Re: [PATCH v1] driver: base: Add driver filter support

[Greg Kroah-Hartman]

On Thu, Aug 05, 2021 at 10:52:10AM -0700, Andi Kleen wrote:
> 
> On 8/5/2021 10:25 AM, Kuppuswamy, Sathyanarayanan wrote:
> > 
> > 
> > On 8/5/21 9:37 AM, Dan Williams wrote:
> > > I overlooked the "authorized" attribute in usb and thunderbolt. The
> > > collision problem makes sense. Are you open to a core "authorized"
> > > attribute that buses like usb and thunderbolt would override in favor
> > > of their local implementation? I.e. similar to suppress_bind_attrs:
> > 
> > Even if such overriding is allowed in default boot, it should not be
> > allowed in protected guest + driver_filter model.
> 
> 
> Allowing overriding would be acceptable, as long as nobody does it by
> default. In theory a (root) user program can already do other things that
> make the guest insecure.
> 
> Still it's not clear to me how this proposal solves the builtin and platform
> drivers problem. AFAIK that needs a builtin allowlist in any case. And once
> we have that likely we don't need anything else for current TDX at least,
> because the allowlist is so small and there is no concept of hotplug or
> similar.

What specific platform drivers do you need on these systems that you
would ever want to exclude some and not just allow them all?

> Also another consideration is that we were trying to avoid relying too much
> on user space for this. One of the goals was to move an existing guest image
> to a confidential guest with only minor changes (new kernel / enable
> attestation). Complex changes for securing it would make that much harder.

Just deny all and only allow the ones you "trust".  That is a
well-defined policy that (/me checks notes) Intel created for USB a very
long time ago.

greg k-h