Re: [RFC 00/10] Process-local memory allocations for hiding KVM secrets

[Alexander Graf]

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