On 21.07.2025 17:51, Ross Lagerwall wrote: > On Wed, Jul 16, 2025 at 5:00 PM Roger Pau Monne <roger....@citrix.com> wrote: >> >> In a livepatch payload relocations will refer to included functions. If >> that function happens to be a replacement for an existing Xen function, the >> relocations on the livepatch payload will use the newly introduced symbol, >> rather than the old one. This is usually fine, but if the result of the >> relocation is stored for later use (for example in the domain struct), >> usages of this address will lead to a page-fault once the livepatch is >> reverted. >> >> Implement a second pass over relocations once the list of replaced >> functions has been loaded, and fixup any references to replaced functions >> to use the old symbol address instead of the new one. There are some >> sections that must be special cased to continue using the new symbol >> address, as those instances must reference the newly added livepatch >> content (for example the alternative patch sites). >> > > Would it be possible to fix this at build time instead by generating the > payload such that relocations to changed functions always point at the > Xen function rather than the included function?
How would you express the difference in the object file? If that's possible (without problematic heuristics), ... > This seems preferable to me rather than making the runtime code more > complicated. ... I agree this would be quite a bit better. Jan > Of course, neither approach would fix all cases - if the function is > completely new calling it would still page-fault after reverting the > live patch - so the usual care needs to be taken when creating live > patches. > > Ross
