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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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?

Jan



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