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
