[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e96bc698-89ca-3c67-d0ba-adecc50e8a53@linux.intel.com>
Date: Wed, 4 Aug 2021 21:45:56 -0700
From: Andi Kleen <ak@...ux.intel.com>
To: Dan Williams <dan.j.williams@...el.com>,
Matthew Wilcox <willy@...radead.org>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Kuppuswamy Sathyanarayanan
<sathyanarayanan.kuppuswamy@...ux.intel.com>,
"Rafael J . Wysocki" <rafael@...nel.org>,
Jonathan Corbet <corbet@....net>,
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 8/4/2021 2:28 PM, Dan Williams wrote
> 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.
Another way to see it is: the confidential guest is protected against
the host, except for the places where it chooses to communicate with the
host through MMIOs, port IOs, some (not all) MSRs. It's somewhat
analogous to a network server in a hostile network which can be attacked
through network packets. We typically use a firewall to limit the
network exposure only to especially hardened network services. Each low
level MMIO etc. is like a network access communicating with a hostile
network. The device filter is the firewall for these vulnerable low
level interactions. It reduces the hardening problem from being
completely infeasible to tractable.
-Andi
Powered by blists - more mailing lists