linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Pavel Machek <pavel@denx.de>
Cc: Jesse Barnes <jsbarnes@google.com>,
	Rajat Jain <rajatja@google.com>,
	Rajat Jain <rajatxjain@gmail.com>,
	Bjorn Helgaas <helgaas@kernel.org>,
	"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>,
	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: Wed, 1 Jul 2020 12:57:14 +0200	[thread overview]
Message-ID: <20200701105714.GA2098169@kroah.com> (raw)
In-Reply-To: <20200701084750.GA7144@amd>

On Wed, Jul 01, 2020 at 10:47:50AM +0200, Pavel Machek wrote:
> Hi!
> 
> > > We normally trust the hardware NOT to be malicious. (Because if hacker
> > > has physical access to hardware and lot of resources, you lost).
> > 
> > That is what we originally thought, however the world has changed and we
> > need to be better about this, now that it is trivial to create a "bad"
> > device.
> 
> I'm not disagreeing.
> 
> > > This is still true today, but maybe trusting USB devices is bad idea,
> > > so drivers are being cleaned up. PCI drivers will be WORSE in this
> > > regard. And you can't really protect against malicious CPU, and it is
> > > very very hard to protect against malicous RAM (probably not practical
> > > without explicit CPU support).
> > > 
> > > Linux was designed with "don't let hackers near your hardware" threat
> > > model in mind.
> > 
> > Yes, it originally was designed that way, but again, the world has
> > changed so we have to change with it.  That is why USB has for a long
> > time now, allowed you to not bind drivers to devices that you do not
> > "trust", and that trust can be determined by userspace.  That all came
> > about thanks to the work done by the wireless USB spec people and kernel
> > authors, which showed that maybe you just don't want to trust any device
> > that comes within range of your system :)
> 
> Again, not disagreeing; but note the scale here.
> 
> It is mandatory to defend against malicious wireless USB devices.

Turns out there are no more wireless USB devices in the world, and the
code for that is gone from Linux :)

> We probably should work on robustness against malicious USB devices.

We are, and do have, that support today.

> Malicious PCI-express devices are lot less of concern.

Not really, they are a lot of concern to some people.  Valid attacks are
out there today, see the thunderbolt attacks that numerous people have
done and published recently and for many years.

> Defending against malicious CPU/RAM does not make much sense.

That's what the spectre and rowhammer fixes have been for :)

thanks,

greg k-h

  reply	other threads:[~2020-07-01 10:57 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CACK8Z6F3jE-aE+N7hArV3iye+9c-COwbi3qPkRPxfrCnccnqrw@mail.gmail.com>
2020-06-01 23:25 ` [RFC] Restrict the untrusted devices, to bind to only a set of "whitelisted" drivers 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 [this message]
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
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

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=20200701105714.GA2098169@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --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=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=pavel@denx.de \
    --cc=pmalani@google.com \
    --cc=rajatja@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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).