On Thu, May 06, 2021 at 01:47:52PM +0100, George Dunlap wrote: > The support status of 32-bit guests doesn't seem particularly useful. > > With it changed to fully unsupported outside of PV-shim, adjust the PV32 > Kconfig default accordingly. > > Reported-by: Jann Horn <ja...@google.com> > Signed-off-by: George Dunlap <george.dun...@citrix.com> > Signed-off-by: Jan Beulich <jbeul...@suse.com> > --- > v2: > - add in Kconfig from advisory, ported over c/s d23d792478d > --- > SUPPORT.md | 9 +-------- > xen/arch/x86/Kconfig | 7 +++++-- > 2 files changed, 6 insertions(+), 10 deletions(-) > > diff --git a/SUPPORT.md b/SUPPORT.md > index d0d4fc6f4f..a29680e04c 100644 > --- a/SUPPORT.md > +++ b/SUPPORT.md > @@ -86,14 +86,7 @@ No hardware requirements > > Status, x86_64: Supported > Status, x86_32, shim: Supported > - Status, x86_32, without shim: Supported, with caveats > - > -Due to architectural limitations, > -32-bit PV guests must be assumed to be able to read arbitrary host memory > -using speculative execution attacks. > -Advisories will continue to be issued > -for new vulnerabilities related to un-shimmed 32-bit PV guests > -enabling denial-of-service attacks or privilege escalation attacks. > + Status, x86_32, without shim: Supported, not security supported > > ### x86/HVM > > diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig > index e55e029b79..9b164db641 100644 > --- a/xen/arch/x86/Kconfig > +++ b/xen/arch/x86/Kconfig > @@ -55,7 +55,7 @@ config PV > config PV32 > bool "Support for 32bit PV guests" > depends on PV > - default y > + default PV_SHIM > select COMPAT > ---help--- > The 32bit PV ABI uses Ring1, an area of the x86 architecture which > @@ -67,7 +67,10 @@ config PV32 > reduction, or performance reasons. Backwards compatibility can be > provided via the PV Shim mechanism. > > - If unsure, say Y. > + Note that outside of PV Shim, 32-bit PV guests are not security > + supported anymore. > + > + If unsure, use the default setting.
While not opposed to this, I wonder whether we should give people some time to adapt. We have in the past not blocked vulnerable configurations by default (ie: the smt stuff for example). It might be less disruptive for users to start by printing a warning message at boot (either on the serial for dom0 or in the toolstack for domU) and switch the default Kconfig slightly later? Note I don't have any specific interest in 32bit PV, so I'm not going to argue strongly against this if everyone else is fine with it. I also wonder whether xl shouldn't try to boot PV 32bit guests by default using the shim now if the hypervisor has been built without CONFIG_PV32, or at least print a message so users know how to deal with the fallout. Roger.
