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 for Android: free password hash cracker in your pocket

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

Message-ID: <CACK8Z6GZprVZMM=JQ-9zjosYQ6OLpifp_g8RmSTa3HwWWTB8Lw@mail.gmail.com>
Date:   Mon, 8 Jun 2020 11:41:19 -0700
From:   Rajat Jain <rajatja@...gle.com>
To:     Jesse Barnes <jsbarnes@...gle.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Rajat Jain <rajatxjain@...il.com>,
        Bjorn Helgaas <helgaas@...nel.org>,
        "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>,
        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

Hi Jesse and Greg,

On Mon, Jun 8, 2020 at 11:30 AM Jesse Barnes <jsbarnes@...gle.com> wrote:
>
> > > I think your suggestion to disable driver binding once the initial
> > > bus/slot devices have been bound will probably work for this
> > > situation.  I just wanted to be clear that without some auditing,
> > > fuzzing, and additional testing, we simply have to assume that drivers
> > > are *not* secure and avoid using them on untrusted devices until we're
> > > fairly confident they can handle them (whether just misbehaving or
> > > malicious), in combination with other approaches like IOMMUs of
> > > course.  And this isn't because we don't trust driver authors or
> > > kernel developers to dtrt, it's just that for many devices (maybe USB
> > > is an exception) I think driver authors haven't had to consider this
> > > case much, and so I think it's prudent to expect bugs in this area
> > > that we need to find & fix.
> >
> > For USB, yes, we have now had to deal with "untrusted devices" lieing
> > about their ids and sending us horrible data.  That's all due to the
> > fuzzing tools that have been written over the past few years, and now we
> > have some of those in the kernel tree itself to help with that testing.

This is great to hear! I tried to look up but didn't find anything
else in-kernel, except the kcov support to export coverage info for
userspace fuzzers. Can you please give us some pointers for in-kernel
fuzzing tools?

> >
> > For PCI, heh, good luck, those assumptions about "devices sending valid
> > data" are everywhere, if our experience with USB is any indication.
> >
> > But, to take USB as an example, this is exactly what the USB
> > "authorized" flag is there for, it's a "trust" setting that userspace
> > has control over.  This came from the wireless USB spec, where it was
> > determined that you could not trust devices.  So just use that same
> > model here, move it to the driver core for all busses to use and you
> > should be fine.
> >
> > If that doesn't meet your needs, please let me know the specifics of
> > why, with patches :)
>
> Yeah will do for sure.  I don't want to carry a big infra for this on our own!
>
> > Now, as to you all getting some sort of "Hardware flag" to determine
> > "inside" vs. "outside" devices, hah, good luck!  It took us a long time
> > to get that for USB, and even then, BIOSes lie and get it wrong all the
> > time.  So you will have to also deal with that in some way, for your
> > userspace policy.
>
> I think that's inherently platform specific to some extent.  We can do
> it with our coreboot based firmware, but there's no guarantee other
> vendors will adopt the same approach.  But I think at least for the
> ChromeOS ecosystem we can come up with something that'll work, and
> allow us to dtrt in userspace wrt driver binding.

Agree, we can work with our firmware teams to get that right, and then
expose it from kernel to userspace to help it implement the policy we
want.

Thanks & Best Regards,

Rajat

>
> Thanks,
> Jesse