> On May 29, 2020, at 11:39 AM, Ian Jackson <ian.jack...@citrix.com> 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.jack...@citrix.com>
>>> Signed-off-by: Jan Beulich <jbeul...@suse.com>
>> 
>> 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

Reply via email to