[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] xsm: also panic upon "flask=enforcing" when XSM_FLASK=n


  • To: Ian Jackson <Ian.Jackson@xxxxxxxxxx>
  • From: George Dunlap <George.Dunlap@xxxxxxxxxx>
  • Date: Fri, 29 May 2020 10:54:07 +0000
  • Accept-language: en-GB, en-US
  • Authentication-results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Wei Liu <wl@xxxxxxx>, Paul Durrant <paul@xxxxxxx>, Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Daniel de Graaf <dgdegra@xxxxxxxxxxxxx>
  • Delivery-date: Fri, 29 May 2020 10:54:13 +0000
  • Ironport-sdr: bERa16mt1R/JAJK61o8LRYzmUQRyjQzranHHWzNaJlOJMp9ZIsMBYTU/7KaMmJzeIfnde12jcf 4ImnVP5ZCe67aRE53TNWmnfyS8VJa+fcID1t5RxpPGLKJmpR13Qj2Drng3u8AtxzqiKgeHCky2 CquWTTHYTQN5yD1nuVzffvl0oSu/y4+4QvYy4PZfJhiLqkenqDO1f8xcW88Add764MopP4LhVK eO0atxlMx8L8sXTmzfyH7eK7AEC1jvgZDYFame2nGbZ2YAZdyG5e7Wq2vnxs1o0eq9iMrh/T+c s/U=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHWNZxiYb+bsyhbWESXJxTbHwGxDKi+tSMAgAAI34CAAAQxgA==
  • Thread-topic: [PATCH] xsm: also panic upon "flask=enforcing" when XSM_FLASK=n

> On May 29, 2020, at 11:39 AM, Ian Jackson <ian.jackson@xxxxxxxxxx> wrote:
> 
> Andrew Cooper writes ("Re: [PATCH] xsm: also panic upon "flask=enforcing" 
> when XSM_FLASK=n"):
>> On 29/05/2020 10:34, Jan Beulich wrote:
>>> While the behavior to ignore this option without FLASK support was
>>> properly documented, it is still somewhat surprising to someone using
>>> this option and then still _not_ getting the assumed security. Add a
>>> 2nd handler for the command line option for the XSM_FLASK=n case, and
>>> invoke panic() when the option is specified (and not subsequently
>>> overridden by "flask=disabled").
>>> 
>>> Suggested-by: Ian Jackson <ian.jackson@xxxxxxxxxx>
>>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>> 
>> I'm very tempted to nack this outright, lest I remind both of you of the
>> total disaster that was XSA-9, and the subsequent retraction of the code
>> which did exactly this.
> 
> You are right to remind me of, well, whatever it is you are trying to
> remind me of, since I'm afraid I don't know what you mean ...  Do you
> really mean XSA-9 ?  I went at looked it up and the connection eludes
> me.

http://xenbits.xen.org/hg/xen-unstable.hg/rev/bc2f3a848f9a

Which apparently would cause Xen to (purposely) panic when booted on systems 
with the specified AMD erratum.

>> If you want to do something like this, prohibit creating guests so the
>> administrator can still log in and unbreak, instead of having it
>> entering a reboot loop with no output.  The console isn't established
>> this early, so none of this text makes it out onto VGA/serial.
> 
> Certainly a silent reboot loop would be very unhelpful.  I think if
> Xen were to actually print something to the serial console that would
> be tolerable (since the administrator can then adjust the boot command
> line), but your suggestion to prohibit guest creation would be fine
> too.

It seems like having the infrastructure to put Xen into a “unsafe mode”, where 
we refused to create guests (or some other similar response), would be a good 
investment to handle this sort of issue in the future.

 -George

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.