[<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