xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: "Roger Pau Monné" <roger.pau@citrix.com>
Cc: xen-devel@lists.xenproject.org, Jann Horn <jannh@google.com>,
	George Dunlap <george.dunlap@citrix.com>
Subject: Re: [PATCH v2] SUPPORT.md: Un-shimmed 32-bit PV guests are no longer supported
Date: Fri, 7 May 2021 13:05:28 +0200	[thread overview]
Message-ID: <0a61c24d-4bd3-c6af-7297-7a3b7bcd90b8@suse.com> (raw)
In-Reply-To: <YJUVx8WMn/4f0gMS@Air-de-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


  reply	other threads:[~2021-05-07 11:05 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-06 12:47 George Dunlap
2021-05-06 13:09 ` Jan Beulich
2021-05-06 14:32   ` Andrew Cooper
2021-05-07 10:26 ` Roger Pau Monné
2021-05-07 11:05   ` Jan Beulich [this message]
2021-06-04 13:14 ` George Dunlap
2021-06-07  9:18 ` Jan Beulich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0a61c24d-4bd3-c6af-7297-7a3b7bcd90b8@suse.com \
    --to=jbeulich@suse.com \
    --cc=george.dunlap@citrix.com \
    --cc=jannh@google.com \
    --cc=roger.pau@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    --subject='Re: [PATCH v2] SUPPORT.md: Un-shimmed 32-bit PV guests are no longer supported' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).