From: Dan Williams <dan.j.williams@intel.com> To: Alan Stern <stern@rowland.harvard.edu> Cc: Andi Kleen <ak@linux.intel.com>, "Michael S. Tsirkin" <mst@redhat.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>, Borislav Petkov <bp@alien8.de>, X86 ML <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>, Kuppuswamy Sathyanarayanan <knsathya@kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Linux PCI <linux-pci@vger.kernel.org>, USB list <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: Thu, 30 Sep 2021 19:20:04 -0700 [thread overview] Message-ID: <CAPcyv4iRo0Hd=_3jAScb5KUEJp3bU=QrWM8FYeb94SzO4gqgJA@mail.gmail.com> (raw) In-Reply-To: <20211001014114.GB489012@rowland.harvard.edu> On Thu, Sep 30, 2021 at 6:41 PM Alan Stern <stern@rowland.harvard.edu> wrote: > > On Thu, Sep 30, 2021 at 01:52:59PM -0700, Dan Williams wrote: > > On Thu, Sep 30, 2021 at 1:44 PM Alan Stern <stern@rowland.harvard.edu> wrote: > > > > > > On Thu, Sep 30, 2021 at 12:23:36PM -0700, Andi Kleen wrote: > > > > > > > > > I don't think the current mitigations under discussion here are about > > > > > keeping the system working. In fact most encrypted VM configs tend to > > > > > stop booting as a preferred way to handle security issues. > > > > > > > > Maybe we should avoid the "trusted" term here. We're only really using it > > > > because USB is using it and we're now using a common framework like Greg > > > > requested. But I don't think it's the right way to think about it. > > > > > > > > We usually call the drivers "hardened". The requirement for a hardened > > > > driver is that all interactions through MMIO/port/config space IO/MSRs are > > > > sanitized and do not cause memory safety issues or other information leaks. > > > > Other than that there is no requirement on the functionality. In particular > > > > DOS is ok since a malicious hypervisor can decide to not run the guest at > > > > any time anyways. > > > > > > > > Someone loading an malicious driver inside the guest would be out of scope. > > > > If an attacker can do that inside the guest you already violated the > > > > security mechanisms and there are likely easier ways to take over the guest > > > > or leak data. > > > > > > > > The goal of the device filter mechanism is to prevent loading unhardened > > > > drivers that could be exploited without them being themselves malicious. > > > > > > If all you want to do is prevent someone from loading a bunch of > > > drivers that you have identified as unhardened, why not just use a > > > modprobe blacklist? Am I missing something? > > > > modules != drivers (i.e. multi-driver modules are a thing) and builtin > > modules do not adhere to modprobe policy. > > > > There is also a desire to be able to support a single kernel image > > across hosts and guests. So, if you were going to say, "just compile > > all unnecessary drivers as modules" that defeats the common kernel > > image goal. For confidential computing the expectation is that the > > necessary device set is small. As you can see in the patches in this > > case it's just a few lines of PCI ids and a hack to the virtio bus to > > achieve the goal of disabling all extraneous devices by default. > > > > If your goal is to prevent some unwanted _drivers_ from operating -- > or all but a few desired drivers, as the case may be -- why extend > the "authorized" API to all _devices_? Why not instead develop a > separate API (but of similar form) for drivers? > > Wouldn't that make more sense? It corresponds a lot more directly > with what you say you want to accomplish. This was v1. v1 was NAKd [1] [2]: [1]: https://lore.kernel.org/all/YQwpa+LAYt7YZ5dh@kroah.com/ [2]: https://lore.kernel.org/all/YQzDqm6FOezM6Rnu@kroah.com/ > What would you do in the theoretical case where two separate drivers > can manage the same device, but one of them is desired (or hardened) > and the other isn't? Allow for user override, just like we do today for new_id, remove_id, bind, and unbind when default driver policy is insufficient. echo 1 > /sys/bus/$bus/devices/$device/authorized echo $device > /sys/bus/$bus/drivers/$desired_driver/bind The device filter is really only necessary to bootstrap until you can run override policy scripts. The driver firewall approach was overkill in that regard.
WARNING: multiple messages have this Message-ID (diff)
From: Dan Williams <dan.j.williams@intel.com> To: Alan Stern <stern@rowland.harvard.edu> Cc: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>, Kuppuswamy Sathyanarayanan <knsathya@kernel.org>, "Michael S. Tsirkin" <mst@redhat.com>, Linux PCI <linux-pci@vger.kernel.org>, virtualization@lists.linux-foundation.org, Andreas Noever <andreas.noever@gmail.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 ML <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>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, USB list <linux-usb@vger.kernel.org>, Linux Kernel Mailing List <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: Thu, 30 Sep 2021 19:20:04 -0700 [thread overview] Message-ID: <CAPcyv4iRo0Hd=_3jAScb5KUEJp3bU=QrWM8FYeb94SzO4gqgJA@mail.gmail.com> (raw) In-Reply-To: <20211001014114.GB489012@rowland.harvard.edu> On Thu, Sep 30, 2021 at 6:41 PM Alan Stern <stern@rowland.harvard.edu> wrote: > > On Thu, Sep 30, 2021 at 01:52:59PM -0700, Dan Williams wrote: > > On Thu, Sep 30, 2021 at 1:44 PM Alan Stern <stern@rowland.harvard.edu> wrote: > > > > > > On Thu, Sep 30, 2021 at 12:23:36PM -0700, Andi Kleen wrote: > > > > > > > > > I don't think the current mitigations under discussion here are about > > > > > keeping the system working. In fact most encrypted VM configs tend to > > > > > stop booting as a preferred way to handle security issues. > > > > > > > > Maybe we should avoid the "trusted" term here. We're only really using it > > > > because USB is using it and we're now using a common framework like Greg > > > > requested. But I don't think it's the right way to think about it. > > > > > > > > We usually call the drivers "hardened". The requirement for a hardened > > > > driver is that all interactions through MMIO/port/config space IO/MSRs are > > > > sanitized and do not cause memory safety issues or other information leaks. > > > > Other than that there is no requirement on the functionality. In particular > > > > DOS is ok since a malicious hypervisor can decide to not run the guest at > > > > any time anyways. > > > > > > > > Someone loading an malicious driver inside the guest would be out of scope. > > > > If an attacker can do that inside the guest you already violated the > > > > security mechanisms and there are likely easier ways to take over the guest > > > > or leak data. > > > > > > > > The goal of the device filter mechanism is to prevent loading unhardened > > > > drivers that could be exploited without them being themselves malicious. > > > > > > If all you want to do is prevent someone from loading a bunch of > > > drivers that you have identified as unhardened, why not just use a > > > modprobe blacklist? Am I missing something? > > > > modules != drivers (i.e. multi-driver modules are a thing) and builtin > > modules do not adhere to modprobe policy. > > > > There is also a desire to be able to support a single kernel image > > across hosts and guests. So, if you were going to say, "just compile > > all unnecessary drivers as modules" that defeats the common kernel > > image goal. For confidential computing the expectation is that the > > necessary device set is small. As you can see in the patches in this > > case it's just a few lines of PCI ids and a hack to the virtio bus to > > achieve the goal of disabling all extraneous devices by default. > > > > If your goal is to prevent some unwanted _drivers_ from operating -- > or all but a few desired drivers, as the case may be -- why extend > the "authorized" API to all _devices_? Why not instead develop a > separate API (but of similar form) for drivers? > > Wouldn't that make more sense? It corresponds a lot more directly > with what you say you want to accomplish. This was v1. v1 was NAKd [1] [2]: [1]: https://lore.kernel.org/all/YQwpa+LAYt7YZ5dh@kroah.com/ [2]: https://lore.kernel.org/all/YQzDqm6FOezM6Rnu@kroah.com/ > What would you do in the theoretical case where two separate drivers > can manage the same device, but one of them is desired (or hardened) > and the other isn't? Allow for user override, just like we do today for new_id, remove_id, bind, and unbind when default driver policy is insufficient. echo 1 > /sys/bus/$bus/devices/$device/authorized echo $device > /sys/bus/$bus/drivers/$desired_driver/bind The device filter is really only necessary to bootstrap until you can run override policy scripts. The driver firewall approach was overkill in that regard. _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
next prev parent reply other threads:[~2021-10-01 2:20 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 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 [this message] 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='CAPcyv4iRo0Hd=_3jAScb5KUEJp3bU=QrWM8FYeb94SzO4gqgJA@mail.gmail.com' \ --to=dan.j.williams@intel.com \ --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=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=stern@rowland.harvard.edu \ --cc=tglx@linutronix.de \ --cc=virtualization@lists.linux-foundation.org \ --cc=x86@kernel.org \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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.