On Wed, Aug 4, 2021 at 2:07 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > On Wed, Aug 04, 2021 at 01:11:27PM -0700, Dan Williams wrote: > > On Wed, Aug 4, 2021 at 12:29 PM Greg Kroah-Hartman > > <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > > 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.
