lkml.org 
[lkml]   [2020]   [Jun]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] Restrict the untrusted devices, to bind to only a set of "whitelisted" drivers
    On Tue, Jun 09, 2020 at 04:04:00PM -0500, Bjorn Helgaas wrote:
    > On Sun, Jun 07, 2020 at 01:36:32PM +0200, Greg Kroah-Hartman wrote:
    >
    > > Your "problem" I think can be summed up a bit more concise:
    > > - you don't trust kernel drivers to be "secure" for untrusted
    > > devices
    > > - you only want to bind kernel drivers to "internal" devices
    > > automatically as you "trust" drivers in that situation.
    > > - you want to only bind specific kernel drivers that you somehow
    > > feel are "secure" to untrusted devices "outside" of a system
    > > when those devices are added to the system.
    > >
    > > Is that correct?
    > >
    > > If so, fine, you can do that today with the bind/unbind ability of
    > > drivers, right? After boot with your "trusted" drivers bound to
    > > "internal" devices, turn off autobind of drivers to devices and then
    > > manually bind them when you see new devices show up, as those "must" be
    > > from external devices (see the bind/unbind files that all drivers export
    > > for how to do this, and old lwn.net articles, this feature has been
    > > around for a very long time.)
    > >
    > > I know for USB you can do this, odds are PCI you can turn off
    > > autobinding as well, as I think this is a per-bus flag somewhere. If
    > > that's not exported to userspace, should be trivial to do so, should be
    > > somewere in the driver model already...
    > >
    > > Ah, yes, look at the "drivers_autoprobe" and "drivers_probe" files in
    > > sysfs for all busses. Do those not work for you?
    > >
    > > My other points are the fact that you don't want to put policy in the
    > > kernel, and I think that you can do everything you want in userspace
    > > today, except maybe the fact that trying to determine what is "inside"
    > > and "outside" is not always easy given that most hardware does not
    > > export this information properly, if at all. Go work with the firmware
    > > people on that issue please, that would be most helpful for everyone
    > > involved to get that finally straightened out.
    >
    > To sketch this out, my understanding of how this would work is:
    >
    > - Expose the PCI pdev->untrusted bit in sysfs. We don't expose this
    > today, but doing so would be trivial. I think I would prefer a
    > sysfs name like "external" so it's more descriptive and less of a
    > judgment.
    >
    > This comes from either the DT "external-facing" property or the
    > ACPI "ExternalFacingPort" property.

    Good idea, but as people have pointed out, even these don't always work
    so userspace will need to be able to override that somehow :(

    > - All devices present at boot are enumerated. Any statically built
    > drivers will bind to them before any userspace code runs.
    >
    > If you want to keep statically built drivers from binding, you'd
    > need to invent some mechanism so pci_driver_init() could clear
    > drivers_autoprobe after registering pci_bus_type.
    >
    > - Early userspace code prevents modular drivers from automatically
    > binding to PCI devices:
    >
    > echo 0 > /sys/bus/pci/drivers_autoprobe
    >
    > This prevents modular drivers from binding to all devices, whether
    > present at boot or hot-added.
    >
    > - Userspace code uses the sysfs "bind" file to control which drivers
    > are loaded and can bind to each device, e.g.,
    >
    > echo 0000:02:00.0 > /sys/bus/pci/drivers/nvme/bind

    Seems good to me, and also matches what the current USB tools do for
    this type of thing.

    thanks,

    greg k-h

    \
     
     \ /
      Last update: 2020-06-10 09:13    [W:2.885 / U:0.240 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site