| Message ID | 20210506124752.65844-1-george.dunlap@citrix.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2] SUPPORT.md: Un-shimmed 32-bit PV guests are no longer supported | expand |
On 06.05.2021 14:47, George Dunlap wrote: > --- 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. Alongside this I wonder whether we should also default opt_pv32 to false then, unless running in shim mode. Jan
On 06/05/2021 14:09, Jan Beulich wrote: > On 06.05.2021 14:47, George Dunlap wrote: >> --- 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. > Alongside this I wonder whether we should also default opt_pv32 to false > then, unless running in shim mode. No - that's just rude to users. Anyone whose enabled CONFIG_PV32 may potentially want to run such guests. Its easy to avoid issues here by not running 32bit bit guests, or not running untrusted guests, but forcing everyone to reboot a second time to specify pv=32 to unbreak their environment is downright unhelpful. Perhaps tangentially, xl/libxl needs some remedial work as a followup, because: Executing 'xl create -p tests/example/test-pv32pae-example.cfg' Parsing config from tests/example/test-pv32pae-example.cfg xc: error: panic: xg_dom_boot.c:121: xc_dom_boot_mem_init: can't allocate low memory for domain: Out of memory libxl: error: libxl_dom.c:586:libxl__build_dom: xc_dom_boot_mem_init failed: Operation not supported libxl: error: libxl_create.c:1572:domcreate_rebuild_done: Domain 3:cannot (re-)build domain: -3 libxl: error: libxl_domain.c:1182:libxl__destroy_domid: Domain 3:Non-existant domain libxl: error: libxl_domain.c:1136:domain_destroy_callback: Domain 3:Unable to destroy guest libxl: error: libxl_domain.c:1063:domain_destroy_cb: Domain 3:Destruction of domain failed is what the user gets back when Xen has correctly reported that it isn't pv32-capable, and rejects the switch_compat() hypercall. ~Andrew
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 <jannh@google.com> > Signed-off-by: George Dunlap <george.dunlap@citrix.com> > Signed-off-by: Jan Beulich <jbeulich@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.
On 07.05.2021 12:26, Roger Pau Monné wrote: > On Thu, May 06, 2021 at 01:47:52PM +0100, George Dunlap wrote: >> --- 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? But by changing the default we don't disrupt anyone or anything. Or are you suggesting people really caring about Xen build it with the default config without even looking? > 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. I, too, have been considering to suggest this. Iirc Andrew did already point out that the error messages resulting from xl aren't really helpful to understand what the problem is (iirc he said they claim an out-of-memory situation). Jan
> On May 6, 2021, at 1:47 PM, George Dunlap <george.dunlap@citrix.com> 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 <jannh@google.com> > Signed-off-by: George Dunlap <george.dunlap@citrix.com> > Signed-off-by: Jan Beulich <jbeulich@suse.com> > --- > v2: > - add in Kconfig from advisory, ported over c/s d23d792478d There haven’t been any objections to this patch, only suggested additional actions taken. Unless someone objects by EOD today I’m going to check it in. -George
On 06.05.2021 14:47, George Dunlap wrote: > --- 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 The tool stack side change that Jürgen has just sent will only address the smoke test side of the resulting fallout. Unless steps get taken to continue to build Xen with PV32=y in osstest (despite the changed default), I expect many (all?) of the test-amd64-i386-* to then fail when doing a full flight, as otherwise a 32-bit Dom0 then also won't be usable anymore. Of course I think I recall the question having got raised in the past whether the 32-bit Dom0 testing shouldn't be dropped at some point. Yet even then I suppose some 32-bit DomU testing would still want keeping, which still would require a PV32=y hypervisor. I guess we want to postpone backporting until that is sorted. Jan
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. config PV_LINEAR_PT bool "Support for PV linear pagetables"