diff mbox series

[v2] SUPPORT.md: Un-shimmed 32-bit PV guests are no longer supported

Message ID 20210506124752.65844-1-george.dunlap@citrix.com (mailing list archive)
State New
Headers show
Series [v2] SUPPORT.md: Un-shimmed 32-bit PV guests are no longer supported | expand

Commit Message

George Dunlap May 6, 2021, 12:47 p.m. UTC
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(-)

Comments

Jan Beulich May 6, 2021, 1:09 p.m. UTC | #1
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
Andrew Cooper May 6, 2021, 2:32 p.m. UTC | #2
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
Roger Pau Monné May 7, 2021, 10:26 a.m. UTC | #3
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.
Jan Beulich May 7, 2021, 11:05 a.m. UTC | #4
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
George Dunlap June 4, 2021, 1:14 p.m. UTC | #5
> 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
Jan Beulich June 7, 2021, 9:18 a.m. UTC | #6
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 mbox series

Patch

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"