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
