Virtualization - Oct 2021 - [PATCH v2 2/6] driver core: Add common support to skip probe for un-authorized devices

On Thu, Sep 30, 2021 at 12:23:36PM -0700, Andi Kleen
wrote:
> 
> > I don't think the current mitigations under discussion here are
about
> > keeping the system working. In fact most encrypted VM configs tend to
> > stop booting as a preferred way to handle security issues.
> 
> Maybe we should avoid the "trusted" term here. We're only
really using it
> because USB is using it and we're now using a common framework like
Greg
> requested. But I don't think it's the right way to think about it.
> 
> We usually call the drivers "hardened". The requirement for a
hardened
> driver is that all interactions through MMIO/port/config space IO/MSRs are
> sanitized and do not cause memory safety issues or other information leaks.
> Other than that there is no requirement on the functionality. In particular
> DOS is ok since a malicious hypervisor can decide to not run the guest at
> any time anyways.
> 
> Someone loading an malicious driver inside the guest would be out of scope.
> If an attacker can do that inside the guest you already violated the
> security mechanisms and there are likely easier ways to take over the guest
> or leak data.
> 
> The goal of the device filter mechanism is to prevent loading unhardened
> drivers that could be exploited without them being themselves malicious.
If all you want to do is prevent someone from loading a bunch of 
drivers that you have identified as unhardened, why not just use a 
modprobe blacklist?  Am I missing something?

Alan Stern

On Thu, Sep 30, 2021 at 1:44 PM Alan Stern <stern at rowland.harvard.edu>
wrote:
>
> On Thu, Sep 30, 2021 at 12:23:36PM -0700, Andi Kleen wrote:
> >
> > > I don't think the current mitigations under discussion here
are about
> > > keeping the system working. In fact most encrypted VM configs
tend to
> > > stop booting as a preferred way to handle security issues.
> >
> > Maybe we should avoid the "trusted" term here. We're
only really using it
> > because USB is using it and we're now using a common framework
like Greg
> > requested. But I don't think it's the right way to think about
it.
> >
> > We usually call the drivers "hardened". The requirement for
a hardened
> > driver is that all interactions through MMIO/port/config space IO/MSRs
are
> > sanitized and do not cause memory safety issues or other information
leaks.
> > Other than that there is no requirement on the functionality. In
particular
> > DOS is ok since a malicious hypervisor can decide to not run the guest
at
> > any time anyways.
> >
> > Someone loading an malicious driver inside the guest would be out of
scope.
> > If an attacker can do that inside the guest you already violated the
> > security mechanisms and there are likely easier ways to take over the
guest
> > or leak data.
> >
> > The goal of the device filter mechanism is to prevent loading
unhardened
> > drivers that could be exploited without them being themselves
malicious.
>
> If all you want to do is prevent someone from loading a bunch of
> drivers that you have identified as unhardened, why not just use a
> modprobe blacklist?  Am I missing something?
modules != drivers (i.e. multi-driver modules are a thing) and builtin
modules do not adhere to modprobe policy.

There is also a desire to be able to support a single kernel image
across hosts and guests. So, if you were going to say, "just compile
all unnecessary drivers as modules" that defeats the common kernel
image goal. For confidential computing the expectation is that the
necessary device set is small. As you can see in the patches in this
case it's just a few lines of PCI ids and a hack to the virtio bus to
achieve the goal of disabling all extraneous devices by default.

> If all you want to do is prevent someone from loading a bunch of
> drivers that you have identified as unhardened, why not just use a
> modprobe blacklist?
That wouldn't help for builtin drivers, we cannot control initcalls.

This LWN article has more details on the background.

https://lwn.net/Articles/865918/

-Andi

> Am I missing something?
>
> Alan Stern

On Thu, Sep 30, 2021 at 01:52:59PM -0700, Dan Williams
wrote:
> On Thu, Sep 30, 2021 at 1:44 PM Alan Stern <stern at
rowland.harvard.edu> wrote:
> >
> > On Thu, Sep 30, 2021 at 12:23:36PM -0700, Andi Kleen wrote:
> > >
> > > > I don't think the current mitigations under discussion
here are about
> > > > keeping the system working. In fact most encrypted VM
configs tend to
> > > > stop booting as a preferred way to handle security issues.
> > >
> > > Maybe we should avoid the "trusted" term here.
We're only really using it
> > > because USB is using it and we're now using a common
framework like Greg
> > > requested. But I don't think it's the right way to think
about it.
> > >
> > > We usually call the drivers "hardened". The requirement
for a hardened
> > > driver is that all interactions through MMIO/port/config space
IO/MSRs are
> > > sanitized and do not cause memory safety issues or other
information leaks.
> > > Other than that there is no requirement on the functionality. In
particular
> > > DOS is ok since a malicious hypervisor can decide to not run the
guest at
> > > any time anyways.
> > >
> > > Someone loading an malicious driver inside the guest would be out
of scope.
> > > If an attacker can do that inside the guest you already violated
the
> > > security mechanisms and there are likely easier ways to take over
the guest
> > > or leak data.
> > >
> > > The goal of the device filter mechanism is to prevent loading
unhardened
> > > drivers that could be exploited without them being themselves
malicious.
> >
> > If all you want to do is prevent someone from loading a bunch of
> > drivers that you have identified as unhardened, why not just use a
> > modprobe blacklist?  Am I missing something?
> 
> modules != drivers (i.e. multi-driver modules are a thing) and builtin
> modules do not adhere to modprobe policy.
> 
> There is also a desire to be able to support a single kernel image
> across hosts and guests. So, if you were going to say, "just compile
> all unnecessary drivers as modules" that defeats the common kernel
> image goal. For confidential computing the expectation is that the
> necessary device set is small. As you can see in the patches in this
> case it's just a few lines of PCI ids and a hack to the virtio bus to
> achieve the goal of disabling all extraneous devices by default.


If your goal is to prevent some unwanted _drivers_ from operating -- 
or all but a few desired drivers, as the case may be -- why extend 
the "authorized" API to all _devices_?  Why not instead develop a 
separate API (but of similar form) for drivers?

Wouldn't that make more sense?  It corresponds a lot more directly 
with what you say you want to accomplish.

What would you do in the theoretical case where two separate drivers 
can manage the same device, but one of them is desired (or hardened) 
and the other isn't?

Alan Stern