All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Andi Kleen <ak@linux.intel.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Kuppuswamy Sathyanarayanan 
	<sathyanarayanan.kuppuswamy@linux.intel.com>,
	Borislav Petkov <bp@alien8.de>,
	x86@kernel.org, Bjorn Helgaas <bhelgaas@google.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Andreas Noever <andreas.noever@gmail.com>,
	Michael Jamet <michael.jamet@intel.com>,
	Yehezkel Bernat <YehezkelShB@gmail.com>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Jason Wang <jasowang@redhat.com>,
	Dan Williams <dan.j.williams@intel.com>,
	Kuppuswamy Sathyanarayanan <knsathya@kernel.org>,
	linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
	linux-usb@vger.kernel.org,
	virtualization@lists.linux-foundation.org, "Reshetova,
	Elena" <elena.reshetova@intel.com>
Subject: Re: [PATCH v2 2/6] driver core: Add common support to skip probe for un-authorized devices
Date: Fri, 1 Oct 2021 11:51:43 -0400	[thread overview]
Message-ID: <20211001155143.GB505557@rowland.harvard.edu> (raw)
In-Reply-To: <YVaq0Hm8WHVY46xX@kroah.com>

On Fri, Oct 01, 2021 at 08:29:36AM +0200, Greg Kroah-Hartman wrote:
> On Thu, Sep 30, 2021 at 12:15:16PM -0700, Andi Kleen wrote:
> > 
> > On 9/30/2021 10:23 AM, Greg Kroah-Hartman wrote:
> > > On Thu, Sep 30, 2021 at 10:17:09AM -0700, Andi Kleen wrote:
> > > > The legacy drivers could be fixed, but nobody really wants to touch them
> > > > anymore and they're impossible to test.
> > > Pointers to them?
> > 
> > For example if you look over old SCSI drivers in drivers/scsi/*.c there is a
> > substantial number that has a module init longer than just registering a
> > driver. As a single example look at drivers/scsi/BusLogic.c
> 
> Great, send patches to fix them up instead of adding new infrastructure
> to the kernel.  It is better to remove code than add it.  You can rip
> the ISA code out of that driver and then you will not have the issue
> anymore.
> 
> Or again, just add that module to the deny list and never load it from
> userspace.
> 
> > There were also quite a few platform drivers like this.
> 
> Of course, platform drivers are horrible abusers of this.  Just like the
> recent one submitted by Intel that would bind to any machine it was
> loaded on and did not actually do any hardware detection assuming that
> it owned the platform:
> 	https://lore.kernel.org/r/20210924213157.3584061-2-david.e.box@linux.intel.com
> 
> So yes, some drivers are horrible, it is our job to catch that and fix
> it.  If you don't want to load those drivers on your system, we have
> userspace solutions for that (you can have allow/deny lists there.)
> 
> > > > The drivers that probe something that is not enumerated in a standard way
> > > > have no choice, it cannot be implemented in a different way.
> > > PCI devices are not enumerated in a standard way???
> > 
> > The pci devices are enumerated in a standard way, but typically the driver
> > also needs something else outside PCI that needs some other probing
> > mechanism.
> 
> Like what?  What PCI drivers need outside connections to control the
> hardware?
> 
> > > > So instead we're using a "firewall" the prevents these drivers from doing
> > > > bad things by not allowing ioremap access unless opted in, and also do some
> > > > filtering on the IO ports The device filter is still the primary mechanism,
> > > > the ioremap filtering is just belts and suspenders for those odd cases.
> > > That's horrible, don't try to protect the kernel from itself.  Just fix
> > > the drivers.
> > 
> > I thought we had already established this last time we discussed it.
> > 
> > That's completely impractical. We cannot harden thousands of drivers,
> > especially since it would be all wasted work since nobody will ever need
> > them in virtual guests. Even if we could harden them how would such a work
> > be maintained long term? Using a firewall and filtering mechanism is much
> > saner for everyone.
> 
> I agree, you can not "harden" anything here.  That is why I asked you to
> use the existing process that explicitly moves the model to userspace
> where a user can say "do I want this device to be controlled by the
> kernel or not" which then allows you to pick and choose what drivers you
> want to have in your system.
> 
> You need to trust devices, and not worry about trusting drivers as you
> yourself admit :)

That isn't the way they see it.  In their approach you can never 
trust any devices at all.  Therefore devices can only be allowed to 
bind to a very small set of "hardened" drivers.  Never mind how they 
decide whether or not a driver is sufficiently "hardened".

> The kernel's trust model is that once we bind to them, we trust almost
> all device types almost explicitly.  If you wish to change that model,
> that's great, but it is a much larger discussion than this tiny patchset
> would require.

Forget about trust for the moment.  Let's say the goal is to prevent 
the kernel from creating any bindings other that those in some small 
"allowed" set.  To fully specify one of the allowed bindings, you 
would have to provide both a device ID and a driver name.  But in 
practice this isn't necessary, since a device with a given ID will 
bind to only one driver in almost all cases, and hence giving just 
the device ID is enough.

So to do what they want, all that's needed is to forbid any bindings 
except where the device ID is "allowed".  Or to put it another way, 
where the device's authorized flag (which can be initialized based on 
the device ID) is set.

(The opposite approach, in which the drivers are "allowed" rather 
than the device IDs, apparently has already been discussed and 
rejected.  I'm not convinced that was a good decision, but...)

Does this seem like a fair description of the situation?

Alan Stern

WARNING: multiple messages have this Message-ID
From: Alan Stern <stern@rowland.harvard.edu>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Kuppuswamy Sathyanarayanan
	<sathyanarayanan.kuppuswamy@linux.intel.com>,
	Kuppuswamy Sathyanarayanan <knsathya@kernel.org>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	linux-pci@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Andreas Noever <andreas.noever@gmail.com>,
	Dan Williams <dan.j.williams@intel.com>,
	"Reshetova, Elena" <elena.reshetova@intel.com>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	Andi Kleen <ak@linux.intel.com>, Jonathan Corbet <corbet@lwn.net>,
	x86@kernel.org, Ingo Molnar <mingo@redhat.com>,
	Michael Jamet <michael.jamet@intel.com>,
	Borislav Petkov <bp@alien8.de>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
	Yehezkel Bernat <YehezkelShB@gmail.com>
Subject: Re: [PATCH v2 2/6] driver core: Add common support to skip probe for un-authorized devices
Date: Fri, 1 Oct 2021 11:51:43 -0400	[thread overview]
Message-ID: <20211001155143.GB505557@rowland.harvard.edu> (raw)
In-Reply-To: <YVaq0Hm8WHVY46xX@kroah.com>

On Fri, Oct 01, 2021 at 08:29:36AM +0200, Greg Kroah-Hartman wrote:
> On Thu, Sep 30, 2021 at 12:15:16PM -0700, Andi Kleen wrote:
> > 
> > On 9/30/2021 10:23 AM, Greg Kroah-Hartman wrote:
> > > On Thu, Sep 30, 2021 at 10:17:09AM -0700, Andi Kleen wrote:
> > > > The legacy drivers could be fixed, but nobody really wants to touch them
> > > > anymore and they're impossible to test.
> > > Pointers to them?
> > 
> > For example if you look over old SCSI drivers in drivers/scsi/*.c there is a
> > substantial number that has a module init longer than just registering a
> > driver. As a single example look at drivers/scsi/BusLogic.c
> 
> Great, send patches to fix them up instead of adding new infrastructure
> to the kernel.  It is better to remove code than add it.  You can rip
> the ISA code out of that driver and then you will not have the issue
> anymore.
> 
> Or again, just add that module to the deny list and never load it from
> userspace.
> 
> > There were also quite a few platform drivers like this.
> 
> Of course, platform drivers are horrible abusers of this.  Just like the
> recent one submitted by Intel that would bind to any machine it was
> loaded on and did not actually do any hardware detection assuming that
> it owned the platform:
> 	https://lore.kernel.org/r/20210924213157.3584061-2-david.e.box@linux.intel.com
> 
> So yes, some drivers are horrible, it is our job to catch that and fix
> it.  If you don't want to load those drivers on your system, we have
> userspace solutions for that (you can have allow/deny lists there.)
> 
> > > > The drivers that probe something that is not enumerated in a standard way
> > > > have no choice, it cannot be implemented in a different way.
> > > PCI devices are not enumerated in a standard way???
> > 
> > The pci devices are enumerated in a standard way, but typically the driver
> > also needs something else outside PCI that needs some other probing
> > mechanism.
> 
> Like what?  What PCI drivers need outside connections to control the
> hardware?
> 
> > > > So instead we're using a "firewall" the prevents these drivers from doing
> > > > bad things by not allowing ioremap access unless opted in, and also do some
> > > > filtering on the IO ports The device filter is still the primary mechanism,
> > > > the ioremap filtering is just belts and suspenders for those odd cases.
> > > That's horrible, don't try to protect the kernel from itself.  Just fix
> > > the drivers.
> > 
> > I thought we had already established this last time we discussed it.
> > 
> > That's completely impractical. We cannot harden thousands of drivers,
> > especially since it would be all wasted work since nobody will ever need
> > them in virtual guests. Even if we could harden them how would such a work
> > be maintained long term? Using a firewall and filtering mechanism is much
> > saner for everyone.
> 
> I agree, you can not "harden" anything here.  That is why I asked you to
> use the existing process that explicitly moves the model to userspace
> where a user can say "do I want this device to be controlled by the
> kernel or not" which then allows you to pick and choose what drivers you
> want to have in your system.
> 
> You need to trust devices, and not worry about trusting drivers as you
> yourself admit :)

That isn't the way they see it.  In their approach you can never 
trust any devices at all.  Therefore devices can only be allowed to 
bind to a very small set of "hardened" drivers.  Never mind how they 
decide whether or not a driver is sufficiently "hardened".

> The kernel's trust model is that once we bind to them, we trust almost
> all device types almost explicitly.  If you wish to change that model,
> that's great, but it is a much larger discussion than this tiny patchset
> would require.

Forget about trust for the moment.  Let's say the goal is to prevent 
the kernel from creating any bindings other that those in some small 
"allowed" set.  To fully specify one of the allowed bindings, you 
would have to provide both a device ID and a driver name.  But in 
practice this isn't necessary, since a device with a given ID will 
bind to only one driver in almost all cases, and hence giving just 
the device ID is enough.

So to do what they want, all that's needed is to forbid any bindings 
except where the device ID is "allowed".  Or to put it another way, 
where the device's authorized flag (which can be initialized based on 
the device ID) is set.

(The opposite approach, in which the drivers are "allowed" rather 
than the device IDs, apparently has already been discussed and 
rejected.  I'm not convinced that was a good decision, but...)

Does this seem like a fair description of the situation?

Alan Stern
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

  reply	other threads:[~2021-10-01 15:51 UTC|newest]

Thread overview: 132+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-30  1:05 [PATCH v2 0/6] Add device filter support Kuppuswamy Sathyanarayanan
2021-09-30  1:05 ` [PATCH v2 1/6] driver core: Move the "authorized" attribute from USB/Thunderbolt to core Kuppuswamy Sathyanarayanan
2021-09-30  1:42   ` Alan Stern
2021-09-30  1:42     ` Alan Stern
2021-09-30  1:55     ` Dan Williams
2021-09-30  1:55       ` Dan Williams
2021-09-30  2:38       ` Kuppuswamy, Sathyanarayanan
2021-09-30  4:59         ` Dan Williams
2021-09-30  4:59           ` Dan Williams
2021-09-30  9:05           ` Rafael J. Wysocki
2021-09-30  9:05             ` Rafael J. Wysocki
2021-09-30 14:59       ` Alan Stern
2021-09-30 14:59         ` Alan Stern
2021-09-30 15:25         ` Dan Williams
2021-09-30 15:25           ` Dan Williams
2021-09-30 11:19   ` Yehezkel Bernat
2021-09-30 15:28     ` Dan Williams
2021-09-30 15:28       ` Dan Williams
2021-09-30 18:25       ` Yehezkel Bernat
2021-09-30 19:04         ` Dan Williams
2021-09-30 19:04           ` Dan Williams
2021-09-30 19:50           ` Kuppuswamy, Sathyanarayanan
2021-09-30 20:23             ` Dan Williams
2021-09-30 20:23               ` Dan Williams
2021-09-30  1:05 ` [PATCH v2 2/6] driver core: Add common support to skip probe for un-authorized devices Kuppuswamy Sathyanarayanan
2021-09-30 10:59   ` Michael S. Tsirkin
2021-09-30 10:59     ` Michael S. Tsirkin
2021-09-30 13:52     ` Greg Kroah-Hartman
2021-09-30 13:52       ` Greg Kroah-Hartman
2021-09-30 14:38       ` Michael S. Tsirkin
2021-09-30 14:38         ` Michael S. Tsirkin
2021-09-30 14:49         ` Greg Kroah-Hartman
2021-09-30 14:49           ` Greg Kroah-Hartman
2021-09-30 15:00           ` Michael S. Tsirkin
2021-09-30 15:00             ` Michael S. Tsirkin
2021-09-30 15:22             ` Greg Kroah-Hartman
2021-09-30 15:22               ` Greg Kroah-Hartman
2021-09-30 17:17               ` Andi Kleen
2021-09-30 17:17                 ` Andi Kleen
2021-09-30 17:23                 ` Greg Kroah-Hartman
2021-09-30 17:23                   ` Greg Kroah-Hartman
2021-09-30 19:15                   ` Andi Kleen
2021-09-30 19:15                     ` Andi Kleen
2021-10-01  6:29                     ` Greg Kroah-Hartman
2021-10-01  6:29                       ` Greg Kroah-Hartman
2021-10-01 15:51                       ` Alan Stern [this message]
2021-10-01 15:51                         ` Alan Stern
2021-10-01 15:56                         ` Andi Kleen
2021-10-01 15:56                           ` Andi Kleen
2021-09-30 14:43       ` Alan Stern
2021-09-30 14:43         ` Alan Stern
2021-09-30 14:48         ` Michael S. Tsirkin
2021-09-30 14:48           ` Michael S. Tsirkin
2021-09-30 15:32           ` Alan Stern
2021-09-30 15:32             ` Alan Stern
2021-09-30 15:52             ` Michael S. Tsirkin
2021-09-30 15:52               ` Michael S. Tsirkin
2021-09-30 14:58         ` Michael S. Tsirkin
2021-09-30 14:58           ` Michael S. Tsirkin
2021-09-30 15:35           ` Alan Stern
2021-09-30 15:35             ` Alan Stern
2021-09-30 15:59             ` Michael S. Tsirkin
2021-09-30 15:59               ` Michael S. Tsirkin
2021-09-30 19:23               ` Andi Kleen
2021-09-30 19:23                 ` Andi Kleen
2021-09-30 20:44                 ` Alan Stern
2021-09-30 20:44                   ` Alan Stern
2021-09-30 20:52                   ` Dan Williams
2021-09-30 20:52                     ` Dan Williams
2021-10-01  1:41                     ` Alan Stern
2021-10-01  1:41                       ` Alan Stern
2021-10-01  2:20                       ` Dan Williams
2021-10-01  2:20                         ` Dan Williams
2021-09-30 21:12                   ` Andi Kleen
2021-09-30 21:12                     ` Andi Kleen
2021-09-30  1:05 ` [PATCH v2 3/6] driver core: Allow arch to initialize the authorized attribute Kuppuswamy Sathyanarayanan
2021-09-30  1:05 ` [PATCH v2 4/6] virtio: Initialize authorized attribute for confidential guest Kuppuswamy Sathyanarayanan
2021-09-30 11:03   ` Michael S. Tsirkin
2021-09-30 11:03     ` Michael S. Tsirkin
2021-09-30 13:36     ` Dan Williams
2021-09-30 13:36       ` Dan Williams
2021-09-30 13:49       ` Greg Kroah-Hartman
2021-09-30 13:49         ` Greg Kroah-Hartman
2021-09-30 15:18       ` Kuppuswamy, Sathyanarayanan
2021-09-30 15:20         ` Michael S. Tsirkin
2021-09-30 15:20           ` Michael S. Tsirkin
2021-09-30 15:23           ` Kuppuswamy, Sathyanarayanan
2021-09-30 15:23         ` Greg Kroah-Hartman
2021-09-30 15:23           ` Greg Kroah-Hartman
2021-09-30 19:04           ` Kuppuswamy, Sathyanarayanan
2021-09-30 19:16             ` Kuppuswamy, Sathyanarayanan
2021-09-30 19:30             ` Andi Kleen
2021-09-30 19:30               ` Andi Kleen
2021-09-30 19:40               ` Kuppuswamy, Sathyanarayanan
2021-10-01  7:03             ` Greg Kroah-Hartman
2021-10-01  7:03               ` Greg Kroah-Hartman
2021-10-01 15:49               ` Andi Kleen
2021-10-01 15:49                 ` Andi Kleen
2021-10-02 11:04                 ` Michael S. Tsirkin
2021-10-02 11:04                   ` Michael S. Tsirkin
2021-10-02 11:14                   ` Greg Kroah-Hartman
2021-10-02 11:14                     ` Greg Kroah-Hartman
2021-10-02 14:20                     ` Andi Kleen
2021-10-02 14:20                       ` Andi Kleen
2021-10-02 14:44                       ` Greg Kroah-Hartman
2021-10-02 14:44                         ` Greg Kroah-Hartman
2021-10-02 18:40                       ` Michael S. Tsirkin
2021-10-02 18:40                         ` Michael S. Tsirkin
2021-10-03  6:40                         ` Greg Kroah-Hartman
2021-10-03  6:40                           ` Greg Kroah-Hartman
2021-10-04 21:04                       ` Dan Williams
2021-10-04 21:04                         ` Dan Williams
2021-10-01 16:13               ` Dan Williams
2021-10-01 16:13                 ` Dan Williams
2021-10-01 16:45                 ` Alan Stern
2021-10-01 16:45                   ` Alan Stern
2021-10-01 18:09                   ` Dan Williams
2021-10-01 18:09                     ` Dan Williams
2021-10-01 19:00                     ` Alan Stern
2021-10-01 19:00                       ` Alan Stern
2021-10-01 19:45                       ` Kuppuswamy, Sathyanarayanan
2021-10-01 19:57                       ` Dan Williams
2021-10-01 19:57                         ` Dan Williams
2021-10-04  5:16                         ` Mika Westerberg
2021-10-05 22:33                           ` Dan Williams
2021-10-05 22:33                             ` Dan Williams
2021-10-06  5:45                             ` Greg Kroah-Hartman
2021-10-06  5:45                               ` Greg Kroah-Hartman
2021-09-30 19:25         ` Andi Kleen
2021-09-30 19:25           ` Andi Kleen
2021-09-30  1:05 ` [PATCH v2 5/6] x86/tdx: Add device filter support for x86 TDX guest platform Kuppuswamy Sathyanarayanan
2021-09-30  1:05 ` [PATCH v2 6/6] PCI: Initialize authorized attribute for confidential guest Kuppuswamy Sathyanarayanan

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=20211001155143.GB505557@rowland.harvard.edu \
    --to=stern@rowland.harvard.edu \
    --cc=YehezkelShB@gmail.com \
    --cc=ak@linux.intel.com \
    --cc=andreas.noever@gmail.com \
    --cc=bhelgaas@google.com \
    --cc=bp@alien8.de \
    --cc=corbet@lwn.net \
    --cc=dan.j.williams@intel.com \
    --cc=elena.reshetova@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jasowang@redhat.com \
    --cc=knsathya@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=michael.jamet@intel.com \
    --cc=mika.westerberg@linux.intel.com \
    --cc=mingo@redhat.com \
    --cc=mst@redhat.com \
    --cc=rafael@kernel.org \
    --cc=sathyanarayanan.kuppuswamy@linux.intel.com \
    --cc=tglx@linutronix.de \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=x86@kernel.org \
    --subject='Re: [PATCH v2 2/6] driver core: Add common support to skip probe for un-authorized devices' \
    /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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.