Re: [Xen-devel] [PATCH v7 12/12] xen: clarify the security-support status of Kconfig options on ARM

[Julien Grall <julien.grall@xxxxxxx>]

On 24/07/18 23:31, Stefano Stabellini wrote:
> On Mon, 23 Jul 2018, Julien Grall wrote:
> > Hi,
> >
> > On 07/07/18 00:14, Stefano Stabellini wrote:
> > > Signed-off-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>
> > > CC: George.Dunlap@xxxxxxxxxxxxx
> > > CC: Ian.Jackson@xxxxxxxxxxxxx
> > > CC: jbeulich@xxxxxxxx
> > > CC: andrew.cooper3@xxxxxxxxxx
> > > ---
> > >    SUPPORT.md | 10 ++++++++++
> > >    1 file changed, 10 insertions(+)
> > >
> > > diff --git a/SUPPORT.md b/SUPPORT.md
> > > index e3e49e2..151a63d 100644
> > > --- a/SUPPORT.md
> > > +++ b/SUPPORT.md
> > > @@ -22,6 +22,16 @@ EXPERT and DEBUG Kconfig options are not security
> > > supported. Other
> > >    Kconfig options are supported, if the related features are marked as
> > >    supported in this document.
> > >    +On ARM, a wider range of Kconfig configurations is available to enable
> > > +very small lines of code counts in the hypervisor. Not all possible
> > > +combinations of kconfig options are security supported. Instead, a few
> > NIT: s/kconfig/Kconfig/
> >
> > > +pre-canned configurations have been added to xen/arch/arm/configs: they
> > > +are security suppored. Configurations derived from the pre-canned files
> > s/suppored/supported/
> I'll fix
>
>
> > > +by adding non-listed options with their default values, or by enabling
> > > +any of the platform options under "Platform Support" (and their
> > > +dependent options) are security supported, unless stated
> > > +otherwise.
> > I am not entirely sure to understand the implications the paragraph.
> It is meant to say:
>
> 1) xen/arch/arm/configs config files are security supported
> 2) default values of any kconfig options are security supported
> 3) if an option is marked as not security supported in SUPPORT.md, then
>     it is not security supported, no matter the default value
> 4) everything else is not security supported
>   
> Should I try to clarify it? I guess I should make clear that a .config
> with an unsupported option is unsupported as a whole. I can add:
>
>   "A configuration with one or more unsupported options, is not
>   unsupported."
>
>
> > For instance, if I choose arm64_defconfig, memaccess will be enabled by
> > default but any use of it is not security supported. What will be the state of
> > the security support for that .config?
> Yes, memaccess will default to enable. However, SUPPORT.md says it is
> not security supported, hence, the result is that the .config is not
> security supported, according to (3).
We really don't want that. That arm64_defconfig is the default config 
for Xen. Anyone using it will not be security supported.
Distros will likely use the default config as it enables everything. If 
I were a package maintainer, I would expect at minimum to security 
support the .config. This does not mean that using a specific feature 
will be supported.
> There is a catch though. In the specific case of memaccess, SUPPORT.md
> only states the following:
>
> ### Virtual Machine Introspection
>
>      Status, x86: Supported, not security supported
>
> Which doesn't say anything about ARM. It would be a good idea to do the
> same that x86 is doing (Supported, not security supported)?
Memaccess has never been considered to be supported on Arm, yet it is 
enabled by default as on x86. However, most of the code in that context 
is gated by "memaccess_enabled". So what is not security supported is 
the use of memaccess.
Cheers,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel