From: Bjorn Helgaas <email@example.com> To: Rajat Jain <firstname.lastname@example.org> Cc: Rajat Jain <email@example.com>, Greg Kroah-Hartman <firstname.lastname@example.org>, "Raj, Ashok" <email@example.com>, "Krishnakumar, Lalithambika" <firstname.lastname@example.org>, Bjorn Helgaas <email@example.com>, linux-pci <firstname.lastname@example.org>, Mika Westerberg <email@example.com>, Jean-Philippe Brucker <firstname.lastname@example.org>, Prashant Malani <email@example.com>, Benson Leung <firstname.lastname@example.org>, Todd Broch <email@example.com>, Alex Levin <firstname.lastname@example.org>, Mattias Nissler <email@example.com>, Zubin Mithra <firstname.lastname@example.org>, Bernie Keany <email@example.com>, Aaron Durbin <firstname.lastname@example.org>, Diego Rivas <email@example.com>, Duncan Laurie <firstname.lastname@example.org>, Furquan Shaikh <email@example.com>, Jesse Barnes <firstname.lastname@example.org>, Christian Kellner <email@example.com>, Alex Williamson <firstname.lastname@example.org>, Joerg Roedel <email@example.com>, Linux Kernel Mailing List <firstname.lastname@example.org> Subject: Re: [RFC] Restrict the untrusted devices, to bind to only a set of "whitelisted" drivers Date: Wed, 10 Jun 2020 18:09:06 -0500 Message-ID: <20200610230906.GA1528594@bjorn-Precision-5520> (raw) In-Reply-To: <CAA93t1pFqsi2a-LGP7+eHpCmSvzoDfWEe7KSeFx6wt2caeFA1A@mail.gmail.com> On Wed, Jun 10, 2020 at 01:17:54PM -0700, Rajat Jain wrote: > On Tue, Jun 9, 2020 at 5:30 PM Rajat Jain <email@example.com> wrote: > > > > On Tue, Jun 9, 2020 at 5:04 PM Bjorn Helgaas <firstname.lastname@example.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 <email@example.com> 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. > > > > I realized that we may not need to distinguish between internal and > external devices if we can assume that no internal PCI devices will > show up after boot. That assumption is 99% true for our use case > (leaving 1% out because we have some corner cases i.e. PCIe rescans, > module insertions etc that may probably make some internal devices > disappear and reappear). If I find that I can do without the need for > a UAPI to distinguish internal vs external devices, do you still want > me to fix this edge case (i.e. "break" the pdev->untrusted flag into > "external_facing" and "external" devices)? I'm not sure there's a need to explicitly identify the "external-facing" devices at all. AFAIK there's nothing today that would do anything different with a root port that happens to have an external connector. The "untrusted" uses today are things like forcing use of an IOMMU. Most root ports don't initiate DMA themselves, but even if they did, there's no reason to treat DMA from the root port differently than DMA from other internal devices. What we want is to treat DMA from devices *connected* to that external connector differently. So yes, I think we should change the current behavior so we only set the dev->untrusted flag for devices *downstream* from an external-facing device, but not the external-facing device itself.
next prev parent 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 2020-06-10 20:17 ` Rajat Jain 2020-06-10 23:09 ` Bjorn Helgaas [this message] 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=20200610230906.GA1528594@bjorn-Precision-5520 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.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 \ firstname.lastname@example.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