alternatives+livepatch testing

[Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>]

Hello,

The recent hiccup with CET-IBT, and discovery that livepatch-build-tools
have been broken for several releases, demonstrates that we do not have
remotely adequate testing in place.  We need to address, and ensure we
don't end up in the same position again.

Alternatives and Livepatching have a number of overlapping test
requirements, so how about the following plan:

1) Introduce a new $arch/scm-tests.c, with something akin to the
existing stub_selftest().  I'm tempted to move stub_selftest() out of
initcall and call it from init_done() (before we clobber .init.text)
because that gets shstk testing included.

Even without livepatching, we've got various requirements such as
endbr's only existing where expected, and getting clobbered when
suitably annotated, and altcalls turning into UD for a still-NULL pointer.

Items not yet upstream but on the radar include inlining of retpoline
thunks and SLS workarounds, which would also fit into this.

2) Provide (in xen.git) a patch to scm-tests.c which OSSTest/other can
use livepatch-build-tools on to generate a real livepatch, and a new
livepatching subop which can be invoked from xen-livepatch in userspace
that will run the same kind of consistency checks as 1) on the patched
content.

This lets us create specific constructs and confirm that they get
patched correctly, without having to specifically execute the result.  I
(think) we can do everything needed without reference to the livepatch
metadata, which simplifies things.

Providing a patch isn't totally ideal from a "maintaining xen" point of
view, but I think we can have a build-time test which confirms the patch
is still good, and it is definitely the right primitive to use for the
end-to-end testing.

Thoughts?

~Andrew