linux-kernel - Re: [PATCH v1] driver: base: Add driver filter support

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Thu, 5 Aug 2021 09:59:45 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Dan Williams <dan.j.williams@...el.com>
Cc:     Matthew Wilcox <willy@...radead.org>,
        Kuppuswamy Sathyanarayanan 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        "Rafael J . Wysocki" <rafael@...nel.org>,
        Jonathan Corbet <corbet@....net>,
        Andi Kleen <ak@...ux.intel.com>,
        Kuppuswamy Sathyanarayanan <knsathya@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Doc Mailing List <linux-doc@...r.kernel.org>
Subject: Re: [PATCH v1] driver: base: Add driver filter support

On Wed, Aug 04, 2021 at 02:28:32PM -0700, Dan Williams wrote:
> On Wed, Aug 4, 2021 at 2:07 PM Matthew Wilcox <willy@...radead.org> wrote:
> >
> > On Wed, Aug 04, 2021 at 01:11:27PM -0700, Dan Williams wrote:
> > > On Wed, Aug 4, 2021 at 12:29 PM Greg Kroah-Hartman
> > > <gregkh@...uxfoundation.org> wrote:
> > > > Why not just make distros that want to support this type of platform,
> > > > also provide these tiny kernel images?  Why are you pushing this work on
> > > > the kernel community instead?
> > >
> > > In fact, these questions are where I started when first encountering
> > > this proposal. Andi has addressed the single kernel image constraint,
> > > but I want to pick up on this "pushing work to the kernel community"
> > > contention. The small list of vetted drivers that a TDX guest needs
> > > will be built-in and maintained in the kernel by the protected guest
> > > developer community, so no "pushing work" there. However, given that
> > > any driver disable mechanism needs to touch the driver core I
> > > advocated to go ahead and make this a general purpose capability to
> > > pick up where this [1] conversation left off. I.e. a general facility
> > > for the corner cases that modprobe and kernel config policy can not
> > > reach. Corner cases like VMM attacking the VM, or broken hardware with
> > > a built-in driver that can't be unbound after the fact.
> >
> > I don't understand how this defends against a hypervisor attacking a
> > guest.  If the hardware exists, the hypervisor can access it, regardless
> > of whether the driver is default-disabled by configuration.
> 
> The "hardware" in this case is virtual devices presented by the VMM to
> the VM. So if a driver misbehaves in a useful way for an attacker to
> exploit, they can stimulate that behavior with a custom crafted
> virtual device, and that driver will autoload unaware of the threat
> without this filter for vetted drivers.

As I just said elsewhere in this thread, we have support for this today
for thunderbolt and USB, please just expand that to all bus types and
that should be fine.

thanks,

greg k-h