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 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:48:54AM -0400, Michael S. Tsirkin
wrote:
> 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).  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.
Does this make sense?

The only way to tell the kernel to block a built-in driver is by 
using some boot-command-line option.  Otherwise the driver's init 
code will run before you have a chance to tell the kernel anything at 
all.

So if you change your mind about whether a driver should be blocked, 
all you have to do is remove the blocking option from the command 
line and reboot.  No kernel rebuild is necessary.

Alan Stern