Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54a4d14c-b19b-339e-5a15-adb10297cb30@amazon.com>
Date: Thu, 13 Jun 2019 09:27:00 +0200
From: Alexander Graf <graf@...zon.com>
To: Dave Hansen <dave.hansen@...el.com>, Marius Hillenbrand
	<mhillenb@...zon.de>, <kvm@...r.kernel.org>
CC: <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>, the arch/x86 maintainers <x86@...nel.org>, "Andy
 Lutomirski" <luto@...nel.org>, Peter Zijlstra <peterz@...radead.org>
Subject: Re: [RFC 00/10] Process-local memory allocations for hiding KVM
 secrets


On 12.06.19 21:55, Dave Hansen wrote:
> On 6/12/19 10:08 AM, Marius Hillenbrand wrote:
>> This patch series proposes to introduce a region for what we call
>> process-local memory into the kernel's virtual address space.
> It might be fun to cc some x86 folks on this series.  They might have
> some relevant opinions. ;)
>
> A few high-level questions:
>
> Why go to all this trouble to hide guest state like registers if all the
> guest data itself is still mapped?


(jumping in for Marius, he's offline today)

Glad you asked :). I hope this cover letter explains well how to achieve 
guest data not being mapped:

https://lkml.org/lkml/2019/1/31/933


> Where's the context-switching code?  Did I just miss it?


I'm not sure I understand the question. With this mechanism, the global 
linear map pages are just not present anymore, so there is no context 
switching needed. For the process local memory, the page table is 
already mm local, so we don't need to do anything special during context 
switch, no?


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.