[RFC] proposal: KVM: Orphaned VMs: The Caretaker approach for Live Update
David Woodhouse
dwmw2 at infradead.org
Wed Apr 29 01:40:32 PDT 2026
On Wed, 2026-04-29 at 10:13 +0200, Alexander Graf wrote:
> I would prefer we only attach the whole caretaker and all of its
> specialties right around the point when live update happens. Why keep it
> dangling and active forever? That way you can also late load the kernel
> module that contains it, so you can be sure it's an up to date version.
"Why keep it dangling and active forever?"
I've always wanted to tie this to address space isolation.
The only way to truly stay in front of the constant stream of new
speculation vulnerabilities has been to just make sure there's nothing
sensitive accessible in the address space at all. Hence all the work on
secret hiding, XPFO, proclocal, etc. — and hence the occasional
researcher finding their shiny new (5-year-old) vulnerability and being
confused when it doesn't leak anything *interesting* in certain
environments.
I'd like to see the inner KVM_RUN loop switch to a completely separate
address space, in which there's a kind of caretaker which can handle
the bare minimum of interrupts and timers and the most common exits,
and which *relatively* rarely has to come back into the real Linux
address space.
And once you have that caretaker running in its own address space...
why not just let it keep going while Linux does its kexec?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5069 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/kexec/attachments/20260429/bd5d8620/attachment.p7s>
More information about the kexec
mailing list