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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Fri, 20 Apr 2018, Jan Beulich wrote:
> >>> On 20.04.18 at 00:43, <sstabellini@xxxxxxxxxx> wrote:
> > 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?
> 
> How about a limited set of "canned" configurations which are security
> supported?

Yes, I think that is a good idea. It is a natural evolution of what we
are already doing.


As I mentioned here https://marc.info/?l=xen-devel&m=152417800326142 in
the context of testing, I think we should only keep in-tree kconfigs
that are well tested for each release. On ARM it is not obvious as the
kconfigs are board specific, so we need somebody with the hardware to
run the tests and send back results twice a year.

With this simple rule in place, I think the number of kconfigs will be
drastically reduced to only the ones for boards that are actively used
and supported.


Moreover, specifically regarding security support, most of the ARM
kconfigs will have similar and extremely small set of kconfig options.
The only differences will be in terms of drivers: UART drivers, SMMU
drivers, GIC drivers, and little else.

Today, all these drivers options are already security supported, it is
only the number of combinations that will increase. However, generally,
I don't think that different combinations of drivers (UART, SMMU, etc)
should cause any problems: even today only one driver for each kind of
devices is actually used at runtime.


In other words, provided that we have a way to embed the .config into
the binary, I think that security-supporting a limited set of "canned"
configurations shouldn't pose any additional efforts onto the security
team. Of course, if it turns out that it generates more work than we are
prepared to handle, we can always revisit this decision.

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