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]

Message-ID: <YQsBfAVPomaC97Rm@casper.infradead.org>
Date:   Wed, 4 Aug 2021 22:07:08 +0100
From:   Matthew Wilcox <willy@...radead.org>
To:     Dan Williams <dan.j.williams@...el.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.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 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.