From: "Manwaring, Derek" <derekmn@amazon.com>
To: Sean Christopherson <seanjc@google.com>,
James Gowans <jgowans@amazon.com>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>,
Nikita Kalyazin <kalyazin@amazon.co.uk>,
"rppt@kernel.org" <rppt@kernel.org>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Patrick Roy <roypat@amazon.co.uk>,
"somlo@cmu.edu" <somlo@cmu.edu>,
"vbabka@suse.cz" <vbabka@suse.cz>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"kirill.shutemov@linux.intel.com"
<kirill.shutemov@linux.intel.com>,
"Liam.Howlett@oracle.com" <Liam.Howlett@oracle.com>,
David Woodhouse <dwmw@amazon.co.uk>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
Alexander Graf <graf@amazon.de>,
"chao.p.peng@linux.intel.com" <chao.p.peng@linux.intel.com>,
"lstoakes@gmail.com" <lstoakes@gmail.com>,
"mst@redhat.com" <mst@redhat.com>, Moritz Lipp <mlipp@amazon.at>,
Claudio Canella <canellac@amazon.at>
Subject: Re: Unmapping KVM Guest Memory from Host Kernel
Date: Mon, 13 May 2024 15:01:46 -0700 [thread overview]
Message-ID: <7107a45b-0635-4040-9f4c-288708b13c04@amazon.com> (raw)
In-Reply-To: <ZkJ37uwNOPis0EnW@google.com>
On 2024-05-13 13:36-0700, Sean Christopherson wrote:
> Hmm, a slightly crazy idea (ok, maybe wildly crazy) would be to support mapping
> all of guest_memfd into kernel address space, but as USER=1 mappings. I.e. don't
> require a carve-out from userspace, but do require CLAC/STAC when access guest
> memory from the kernel. I think/hope that would provide the speculative execution
> mitigation properties you're looking for?
This is interesting. I'm hesitant to rely on SMAP since it can be
enforced too late by the microarchitecture. But Canella, et al. [1] did
say in 2019 that the kernel->user access route seemed to be free of any
"Meltdown" effects. LASS sounds like it will be even stronger, though
it's not clear to me from Intel's programming reference that speculative
scenarios are in scope [2]. AMD does list SMAP specifically as a
feature that can control speculation [3].
I don't see an equivalent read-access control on ARM. It has PXN for
execute. Read access can probably also be controlled? But I think for
the non-CoCo case we should favor solutions that are less dependent on
hardware-specific protections.
Derek
[1] https://www.usenix.org/system/files/sec19-canella.pdf
[2] https://cdrdv2.intel.com/v1/dl/getContent/671368
[3] https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/tuning-guides/software-techniques-for-managing-speculation.pdf
next prev parent reply other threads:[~2024-05-13 22:02 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <AQHacXBJeX10YUH0O0SiQBg1zQLaEw==>
2024-03-08 15:50 ` Unmapping KVM Guest Memory from Host Kernel Gowans, James
2024-03-08 16:25 ` Brendan Jackman
2024-03-08 17:35 ` David Matlack
2024-03-08 17:45 ` David Woodhouse
2024-03-08 22:47 ` Sean Christopherson
2024-03-09 2:45 ` Manwaring, Derek
2024-03-18 14:11 ` Brendan Jackman
2024-03-08 23:22 ` Sean Christopherson
2024-03-09 11:14 ` Mike Rapoport
2024-05-13 10:31 ` Patrick Roy
2024-05-13 15:39 ` Sean Christopherson
2024-05-13 16:01 ` Gowans, James
2024-05-13 17:09 ` Sean Christopherson
2024-05-13 19:43 ` Gowans, James
2024-05-13 20:36 ` Sean Christopherson
2024-05-13 22:01 ` Manwaring, Derek [this message]
2024-03-14 21:45 ` Manwaring, Derek
2024-03-09 5:01 ` Matthew Wilcox
2024-03-08 21:05 Manwaring, Derek
2024-03-11 9:26 ` Fuad Tabba
2024-03-11 9:29 ` Fuad Tabba
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=7107a45b-0635-4040-9f4c-288708b13c04@amazon.com \
--to=derekmn@amazon.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=canellac@amazon.at \
--cc=chao.p.peng@linux.intel.com \
--cc=dwmw@amazon.co.uk \
--cc=graf@amazon.de \
--cc=jgowans@amazon.com \
--cc=kalyazin@amazon.co.uk \
--cc=kirill.shutemov@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-mm@kvack.org \
--cc=lstoakes@gmail.com \
--cc=mlipp@amazon.at \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=roypat@amazon.co.uk \
--cc=rppt@kernel.org \
--cc=seanjc@google.com \
--cc=somlo@cmu.edu \
--cc=vbabka@suse.cz \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).