Lines Matching refs:to
5 A mechanism is required to binarily patch the running hypervisor with new
6 opcodes that have come about due to primarily security updates.
8 This document describes the design of the API that would allow us to
9 upload to the hypervisor binary patches.
22 * trampoline - a jump to a new instruction.
25 * reloc - telemetries contained in the payload to construct proper trampoline.
34 ## Multiple ways to patch
36 The mechanism needs to be flexible to patch the hypervisor in multiple ways
39 insert a trampoline to the new code to be executed - or only modify in-place
40 the code if there is sufficient space. The placement of new code has to be done
48 is responsible for identifying which mechanism to employ and how many locations
49 to patch. Combinations of modifying in-place code, adding trampoline, etc
50 has to be supported. The API should allow read/write any memory within
53 We must also have a mechanism to query what has been applied and a mechanism
54 to revert it if needed.
64 * One wants to query which modules have been loaded at runtime.
65 * If unloading is deemed safe (see unloading below), one may want to
71 The first mechanism to patch that comes in mind is in-place replacement.
74 to replace the instructions. That is not a problem if the change is smaller
78 The second mechanism is by ti replace the call or jump to the
81 A third mechanism is to add a jump to the new function at the
88 *domctl/sysctl: don't leak hypervisor stack to toolstacks*
89 4ff3449f0e9d175ceb9551d3f2aecb59273f639d) and we would like to binary patch
110 space in .text to squeeze this in.
123 Astute readers will wonder what we need to do if we were to patch `do_domctl`
138 to be patched in a similar way. This would require an in-place splicing
142 * allocating memory for the new code to live in,
147 resides in the .rodata section we would need to temporarily change the
150 However it has drawbacks - the safety checks which have to make sure
153 callers - that we would never be able to apply the update.
161 existing function to be patched to jump directly to the new code. This
162 lessens the locations to be patched to one but it puts pressure on the
183 to be patched in a similar way. This would require an in-place splicing
186 An alternative solution would be to patch insert a trampoline in the
187 old `do_xen_version' function to directly jump to the new `do_xen_version`.
203 which would lessen the amount of patching to just one location.
205 In summary this example patched the affected function to jump to the
207 * allocating memory for the new code to live in,
208 * inserting trampoline with new offset in the old function to point to the
210 * Optionally we can insert in the old function a trampoline jump to an function
211 providing an BUG_ON to catch errant code.
218 checks have to make sure the function is not on the stack. However
220 to various offsets within functions) the checks are simpler.
228 diligent in only allowing certain guests to perform this operation.
231 of the payload to be certain it came from a trusted source and integrity
234 As such the hypercall **MUST** support an XSM policy to limit what the guest
235 is allowed to invoke. If the system is booted with signature checking the
240 The payload **MUST** contain enough data to allow us to apply the update
243 * The locations in memory to be patched. This can be determined dynamically
250 * The format might need to be changed and we need an mechanism to accommodate
252 * It has to be platform agnostic.
262 Earlier design attempted to ineptly explain the relations of the ELF sections
263 to each other without using proper ELF mechanism (sh_info, sh_link, data
296 which describe the functions to be patched:
317 * `old_addr` is the address of the function to be patched and is filled in at
319 the value *MUST* be zero and the hypervisor will attempt to resolve the address.
336 instruction bytes to NOP (up to opaque size modulo smallest platform
339 * `version` is to be one.
347 structure and the core code inserts a trampoline at `old_addr` to `new_addr`.
352 to `old_addr`.
354 It optionally may contain the address of functions to be called right before
400 This section contains an array of function pointers to be executed
402 the payload. This is useful to prepare data structures that need to
416 To support dependencies checking and safe loading (to load the
418 to embbed an build-id dependency.
422 (name, and description) are specific to the linker utilized to
434 There are to be four sub-operations:
439 * command to apply, delete, or revert the payload.
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
446 it requires every physical CPU to be lock-step with each other.
451 The sub-operations will spell out how preemption is to be handled (if at all).
453 Furthermore it is possible to have multiple different payloads for the same
454 function. As such an unique name per payload has to be visible to allow proper manipulation.
457 one uint32_t to determine the sub-operations and one padding field which
479 * `pad` - padding - to be zero.
490 XEN_GUEST_HANDLE_64(char) name; /* IN, pointer to name. */
499 Upload a payload to the hypervisor. The payload is verified
560 We apply an action - LIVEPATCH_ACTION_REVERT - to revert it (which won't work
601 * `nr` the max number of entries to populate. Can be zero which will result
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
616 provided to the hypercall) of the payloads returned, along with `nr` updated
627 Note that due to the asynchronous nature of hypercalls the control domain might
629 the responsibility of the toolstack to use the `version` field to check
631 data and start from scratch. It is OK for the toolstack to use the new
655 should be filled out. Can be zero to get
692 * `time` the upper bound of time (ns) the cmd should take. Zero means to use
712 /* for operation to take. */
720 The LIVEPATCH_ACTION prefix has been dropped to easy reading and
736 - The REVERT operation on success will automatically move to the CHECKED state.
771 The normal sequence of events is to:
773 1. *XEN_SYSCTL_LIVEPATCH_UPLOAD* to upload the payload. If there are errors *STOP* here.
774 2. *XEN_SYSCTL_LIVEPATCH_GET* to check the `->rc`. If *-XEN_EAGAIN* spin. If zero go to next step.
775 3. *XEN_SYSCTL_LIVEPATCH_ACTION* with *LIVEPATCH_ACTION_APPLY* to apply the patch.
776 …4. *XEN_SYSCTL_LIVEPATCH_GET* to check the `->rc`. If in *-XEN_EAGAIN* spin. If zero exit with suc…
789 Alternative assembler is a mechanism to use different instructions depending
792 `nop` operations. The alternative assembler macros cause the compiler to
793 expand the code to place a most generic code in place - emit a special
794 ELF .section header to tag this location. During run-time the hypervisor
797 Note that patching functions that copy to or from guest memory requires
798 to support alternative support. For example this can be due to SMAP
800 and later architectures. It may be related to other alternative instructions.
802 ### When to patch
806 minimize the chance of the patch not being applied due to safety
808 is on the stack - which can lead to corruption.
813 every second. Using the stop_machine to patch can stall the time rendezvous
826 Before we call VMXResume we check whether any soft IRQs need to be executed.
832 hypervisor with IPIs, can be utilized to execute lockstep instructions
835 The approach is similar in concept to stop_machine and the time rendezvous
844 with -ffunction-sections / -fdata-sections. Changes would have to
845 be done to the linker scripts to support this.
859 patching such code. Hotpatches may need to bring their own small
860 exception tables (similar to how Linux modules support this).
866 As found almost every patch (XSA) to a non-trivial function requires
873 The patching might require strings to be updated as well. As such we must be
874 also able to patch the strings as needed. This sounds simple - but the compiler
878 This is also where pointers to functions live - and we may need to patch this
881 To guard against that we must be prepared to do patching similar to
883 do in-line patching we would need to:
885 * alter `.rodata` to be writeable.
887 * alter `.rodata` to be read-only.
889 If are doing trampoline patching we would need to:
892 * all locations which use this string will have to be updated to use the
893 offset to the string.
903 However, functions which are being patched can bring in changes to strings
904 (.data or .rodata section changes), or even to .bss sections.
915 Only the privileged domain should be allowed to do this operation.
924 grows to accumulate all the code changes.
927 of the hypevisor to make sure the hot-patches are build against the
929 * Payload containing the old code to check against that. That allows
930 the hotpatches to be loaded indepedently (if they don't overlap) - or
935 time and not provide an bisection mechanism to identify faulty patches.
938 being loaded and requires an hypervisor build-id to match against.
941 but is more complex to implement.
962 * Be able to lookup in the Xen hypervisor the symbol names of functions from the
964 * Be able to patch .rodata, .bss, and .data sections.
968 Specifically we want to make sure that live patching codepaths cannot be patched.
975 This problem is related to hotpatch construction
985 Now we want to hotpatch f1 and the hotpatch source-code patch adds 2
986 lines to f1 and as a consequence shifts out f2 by two lines. The newly
992 and after hotpatch application will determine both functions to be
993 changed and will have to include both into the binary hotpatch.
997 1. Transform source code patches for hotpatches to be line-neutral for
1000 preprocessor "#line n" directives to adjust for the introduced
1004 backtraces and existing debug information refers to the original
1011 This approach might lead to some very large hotpatches depending on
1014 to limitations of a hotpatching framework (init-sections, parts of
1026 that with each hotpatch (similarly to exception tables) or we might
1027 purely use it when building hotpatches to ignore functions that only
1033 Similar considerations are true to a lesser extent for __FILE__, but it
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
1101 and .data to be exactly as it was during loading. Hence the administrator
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;
1115 we are limited to up to 2GB of virtual address to place the new code
1124 to accomodate the trampoline. On x86 with +-2 GB relative jumps,
1141 runtime check that verifies symbol size (+ padding to next symbols) for
1145 check to ensure that the function to be replaced is large enough.
1151 with proper offset is used for an unconditional branch to the new code.
1155 The instruction offset is limited on ARM32 to +/- 32MB to displacement
1156 and on ARM64 to +/- 128MB displacement.