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

Re: [PATCH v6 09/10] kconfig: update xsm config to reflect reality

  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>
  • Date: Fri, 17 Sep 2021 09:19:50 -0400
  • Arc-authentication-results: i=1; mx.zohomail.com; dkim=pass header.i=apertussolutions.com; spf=pass smtp.mailfrom=dpsmith@xxxxxxxxxxxxxxxxxxxx; dmarc=pass header.from=<dpsmith@xxxxxxxxxxxxxxxxxxxx>
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1631884797; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=HhssghJGx7/IL6SOq974BeYYZj6SlieVg2iEnlJF4po=; b=XMGUN8IV0QJRRPRm7A0osGc9/dzvtPllTASogOsA6IfDkY+RL4t8warNZD2w48KljrgTBmvJyWaMIyAO6CHfgKNTs/73ts9wtuHH5cXfXdaP65c9sYK8Qje6syh9mLl+LerFE+MVqTpWRILgzAxx2nOTHPVXemV5MbRIak9ZMuA=
  • Arc-seal: i=1; a=rsa-sha256; t=1631884797; cv=none; d=zohomail.com; s=zohoarc; b=YpJjkWR2KTeCl/tPoVDK4LqnKEAIAvj/+YPvDIeCeQqsgbEIXnufveLZUqHHfamyEoHP+vIK2eOG7/nPLQ0MEV4/kPicFTG97nwCC24kKveskpB0SQEZm01N7tRIR+37zGD2yLau3cKnxtSKwpfhjbOwnHo+aBl430mfXqhbOgo=
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Fri, 17 Sep 2021 13:20:07 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 9/17/21 8:09 AM, Jan Beulich wrote:
> On 10.09.2021 22:13, Daniel P. Smith wrote:
>> --- a/xen/common/Kconfig
>> +++ b/xen/common/Kconfig
>> @@ -200,23 +200,20 @@ config XENOPROF
>>        If unsure, say Y.
>> -config XSM
>> -    bool "Xen Security Modules support"
>> +    bool "Configure Xen Security Modules"
>>      default ARM
>> -    ---help---
>> -      Enables the security framework known as Xen Security Modules which
>> -      allows administrators fine-grained control over a Xen domain and
>> -      its capabilities by defining permissible interactions between domains,
>> -      the hypervisor itself, and related resources such as memory and
>> -      devices.
>> +    help
>> +      Allows for configuring the Xen Security Modules (XSM) policy or 
>> policies
>> +      modules that will be availble and which will be the default.
>>        If unsure, say N.
>>  config XSM_FLASK
>> -    def_bool y
>> -    prompt "FLux Advanced Security Kernel support"
>> -    depends on XSM
>> -    ---help---
>> +    bool "FLux Advanced Security Kernel support"
>> +    depends on XSM_CONFIGURABLE
>> +    select XSM_EVTCHN_LABELING
>> +    help
>>        Enables FLASK (FLux Advanced Security Kernel) as the access control
>>        mechanism used by the XSM framework.  This provides a mandatory access
>>        control framework by which security enforcement, isolation, and
> I continue to think that the default here and ...
>> @@ -253,10 +250,10 @@ config XSM_FLASK_POLICY
>>        If unsure, say Y.
>>  config XSM_SILO
>> -    def_bool y
>> -    prompt "SILO support"
>> -    depends on XSM
>> -    ---help---
>> +    bool "SILO support"
>> +    default y if ARM
>> +    depends on XSM_CONFIGURABLE
>> +    help
>>        Enables SILO as the access control mechanism used by the XSM 
>> framework.
>>        This is not the default module, add boot parameter xsm=silo to choose
>>        it. This will deny any unmediated communication channels (grant tables
> ... here should not change. If it changes, the change needs justifying
> in the description.

IMHO the configure system should not presumptuously assume that if a
user selects XSM_CONFIGURABLE that the Flask module, which is not
currently security supported, should be enabled. I would agree that we
could turn on the SILO module since it is security supported. Later when
I am able to get Flask into a security supported state, I would be all
for enabling it as well. A more roadmap-ish idea is to see SILO subsumed
as a select-able policy under Flask, but that is a bit of a digression.

I will add to the commit message to clarify this position that is being

>> @@ -282,15 +279,15 @@ endchoice
>>  config LATE_HWDOM
>>      bool "Dedicated hardware domain"
>>      default n
>> -    depends on XSM && X86
>> -    ---help---
>> +    depends on XSM_FLASK && X86
>> +    help
>>        Allows the creation of a dedicated hardware domain distinct from
>>        domain 0 that manages devices without needing access to other
>>        privileged functionality such as the ability to manage domains.
>>        This requires that the actual domain 0 be a stub domain that
>>        constructs the actual hardware domain instead of initializing the
>>        hardware itself.  Because the hardware domain needs access to
>> -      hypercalls not available to unprivileged guests, an XSM policy
>> +      hypercalls not available to unprivileged guests, an XSM Flask policy
>>        is required to properly define the privilege of these domains.
> I also continue to think that this would better be a separate change.
> Or if not, the seemingly unrelated change needs mentioning in the
> description (to make clear it's not a stray change).

Apologies that I missed the suggestion to break this out. Since this
really is more of a general clean-up over being part of the intended
improvement for this patch set, I will break it out and move it to the
front of the patch set.




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