Re: [Xen-devel] [PATCH 3/6] arm: make it possible to disable the SMMU driver

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Thu, 19 Apr 2018, Jan Beulich wrote:
> >>> On 19.04.18 at 00:15, <sstabellini@xxxxxxxxxx> wrote:
> > --- /dev/null
> > +++ b/xen/drivers/passthrough/arm/Kconfig
> > @@ -0,0 +1,7 @@
> > +
> > +config HAS_SMMUv2
> > +   bool "ARM SMMUv2 driver"
> > +   default y
> > +   depends on ARM
> > +   ---help---
> > +     Driver for the ARM SMMU version 2, a popular IOMMU by ARM.
> 
> This being user-visible but not dependent upon EXPERT - what's the
> support status of a hypervisor built without that option?

Let me take a step back to give you a bit of context to this work, which
will help us decide the best way forward in terms of security support. I
am CC'ing the REST maintainers as well.

With Xen on ARM taking off in embedded, IoT, and automotive, we are
seeing more and more uses of Xen in constrained environments. Users and
system integrators want the smallest Xen and Dom0 configurations. Some
of these deployments require certifications, where you definitely want
the smallest lines of code count. I provided a patch to give us the
lines of code count exactly for that purpose. For reference, one of the
selling points of ACRN is the small code size [0].

I expect kconfig options to proliferate and, generally, all-purpose
kconfigs becoming less attractive going forward.  Having kconfig options
for drivers that should be security supported otherwise is inevitable.


Let's take this example: SMMUv2. The driver is decently quality, and
definitely some boards will require it. It makes sense to security
support it. However, some boards don't come with an SMMU at all, such as
Pine64, or have a different SMMU, such as the Renesas RCar. Certainly,
the smallest kconfig for Pine64/Renesas Rcar shouldn't have the SMMUv2
driver [1]. I think it makes sense to allow the SMMUv2 driver to be
disabled by users. The same argument goes for all of the UART drivers:
each board has only one type of UART, it doesn't make sense to enable
more than one in a kconfig [2].

I think it is OK *not* to security support any option that depends on
EXPERT. But I also think we should allow for options that are
user-visible *and* security supported.

What do you guys think?


[0] https://projectacrn.org/
[1] I realize I enabled the SMMUv2 in the Renesas Rcar kconfig by
    mistake, I'll fix in v2.
[2] See patch #2


> Please recall that as a rule of thumb we try to limit the number of
> different configurations people can build without setting EXPERT, such
> that we don't have to go long ways to figure out what configuration
> was used in case someone reports a problem. People enabling EXPERT are
> left on their own anyway.

To address this specific concern I would like to embed the .config into
the Xen binary, so that we can go back and ask for the kconfig used to
generated Xen easily, see:

https://xenproject.atlassian.net/browse/XEN-38

I intend to come up with a patch and add it to this series.

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