On 23/11/2023 11:23 am, Roger Pau Monne wrote: > Introduce a dummy XEN_SYSCTL_LIVEPATCH_TEST hypercall to be used in order to > test livepatch functionality. The hypercall fills a value in the passed > structure, which is returned to the caller. > > The xen-livepatch utility is expanded to allow calling that hypercall, and > printing the returned value on stdout. > > Finally, add dummy patch that changes the returned value of the hypercall from > 1 to 2. Such patch can be used with livepatch-build-tools in order to > generate > a livepatch payload, that when applied to the hypervisor change the printed > value of `xen-livepatch test`. > > Signed-off-by: Roger Pau Monné <[email protected]> > --- > The whole logic is very simple now. I think it's enough to have a skeleton we > can later expand. > > Unsure whether we should do some kind of test (with `patch -F0`) that the > patch > still applies cleanly as part of Xen build.
Thanks for looking into this. I think one tweak towards the larger plan might help here. When I envisaged this originally, it was something along the lines of test_self_modify_code() which would be called on boot after alternatives were called, which would sanity check the result of certain simple cases. Then, for livepatching, I was thinking of something like this: obj-y += test_smc.o targets-y += test_smc_alt.o i.e. we have test_smc.c and test_smc_alt.c which are two slightly different copies of the same thing, and we compile both but don't link the second one in. Then, we can diff the two C files in order to make the patch to build as a livepatch. This way we're not maintaining a patch committed into the tree, which I suspect will make everyone's lives easier. I suspect in practice that we'll want test_smc_asm.S pairs too. Not necessarily for now, but I was also thinking we'd have a test stage where we know exactly what the livepatch ought to look like, so we audit the eventual livepatch elf that it has all the expected differences encoded, and no extraneous ones. Finally, I was thinking that the hypercall would (re)run test_self_modify_code(). I'm on the fence about making it part of the livepatch infrastructure, given that the nature of the test is wider, but I can't think of any case that we'd be wanting runtime self modifying code (e.g. rerun alternatives after ucode load) which isn't linked to a new livepatch to begin with. Thoughts? ~Andrew
