Re: [PATCH 2/3] livepatch: add a dummy hypercall for testing purposes

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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é <roger.pau@xxxxxxxxxx>
> ---
> 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