Linux-PCI Archive on lore.kernel.org
 help / color / Atom feed
From: Rajat Jain <rajatja@google.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Rajat Jain <rajatxjain@gmail.com>,
	"Raj, Ashok" <ashok.raj@intel.com>,
	"Krishnakumar,
	Lalithambika" <lalithambika.krishnakumar@intel.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	linux-pci <linux-pci@vger.kernel.org>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Jean-Philippe Brucker <jean-philippe@linaro.org>,
	Prashant Malani <pmalani@google.com>,
	Benson Leung <bleung@google.com>, Todd Broch <tbroch@google.com>,
	Alex Levin <levinale@google.com>,
	Mattias Nissler <mnissler@google.com>,
	Zubin Mithra <zsm@google.com>,
	Bernie Keany <bernie.keany@intel.com>,
	Aaron Durbin <adurbin@google.com>,
	Diego Rivas <diegorivas@google.com>,
	Duncan Laurie <dlaurie@google.com>,
	Furquan Shaikh <furquan@google.com>,
	Jesse Barnes <jsbarnes@google.com>,
	Christian Kellner <christian@kellner.me>,
	Alex Williamson <alex.williamson@redhat.com>,
	Joerg Roedel <joro@8bytes.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] Restrict the untrusted devices, to bind to only a set of "whitelisted" drivers
Date: Tue, 9 Jun 2020 17:30:13 -0700
Message-ID: <CACK8Z6G3ycsXxuNiihOXiwwAum8=5aOFOshhFa7cEF__+c-v1A@mail.gmail.com> (raw)
In-Reply-To: <20200610000400.GA1473845@bjorn-Precision-5520>

On Tue, Jun 9, 2020 at 5:04 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
>
> 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.

Sure, happy to. I will start a fresh conversation about that (in a
separate thread).

>
> > 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?

Sure, no problems. (I just wanted to slip the thought into the
conversation as UAPI is hard to change later).

>
> > >   - 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.

Yes, understood.

>
> > 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.

Not that I see the need, but slight clarification needed just to make
sure I understand it clearly:

Since pcieport driver is statically compiled in, AER, pciehp, PME, DPC
etc will always be enabled for devices plugged in during boot. But I
can still choose to choose to allow or deny for devices added *after
boot* using the whitelist, right?

Also, denying pcieport driver for hot-added PCIe bridges only disables
these pcieport services on those bridges, but device enumeration
further downstream those bridges is not an issue?

> 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.

Thank you, this was indeed a long and useful thread :-)

Best Regards,

Rajat

  reply index

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-01 23:07 Rajat Jain
2020-05-04 11:47 ` Jean-Philippe Brucker
2020-05-04 11:59   ` Jean-Philippe Brucker
2020-05-04 19:17     ` Rajat Jain
2020-05-05 12:33 ` Mika Westerberg
2020-05-06 18:51   ` Rajat Jain
2020-05-11 20:31 ` Rajat Jain
2020-05-13 15:19 ` Bjorn Helgaas
2020-05-13 21:26   ` Rajat Jain
2020-05-14 13:42     ` Mika Westerberg
2020-05-14 19:12     ` Raj, Ashok
2020-05-15  2:18       ` Rajat Jain
2020-05-26 16:30         ` Rajat Jain
2020-06-01 23:25           ` Bjorn Helgaas
2020-06-02  5:06             ` Greg Kroah-Hartman
2020-06-03  2:27               ` Rajat Jain
2020-06-03  6:07                 ` Greg Kroah-Hartman
2020-06-03 11:51                   ` Rajat Jain
2020-06-03 12:16                     ` Greg Kroah-Hartman
2020-06-03 12:57                       ` Rajat Jain
2020-06-03 13:29                         ` Greg Kroah-Hartman
2020-06-04 19:38                       ` Rajat Jain
2020-06-05  8:02                         ` Greg Kroah-Hartman
2020-06-06  1:08                           ` Rajat Jain
2020-06-07 11:36                             ` Greg Kroah-Hartman
2020-06-08 17:03                               ` Jesse Barnes
2020-06-08 17:50                                 ` Greg Kroah-Hartman
2020-06-08 18:29                                   ` Jesse Barnes
2020-06-08 18:41                                     ` Rajat Jain
2020-06-09  9:54                                       ` Greg Kroah-Hartman
2020-06-30 21:46                                         ` Pavel Machek
2020-06-09  5:57                                     ` Greg Kroah-Hartman
2020-06-30 21:45                                 ` Pavel Machek
2020-07-01  6:54                                   ` Greg Kroah-Hartman
2020-07-01  8:47                                     ` Pavel Machek
2020-07-01 10:57                                       ` Greg Kroah-Hartman
2020-07-01 11:08                                         ` Pavel Machek
2020-06-09 21:04                               ` Bjorn Helgaas
2020-06-09 23:23                                 ` Rajat Jain
2020-06-10  0:04                                   ` Bjorn Helgaas
2020-06-10  0:30                                     ` Rajat Jain [this message]
2020-06-10 20:17                                       ` Rajat Jain
2020-06-10 23:09                                         ` Bjorn Helgaas
2020-06-10 23:01                                       ` Bjorn Helgaas
2020-06-10 23:46                                         ` Rajat Jain
2020-06-10  7:13                                   ` Greg Kroah-Hartman
2020-06-10  1:34                                 ` Oliver O'Halloran
2020-06-10 19:57                                   ` Rajat Jain
2020-06-16  1:24                                     ` Rajat Jain
2020-06-10  7:12                                 ` Greg Kroah-Hartman
2020-05-15 12:44     ` Joerg Roedel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CACK8Z6G3ycsXxuNiihOXiwwAum8=5aOFOshhFa7cEF__+c-v1A@mail.gmail.com' \
    --to=rajatja@google.com \
    --cc=adurbin@google.com \
    --cc=alex.williamson@redhat.com \
    --cc=ashok.raj@intel.com \
    --cc=bernie.keany@intel.com \
    --cc=bhelgaas@google.com \
    --cc=bleung@google.com \
    --cc=christian@kellner.me \
    --cc=diegorivas@google.com \
    --cc=dlaurie@google.com \
    --cc=furquan@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=helgaas@kernel.org \
    --cc=jean-philippe@linaro.org \
    --cc=joro@8bytes.org \
    --cc=jsbarnes@google.com \
    --cc=lalithambika.krishnakumar@intel.com \
    --cc=levinale@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=mnissler@google.com \
    --cc=pmalani@google.com \
    --cc=rajatxjain@gmail.com \
    --cc=tbroch@google.com \
    --cc=zsm@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-PCI Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-pci/0 linux-pci/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-pci linux-pci/ https://lore.kernel.org/linux-pci \
		linux-pci@vger.kernel.org
	public-inbox-index linux-pci

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-pci


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git