linux-kernel - Re: [RFC] Restrict the untrusted devices, to bind to only a set of "whitelisted" drivers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAOSf1CGMwHGSn18MeKYr2BESfLwq3Q8_0fC6yhiQRrAXeSosqQ@mail.gmail.com>
Date:   Wed, 10 Jun 2020 11:34:06 +1000
From:   "Oliver O'Halloran" <oohall@...il.com>
To:     Bjorn Helgaas <helgaas@...nel.org>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Rajat Jain <rajatja@...gle.com>,
        Rajat Jain <rajatxjain@...il.com>,
        "Raj, Ashok" <ashok.raj@...el.com>,
        "Krishnakumar, Lalithambika" <lalithambika.krishnakumar@...el.com>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        linux-pci <linux-pci@...r.kernel.org>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Jean-Philippe Brucker <jean-philippe@...aro.org>,
        Prashant Malani <pmalani@...gle.com>,
        Benson Leung <bleung@...gle.com>,
        Todd Broch <tbroch@...gle.com>,
        Alex Levin <levinale@...gle.com>,
        Mattias Nissler <mnissler@...gle.com>,
        Zubin Mithra <zsm@...gle.com>,
        Bernie Keany <bernie.keany@...el.com>,
        Aaron Durbin <adurbin@...gle.com>,
        Diego Rivas <diegorivas@...gle.com>,
        Duncan Laurie <dlaurie@...gle.com>,
        Furquan Shaikh <furquan@...gle.com>,
        Jesse Barnes <jsbarnes@...gle.com>,
        Christian Kellner <christian@...lner.me>,
        Alex Williamson <alex.williamson@...hat.com>,
        Joerg Roedel <joro@...tes.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] Restrict the untrusted devices, to bind to only a set of
 "whitelisted" drivers

On Wed, Jun 10, 2020 at 7:04 AM Bjorn Helgaas <helgaas@...nel.org> wrote:
>
> 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.

I don't think internal / external is the right distinction to be
making. We have a similar trust issue with the BMC in servers even
though they're internal devices. They're typically network accessible
and infrequently updated so treating them as trustworthy isn't a great
idea. We have been slowly de-privileging the BMC over the last few
years, but the PCIe interface isn't locked down enough for my liking
since the SoCs we use do allow software to set the VDID and perform
arbitrary DMAs (thankfully limited to 32bit). If we're going to add in
infrastructure for handling possibly untrustworthy PCI devices then
I'd like to use that for BMCs too.

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

I don't see why this is preferable to just disabling autoprobe for
untrusted devices. That would dovetail nicely with Rajat's whitelist
idea if we want to go down that route and I think we might want to.
The BMC usually provides some form of VGA console and we'd like that
to continue working out-of-the-box without too much user (or distro)
intervention.

Oliver