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
> <[email protected]> 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.
On Wed, Aug 4, 2021 at 2:07 PM Matthew Wilcox <[email protected]> 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
> > <[email protected]> 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.
On 8/4/2021 2:28 PM, Dan Williams wrote
> 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.
Another way to see it is: the confidential guest is protected against
the host, except for the places where it chooses to communicate with the
host through MMIOs, port IOs, some (not all) MSRs. It's somewhat
analogous to a network server in a hostile network which can be attacked
through network packets. We typically use a firewall to limit the
network exposure only to especially hardened network services. Each low
level MMIO etc. is like a network access communicating with a hostile
network. The device filter is the firewall for these vulnerable low
level interactions. It reduces the hardening problem from being
completely infeasible to tractable.
-Andi
On Wed, Aug 04, 2021 at 02:28:32PM -0700, Dan Williams wrote:
> On Wed, Aug 4, 2021 at 2:07 PM Matthew Wilcox <[email protected]> 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
> > > <[email protected]> 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.
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