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

On Thu, Sep 30, 2021 at 03:52:52PM +0200, Greg Kroah-Hartman
wrote:
> On Thu, Sep 30, 2021 at 06:59:36AM -0400, Michael S. Tsirkin wrote:
> > On Wed, Sep 29, 2021 at 06:05:07PM -0700, Kuppuswamy Sathyanarayanan
wrote:
> > > While the common case for device-authorization is to skip probe
of
> > > unauthorized devices, some buses may still want to emit a message
on
> > > probe failure (Thunderbolt), or base probe failures on the
> > > authorization status of a related device like a parent (USB). So
add
> > > an option (has_probe_authorization) in struct bus_type for the
bus
> > > driver to own probe authorization policy.
> > > 
> > > Reviewed-by: Dan Williams <dan.j.williams at intel.com>
> > > Signed-off-by: Kuppuswamy Sathyanarayanan
<sathyanarayanan.kuppuswamy at linux.intel.com>
> > 
> > 
> > 
> > So what e.g. the PCI patch
> >
https://lore.kernel.org/all/CACK8Z6E8pjVeC934oFgr=VB3pULx_GyT2NkzAogdRQJ9TKSX9A
at mail.gmail.com/
> > actually proposes is a list of
> > allowed drivers, not devices. Doing it at the device level
> > has disadvantages, for example some devices might have a legacy
> > unsafe driver, or an out of tree driver. It also does not
> > address drivers that poke at hardware during init.
> 
> Doing it at a device level is the only sane way to do this.
> 
> A user needs to say "this device is allowed to be controlled by this
> driver".  This is the trust model that USB has had for over a decade
and
> what thunderbolt also has.
> 
> > Accordingly, I think the right thing to do is to skip
> > driver init for disallowed drivers, not skip probe
> > for specific devices.
> 
> What do you mean by "driver init"?  module_init()?
> 
> No driver should be touching hardware in their module init call.  They
> should only be touching it in the probe callback as that is the only
> time they are ever allowed to talk to hardware.  Specifically the device
> that has been handed to them.
> 
> If there are in-kernel PCI drivers that do not do this, they need to be
> fixed today.
> 
> We don't care about out-of-tree drivers for obvious reasons that we
have
> no control over them.
I don't see any point in talking about "untrusted drivers".  If a 
driver isn't trusted then it doesn't belong in your kernel.  Period.  
When you load a driver into your kernel, you are implicitly trusting 
it (aside from limitations imposed by security modules).  The code 
it contains, the module_init code in particular, runs with full 
superuser permissions.

What use is there in loading a driver but telling the kernel "I don't 
trust this driver, so don't allow it to probe any devices"?  Why not 
just blacklist it so that it never gets modprobed in the first place?

Alan Stern

On Thu, Sep 30, 2021 at 10:43:05AM -0400, Alan Stern
wrote:
> On Thu, Sep 30, 2021 at 03:52:52PM +0200, Greg Kroah-Hartman wrote:
> > On Thu, Sep 30, 2021 at 06:59:36AM -0400, Michael S. Tsirkin wrote:
> > > On Wed, Sep 29, 2021 at 06:05:07PM -0700, Kuppuswamy
Sathyanarayanan wrote:
> > > > While the common case for device-authorization is to skip
probe of
> > > > unauthorized devices, some buses may still want to emit a
message on
> > > > probe failure (Thunderbolt), or base probe failures on the
> > > > authorization status of a related device like a parent
(USB). So add
> > > > an option (has_probe_authorization) in struct bus_type for
the bus
> > > > driver to own probe authorization policy.
> > > > 
> > > > Reviewed-by: Dan Williams <dan.j.williams at
intel.com>
> > > > Signed-off-by: Kuppuswamy Sathyanarayanan
<sathyanarayanan.kuppuswamy at linux.intel.com>
> > > 
> > > 
> > > 
> > > So what e.g. the PCI patch
> > >
https://lore.kernel.org/all/CACK8Z6E8pjVeC934oFgr=VB3pULx_GyT2NkzAogdRQJ9TKSX9A
at mail.gmail.com/
> > > actually proposes is a list of
> > > allowed drivers, not devices. Doing it at the device level
> > > has disadvantages, for example some devices might have a legacy
> > > unsafe driver, or an out of tree driver. It also does not
> > > address drivers that poke at hardware during init.
> > 
> > Doing it at a device level is the only sane way to do this.
> > 
> > A user needs to say "this device is allowed to be controlled by
this
> > driver".  This is the trust model that USB has had for over a
decade and
> > what thunderbolt also has.
> > 
> > > Accordingly, I think the right thing to do is to skip
> > > driver init for disallowed drivers, not skip probe
> > > for specific devices.
> > 
> > What do you mean by "driver init"?  module_init()?
> > 
> > No driver should be touching hardware in their module init call.  They
> > should only be touching it in the probe callback as that is the only
> > time they are ever allowed to talk to hardware.  Specifically the
device
> > that has been handed to them.
> > 
> > If there are in-kernel PCI drivers that do not do this, they need to
be
> > fixed today.
> > 
> > We don't care about out-of-tree drivers for obvious reasons that
we have
> > no control over them.
> 
> I don't see any point in talking about "untrusted drivers". 
If a
> driver isn't trusted then it doesn't belong in your kernel. 
Period.
> When you load a driver into your kernel, you are implicitly trusting 
> it (aside from limitations imposed by security modules).  The code 
> it contains, the module_init code in particular, runs with full 
> superuser permissions.
> 
> What use is there in loading a driver but telling the kernel "I
don't
> trust this driver, so don't allow it to probe any devices"?  Why
not
> just blacklist it so that it never gets modprobed in the first place?
> 
> Alan Stern
When the driver is built-in, it seems useful to be able to block it
without rebuilding the kernel. This is just flipping it around
and using an allow-list for cases where you want to severly
limit the available functionality.


-- 
MST

On Thu, Sep 30, 2021 at 10:43:05AM -0400, Alan Stern
wrote:
> I don't see any point in talking about "untrusted drivers". 
If a
> driver isn't trusted then it doesn't belong in your kernel. 
Period.
> When you load a driver into your kernel, you are implicitly trusting 
> it (aside from limitations imposed by security modules).
Trusting it to do what? Historically a ton of drivers did not
validate input from devices they drive. Most still don't.
> The code 
> it contains, the module_init code in particular, runs with full 
> superuser permissions.
-- 
MST