[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 13 Jun 2019 09:20:40 +0200
From: Alexander Graf <graf@...zon.com>
To: Sean Christopherson <sean.j.christopherson@...el.com>, Marius Hillenbrand
<mhillenb@...zon.de>
CC: <kvm@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<kernel-hardening@...ts.openwall.com>, <linux-mm@...ck.org>, Alexander Graf
<graf@...zon.de>, David Woodhouse <dwmw@...zon.co.uk>
Subject: Re: [RFC 00/10] Process-local memory allocations for hiding KVM
secrets
On 12.06.19 20:25, Sean Christopherson wrote:
> On Wed, Jun 12, 2019 at 07:08:24PM +0200, Marius Hillenbrand wrote:
>> The Linux kernel has a global address space that is the same for any
>> kernel code. This address space becomes a liability in a world with
>> processor information leak vulnerabilities, such as L1TF. With the right
>> cache load gadget, an attacker-controlled hyperthread pair can leak
>> arbitrary data via L1TF. Disabling hyperthreading is one recommended
>> mitigation, but it comes with a large performance hit for a wide range
>> of workloads.
>>
>> An alternative mitigation is to not make certain data in the kernel
>> globally visible, but only when the kernel executes in the context of
>> the process where this data belongs to.
>>
>> This patch series proposes to introduce a region for what we call
>> process-local memory into the kernel's virtual address space. Page
>> tables and mappings in that region will be exclusive to one address
>> space, instead of implicitly shared between all kernel address spaces.
>> Any data placed in that region will be out of reach of cache load
>> gadgets that execute in different address spaces. To implement
>> process-local memory, we introduce a new interface kmalloc_proclocal() /
>> kfree_proclocal() that allocates and maps pages exclusively into the
>> current kernel address space. As a first use case, we move architectural
>> state of guest CPUs in KVM out of reach of other kernel address spaces.
> Can you briefly describe what types of attacks this is intended to
> mitigate? E.g. guest-guest, userspace-guest, etc... I don't want to
> make comments based on my potentially bad assumptions.
(quickly jumping in for Marius, he's offline today)
The main purpose of this is to protect from leakage of data from one
guest into another guest using speculation gadgets on the host.
The same mechanism can be used to prevent leakage of secrets from one
host process into another host process though, as host processes
potentially have access to gadgets via the syscall interface.
Alex
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
