|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |