Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210804174322.2898409-1-sathyanarayanan.kuppuswamy@linux.intel.com>
 <YQrqhYEL64CSLRTy@kroah.com> <CAPcyv4iEEDCz5719d0vNi=zi=6oN5vctcVfY5P=WQ9j_Zpz6eA@mail.gmail.com>
 <YQsBfAVPomaC97Rm@casper.infradead.org>
In-Reply-To: <YQsBfAVPomaC97Rm@casper.infradead.org>
From:   Dan Williams <dan.j.williams@intel.com>
Date:   Wed, 4 Aug 2021 14:28:32 -0700
Message-ID: <CAPcyv4gSsL5hk=CSk=9duqCN3VDS_T2LaYRL+_zK9VOkO8NB+A@mail.gmail.com>
Subject: Re: [PATCH v1] driver: base: Add driver filter support
To:     Matthew Wilcox <willy@infradead.org>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Kuppuswamy Sathyanarayanan 
        <sathyanarayanan.kuppuswamy@linux.intel.com>,
        "Rafael J . Wysocki" <rafael@kernel.org>,
        Jonathan Corbet <corbet@lwn.net>,
        Andi Kleen <ak@linux.intel.com>,
        Kuppuswamy Sathyanarayanan <knsathya@kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Linux Doc Mailing List <linux-doc@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Wed, Aug 4, 2021 at 2:07 PM Matthew Wilcox <willy@infradead.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@linuxfoundation.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.