On Wed, Aug 04, 2021 at 02:28:32PM -0700, Dan Williams wrote:

On Wed, Aug 4, 2021 at 2:07 PM Matthew Wilcox [off-list ref] wrote:

quoted

On Wed, Aug 04, 2021 at 01:11:27PM -0700, Dan Williams wrote:

quoted

On Wed, Aug 4, 2021 at 12:29 PM Greg Kroah-Hartman
[off-list ref] wrote:

quoted

Why not just make distros that want to support this type of platform,
also provide these tiny kernel images?  Why are you pushing this work on
the kernel community instead?

In fact, these questions are where I started when first encountering
this proposal. Andi has addressed the single kernel image constraint,
but I want to pick up on this "pushing work to the kernel community"
contention. The small list of vetted drivers that a TDX guest needs
will be built-in and maintained in the kernel by the protected guest
developer community, so no "pushing work" there. However, given that
any driver disable mechanism needs to touch the driver core I
advocated to go ahead and make this a general purpose capability to
pick up where this [1] conversation left off. I.e. a general facility
for the corner cases that modprobe and kernel config policy can not
reach. Corner cases like VMM attacking the VM, or broken hardware with
a built-in driver that can't be unbound after the fact.

I don't understand how this defends against a hypervisor attacking a
guest.  If the hardware exists, the hypervisor can access it, regardless
of whether the driver is default-disabled by configuration.

The "hardware" in this case is virtual devices presented by the VMM to
the VM. So if a driver misbehaves in a useful way for an attacker to
exploit, they can stimulate that behavior with a custom crafted
virtual device, and that driver will autoload unaware of the threat
without this filter for vetted drivers.

As I just said elsewhere in this thread, we have support for this today
for thunderbolt and USB, please just expand that to all bus types and
that should be fine.

thanks,

greg k-h