lkml.org 
[lkml]   [2020]   [Jun]   [9]   [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:23:54PM -0700, Rajat Jain wrote:
> Hi Bjorn,
>
> Thanks for sending out the summary, I was about to send it out but got lazy.
>
> On Tue, Jun 9, 2020 at 2:04 PM Bjorn Helgaas <helgaas@kernel.org> 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.
>
> Yes. I think we should probably semantically differentiate between
> "external" and "external facing" devices. Root ports and downstream
> ports can be "external facing" but are actually internal devices.
> Anything below an "external facing" device is "external". So the sysfs
> attribute "external" should be set only for devices that are truly
> external.

Good point; we (maybe you? :)) should fix that edge case.

> Just a suggestion: Do you think an enum attribute may be better
> instead, whose values could be "internal" / "external" /
> "external-facing" in case need arises later to distinguish between
> them?

I don't see the need for an enum yet. Maybe we should add that
if/when we do need it?

> > - Early userspace code prevents modular drivers from automatically
> > binding to PCI devices:
> >
> > echo 0 > /sys/bus/pci/drivers_autoprobe
>
> Yes.
> I believe this setting will apply it equally to both modular and
> statically linked drivers?

Yes. The test is in bus_probe_device(), and it does the same for both
modular and statically linked drivers.

But for statically linked drivers, it only prevents them from binding
to *hot-added* devices. They will claim devices present at boot even
before userspace code can run.

> The one thing that still needs more thought is how about the
> "pcieport" driver that enumerates the PCI bridges. I'm unsure if it
> needs to be whitelisted for further enumeration downstream. What do
> you think?

The pcieport driver is required for AER, PCIe native hotplug, PME,
etc., and it cannot be a module, so the whitelist wouldn't apply to
it. I assume you need hotplug support, so you would have pcieport
enabled and built in statically.

If you're using ACPI hotplug, that doesn't require pcieport.

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