From: Alexander Graf <graf@amazon.com>
To: Thomas Gleixner <tglx@linutronix.de>,
Andy Lutomirski <luto@amacapital.net>
Cc: Dave Hansen <dave.hansen@intel.com>,
Marius Hillenbrand <mhillenb@amazon.de>, <kvm@vger.kernel.org>,
<linux-kernel@vger.kernel.org>,
<kernel-hardening@lists.openwall.com>, <linux-mm@kvack.org>,
Alexander Graf <graf@amazon.de>,
David Woodhouse <dwmw@amazon.co.uk>,
"the arch/x86 maintainers" <x86@kernel.org>,
Andy Lutomirski <luto@kernel.org>,
"Peter Zijlstra" <peterz@infradead.org>
Subject: Re: [RFC 00/10] Process-local memory allocations for hiding KVM secrets
Date: Mon, 17 Jun 2019 09:38:00 +0200 [thread overview]
Message-ID: <58788f05-04c3-e71c-12c3-0123be55012c@amazon.com> (raw)
In-Reply-To: <alpine.DEB.2.21.1906141618000.1722@nanos.tec.linutronix.de>
On 14.06.19 16:21, Thomas Gleixner wrote:
> On Wed, 12 Jun 2019, Andy Lutomirski wrote:
>>> On Jun 12, 2019, at 12:55 PM, Dave Hansen <dave.hansen@intel.com> 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?
>>>
>>> Where's the context-switching code? Did I just miss it?
>>>
>>> We've discussed having per-cpu page tables where a given PGD is only in
>>> use from one CPU at a time. I *think* this scheme still works in such a
>>> case, it just adds one more PGD entry that would have to context-switched.
>> Fair warning: Linus is on record as absolutely hating this idea. He might
>> change his mind, but it’s an uphill battle.
> Yes I know, but as a benefit we could get rid of all the GSBASE horrors in
> the entry code as we could just put the percpu space into the local PGD.
Would that mean that with Meltdown affected CPUs we open speculation
attacks against the mmlocal memory from KVM user space?
Alex
next prev parent reply other threads:[~2019-06-17 7:38 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-12 17:08 [RFC 00/10] Process-local memory allocations for hiding KVM secrets Marius Hillenbrand
2019-06-12 17:08 ` [RFC 01/10] x86/mm/kaslr: refactor to use enum indices for regions Marius Hillenbrand
2019-06-12 17:08 ` [RFC 02/10] x86/speculation, mm: add process local virtual memory region Marius Hillenbrand
2019-06-12 17:08 ` [RFC 03/10] x86/mm, mm,kernel: add teardown for process-local memory to mm cleanup Marius Hillenbrand
2019-06-12 17:08 ` [RFC 04/10] mm: allocate virtual space for process-local memory Marius Hillenbrand
2019-06-12 17:08 ` [RFC 05/10] mm: allocate/release physical pages " Marius Hillenbrand
2019-06-12 17:08 ` [RFC 06/10] kvm/x86: add support for storing vCPU state in " Marius Hillenbrand
2019-06-12 17:08 ` [RFC 07/10] kvm, vmx: move CR2 context switch out of assembly path Marius Hillenbrand
2019-06-12 17:08 ` [RFC 08/10] kvm, vmx: move register clearing " Marius Hillenbrand
2019-06-12 17:08 ` [RFC 09/10] kvm, vmx: move gprs to process local memory Marius Hillenbrand
2019-06-12 17:08 ` [RFC 10/10] kvm, x86: move guest FPU state into " Marius Hillenbrand
2019-06-12 18:25 ` [RFC 00/10] Process-local memory allocations for hiding KVM secrets Sean Christopherson
2019-06-13 7:20 ` Alexander Graf
2019-06-13 10:54 ` Liran Alon
2019-06-12 19:55 ` Dave Hansen
2019-06-12 20:27 ` Andy Lutomirski
2019-06-12 20:41 ` Dave Hansen
2019-06-12 20:56 ` Andy Lutomirski
2019-06-13 1:30 ` Andy Lutomirski
2019-06-13 1:50 ` Nadav Amit
2019-06-13 16:16 ` Andy Lutomirski
2019-06-13 7:52 ` Alexander Graf
2019-06-13 16:13 ` Andy Lutomirski
2019-06-13 16:20 ` Dave Hansen
2019-06-13 17:29 ` Nadav Amit
2019-06-13 17:49 ` Dave Hansen
2019-06-13 20:05 ` Sean Christopherson
2019-06-14 14:21 ` Thomas Gleixner
2019-06-16 22:18 ` Andy Lutomirski
2019-06-16 22:28 ` Thomas Gleixner
2019-06-17 7:38 ` Alexander Graf [this message]
2019-06-17 15:50 ` Dave Hansen
2019-06-17 15:54 ` Andy Lutomirski
2019-06-17 16:03 ` Dave Hansen
2019-06-17 16:14 ` Andy Lutomirski
2019-06-17 16:53 ` Nadav Amit
2019-06-17 18:07 ` Dave Hansen
2019-06-17 18:45 ` Konrad Rzeszutek Wilk
2019-06-17 18:49 ` Dave Hansen
2019-06-17 18:53 ` Andy Lutomirski
2019-06-17 18:50 ` Nadav Amit
2019-06-17 18:55 ` Dave Hansen
2019-06-13 7:27 ` Alexander Graf
2019-06-13 14:19 ` Dave Hansen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=58788f05-04c3-e71c-12c3-0123be55012c@amazon.com \
--to=graf@amazon.com \
--cc=dave.hansen@intel.com \
--cc=dwmw@amazon.co.uk \
--cc=graf@amazon.de \
--cc=kernel-hardening@lists.openwall.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@amacapital.net \
--cc=luto@kernel.org \
--cc=mhillenb@amazon.de \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).