linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@denx.de>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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 10:47:50 +0200	[thread overview]
Message-ID: <20200701084750.GA7144@amd> (raw)
In-Reply-To: <20200701065426.GC2044019@kroah.com>

[-- Attachment #1: Type: text/plain, Size: 2092 bytes --]

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.

We probably should work on robustness against malicious USB devices.

Malicious PCI-express devices are lot less of concern.

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

Notice that it is quite easy to generate -100V on the USB and kill
your motherboard. Also notice that malicious parts of the hardware
don't need to be electrically connected to the rest of system, and
that they don't even have to contain any electronics. You just have to
be careful. https://en.wikipedia.org/wiki/The_Thing_(listening_device)

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

  reply	other threads:[~2020-07-01  8:47 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 [this message]
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
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=20200701084750.GA7144@amd \
    --to=pavel@denx.de \
    --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=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).