Lines Matching refs:of
8 This document describes the design of the API that would allow us to
13 * Detailed descriptions of the problem statement.
14 * Design of the data structures.
15 * Design of the hypercalls.
23 * payload - telemetries of the old code along with binary blob of the new
31 The end of the document has a section titled `Not Yet Done` which
32 outlines ideas and design for the future version of this work.
38 no gaps - so we have no luxury of 'moving' existing code and must either
40 the code if there is sufficient space. The placement of new code has to be done
47 To lessen the amount of code in hypervisor, the consumer of the API
49 to patch. Combinations of modifying in-place code, adding trampoline, etc
58 The expected workflows of higher-level tools that manage multiple patches
79 old function with the address of the new function.
82 start of the old function. N.B. The Xen hypervisor implements the third
85 ### Example of trampoline and in-place splicing
108 bytes of code which alters all the offsets inside the function. To alter
109 these offsets and add the extra 21 bytes of code we might not have enough
124 - which is not called directly by hypervisor but on behalf of the guests via
139 of the new virtual address of `arch_do_domctl`.
141 In summary this example patched the callee of the affected function by
145 * changing the function pointer tables with the new virtual address of
152 patches this could mean - if there were an sufficient large amount of
158 ### Example of different trampoline patching.
184 of the new virtual address of `do_xen_version`.
203 which would lessen the amount of patching to just one location.
213 The disadvantage of this are that the unconditional jump will consume a small
214 I-cache penalty. However the simplicity of the patching and higher chance
215 of passing safety checks make this a worthwhile option.
231 of the payload to be certain it came from a trusted source and integrity
238 ## Design of payload format
248 there are severe disadvantages of it:
256 carrying the various sets of structures (and data) in the ELF sections under
262 Earlier design attempted to ineptly explain the relations of the ELF sections
273 * Relocations for each of these sections.
280 * Relocations for each of these sections.
288 * `.livepatch.funcs` - which is an array of livepatch_func structures.
291 * `.note.gnu.build-id` - the build-id of this payload. **MUST** have one.
295 The `.livepatch.funcs` contains an array of livepatch_func structures
310 The size of the structure is 64 bytes on 64-bit hypervisors. It will be
313 * `name` is the symbol name of the old function. Only used if `old_addr` is
317 * `old_addr` is the address of the function to be patched and is filled in at
322 * If there is a non-zero value, then it is the address of the function that is
324 The value **MUST** be the address of the new function in the payload file.
329 * `old_size` contains the sizes of the respective `old_addr` function in bytes.
330 The value of `old_size` **MUST** not be zero.
333 * If `new_addr` contains an non-zero value, then `new_size` has the size of
335 * If the value of `new_addr` is zero then `new_size` determines how many
343 The size of the `livepatch_func` array is determined from the ELF section
354 It optionally may contain the address of functions to be called right before
357 * `.livepatch.hooks.load` - an array of function pointers.
358 * `.livepatch.hooks.unload` - an array of function pointers.
361 ### Example of .livepatch.funcs
363 A simple example of what a payload file can be:
400 This section contains an array of function pointers to be executed
407 The type definition of the function are as follow:
421 which follows the format of an ELF Note. The contents of this
429 The size of these structures varies with the --build-id linker option.
433 We will employ the sub operations of the system management hypercall (sysctl).
437 * listing of payloads summary uploaded and their state.
441 Most of the actions are asynchronous therefore the caller is responsible
442 to verify that it has been applied properly by retrieving the summary of it
445 We **MUST** make some of them asynchronous due to the nature of patching
456 The hypercall is part of the `xen_sysctl`. The top level structure contains
470 while the rest of hypercall specific structures are part of the this structure.
474 Most of the hypercalls employ an shared structure called `struct xen_livepatch_name`
478 * `size` - the size of the string
491 uint16_t size; /* IN, size of name. May be upto
507 * `size` the size of the ELF payload (in bytes).
508 * `payload` the virtual address of where the ELF payload is.
523 xen_livepatch_name_t name; /* IN, name of the patch. */
524 uint64_t size; /* IN, size of the ELF file. */
531 Retrieve an status of an specific payload. This caller provides:
539 * `status` - indicates the current status of the payload:
549 The return value of the hypercall is zero on success and -XEN_EXX on failure.
583 xen_livepatch_name_t name; /* IN, the name of the payload. */
584 xen_livepatch_status_t status; /* IN/OUT: status of the payload. */
590 Retrieve an array of abbreviated status and names of payloads that are loaded in the
595 * `version`. Version of the payload. Caller should re-use the field provided by
601 * `nr` the max number of entries to populate. Can be zero which will result
602 in the hypercall being a probing one and return the number of payloads
605 * `status` virtual address of where to write `struct xen_livepatch_status`
606 structures. Caller *MUST* allocate up to `nr` of them.
607 * `name` - virtual address of where to write the unique name of the payload.
608 Caller *MUST* allocate up to `nr` of them. Each *MUST* be of
611 * `len` - virtual address of where to write the length of each unique name
612 of the payload. Caller *MUST* allocate up to `nr` of them. Each *MUST* be
613 of sizeof(uint32_t) (4 bytes).
616 provided to the hypercall) of the payloads returned, along with `nr` updated
617 with the number of remaining payloads, `version` updated (it may be the same
620 value (`idx`) with the returned value of data.
627 Note that due to the asynchronous nature of hypercalls the control domain might
628 have added or removed a number of payloads making this information stale. It is
629 the responsibility of the toolstack to use the `version` field to check
634 The `struct xen_livepatch_status` structure contains an status of payload which includes:
636 * `status` - indicates the current status of the payload:
656 amount of payloads and version.
660 space allocate for nr of them. */
661 XEN_GUEST_HANDLE_64(char) id; /* OUT: Array of names. Each member
663 Must have nr of them. */
664 XEN_GUEST_HANDLE_64(uint32) len; /* OUT: Array of lengths of name's.
665 Must have nr of them. */
683 more time than the upper bound of time the `rc` in `xen_livepatch_status'
686 more time than the upper bound of time the `rc` in `xen_livepatch_status'
689 payload. If the operation takes more time than the upper bound of time
692 * `time` the upper bound of time (ns) the cmd should take. Zero means to use
707 xen_livepatch_name_t name; /* IN, name of the patch. */
711 /* Or upper bound of time (ns) */
717 ## State diagrams of LIVEPATCH_ACTION commands.
719 There is a strict ordering state of what the commands can be.
731 ## State transition table of LIVEPATCH_ACTION commands and LIVEPATCH_STATUS.
740 The state transition table of valid states and action states:
769 ## Sequence of events.
771 The normal sequence of events is to:
790 on what the CPU supports. This is done by providing multiple streams of code
806 minimize the chance of the patch not being applied due to safety
810 #### Rendezvous code instead of stop_machine for patching
815 of rendezvous code should avoid this problem.
847 ### Generation of Live Patch ELF payloads
849 The design of that is not discussed in this design.
875 has a habit of coalescing strings that are the same - which means if we in-place
901 depending on the current state of data. As such it should not be attempted.
923 Over the life-time of patching the hypervisor this large patch
927 of the hypevisor to make sure the hot-patches are build against the
934 The disadvantage of the first large patch is that it can grow over
937 The hot-patch stack puts stricts requirements on the order of the patches
943 The second option which requires an build-id of the hypervisor
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
956 This is for further development of live patching.
962 * Be able to lookup in the Xen hypervisor the symbol names of functions from the
965 * Deal with NMI/MCE checks during patching instead of ignoring them.
966 * Further safety checks (blacklist of which functions cannot be patched, check
976 and potentially has influence on the design of the hotpatching
999 reformatting of the source code or by introducing artificial
1012 content of specific source file. It may also trigger pulling in
1014 to limitations of a hotpatching framework (init-sections, parts of
1034 could be argued that file renaming should be done outside of hotpatches.
1038 The signature checking requires that the layout of the data in memory
1043 The signature is based on the all of the payloads continuously laid out
1044 in memory. The signature is to be appended at the end of the ELF payload
1081 u8 signer_len; /* Length of signer's name */
1082 u8 key_id_len; /* Length of key identifier */
1084 __be32 sig_len; /* Length of signature data */
1094 depending on the current state of data. As such it should not be attempted.
1100 reverted. This is because we cannot guarantee that the state of .bss
1105 and the .data or .bss sections are of zero length.
1115 we are limited to up to 2GB of virtual address to place the new code
1140 A compile-time check for, e.g., a minimum alignment of functions or a
1161 The hypervisor also checks the displacement during loading of the payload.