Lines Matching refs:payload
23 * payload - telemetries of the old code along with binary blob of the new
25 * reloc - telemetries contained in the payload to construct proper trampoline.
231 of the payload to be certain it came from a trusted source and integrity
238 ## Design of payload format
240 The payload **MUST** contain enough data to allow us to apply the update
255 As such having the payload in an ELF file is the sensible way. We would be
268 The Xen Live Patch payload is a relocatable ELF binary. A typical binary would have:
282 The Xen Live Patch core code loads the payload as a standard ELF binary, relocates it
286 The payload contains at least three sections:
289 * `.livepatch.depends` - which is an ELF Note that describes what the payload
291 * `.note.gnu.build-id` - the build-id of this payload. **MUST** have one.
315 the payload).
318 payload generation time if hypervisor function address is known. If unknown,
324 The value **MUST** be the address of the new function in the payload file.
348 The `new_addr` is altered when the ELF payload is loaded.
363 A simple example of what a payload file can be:
401 before payload is being applied (.livepatch.funcs) or after reverting
402 the payload. This is useful to prepare data structures that need to
417 appropiate payload against the right hypervisor) there is a need
420 This is done by the payload containing an section `.livepatch.depends`
423 build the hypevisor and payload.
438 * getting an particular payload summary and its state.
439 * command to apply, delete, or revert the payload.
443 and verifying that there are no error codes associated with the payload.
454 function. As such an unique name per payload has to be visible to allow proper manipulation.
485 * Uniquely identifies the payload. Should be human readable.
499 Upload a payload to the hypervisor. The payload is verified
501 will be returned. The payload is not applied at this time - that is
507 * `size` the size of the ELF payload (in bytes).
508 * `payload` the virtual address of where the ELF payload is.
511 payload. It can be embedded into the ELF payload at creation time
514 The return value is zero if the payload was succesfully uploaded.
517 The `payload` is the ELF payload as mentioned in the `Payload format` section.
525 XEN_GUEST_HANDLE_64(uint8) payload; /* IN: ELF file. */
531 Retrieve an status of an specific payload. This caller provides:
539 * `status` - indicates the current status of the payload:
540 * *LIVEPATCH_STATUS_CHECKED* (1) loaded and the ELF payload safety checks passed.
553 For example, supposing there is an payload:
583 xen_livepatch_name_t name; /* IN, the name of the payload. */
584 xen_livepatch_status_t status; /* IN/OUT: status of the payload. */
595 * `version`. Version of the payload. Caller should re-use the field provided by
597 * `idx` index iterator. The index into the hypervisor's payload count. It is
599 hypervisor will update with the remaining payload count) be provided.
607 * `name` - virtual address of where to write the unique name of the payload.
612 of the payload. Caller *MUST* allocate up to `nr` of them. Each *MUST* be
634 The `struct xen_livepatch_status` structure contains an status of payload which includes:
636 * `status` - indicates the current status of the payload:
637 * *LIVEPATCH_STATUS_CHECKED* (1) loaded and the ELF payload safety checks passed.
671 Perform an operation on the payload structure referenced by the `name` field.
679 * *LIVEPATCH_ACTION_UNLOAD* (1) unload the payload.
682 * *LIVEPATCH_ACTION_REVERT* (2) revert the payload. If the operation takes
685 * *LIVEPATCH_ACTION_APPLY* (3) apply the payload. If the operation takes
689 payload. If the operation takes more time than the upper bound of time
748 | UNLOAD | CHECKED | Unload payload. Always works. | | |
751 | APPLY | CHECKED | Apply payload (success). | | x |
753 | APPLY | CHECKED | Apply payload (error|timeout) | x | |
756 | | | payload with success. | | |
759 | | | payload with error. | | |
761 | REVERT | APPLIED | Revert payload (success). | x | |
763 | REVERT | APPLIED | Revert payload (error|timeout) | | x |
773 1. *XEN_SYSCTL_LIVEPATCH_UPLOAD* to upload the payload. If there are errors *STOP* here.
906 As such the ELF payload can introduce new .rodata, .bss, and .data sections.
946 Specifically each payload has two build-id ELF notes:
947 * The build-id of the payload itself (generated via --build-id).
948 * The build-id of the payload it depends on (extracted from the
949 the previous payload or hypervisor during build time).
951 This means that the very first payload depends on the hypervisor
963 ELF payload. (Either as `symbol` or `symbol`+`offset`).
967 the stack, make sure the payload is built with same compiler as hypervisor).
971 in payload file.
1039 **MUST** be same for signature to be verified. This means that the payload
1044 in memory. The signature is to be appended at the end of the ELF payload
1097 can be changed during payload application.
1099 To guarantee safety we disallow re-applying an payload after it has been
1102 MUST unload the payload and upload it again to apply it.
1104 There is an exception to this: if the payload only has .livepatch.funcs;
1161 The hypervisor also checks the displacement during loading of the payload.