[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20190905103541.4161-1-thomas_os@shipmail.org>
Date: Thu, 5 Sep 2019 12:35:39 +0200
From: Thomas Hellström (VMware)
<thomas_os@...pmail.org>
To: linux-kernel@...r.kernel.org, x86@...nel.org, pv-drivers@...are.com
Cc: Thomas Hellström <thomas_os@...pmail.org>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Andy Lutomirski <luto@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
"H. Peter Anvin" <hpa@...or.com>,
Christoph Hellwig <hch@...radead.org>,
Christian König <christian.koenig@....com>,
Marek Szyprowski <m.szyprowski@...sung.com>,
Tom Lendacky <thomas.lendacky@....com>
Subject: [RFC PATCH 0/2] Fix SEV user-space mapping of unencrypted coherent memory
With SEV and sometimes with SME encryption, The dma api coherent memory is
typically unencrypted, meaning the linear kernel map has the encryption
bit cleared. However, default page protection returned from vm_get_page_prot()
has the encryption bit set. So to compute the correct page protection we need
to clear the encryption bit.
Also, in order for the encryption bit setting to survive across do_mmap() and
mprotect_fixup(), We need to make pgprot_modify() aware of it and not touch it.
(Note that the encryption status is not logically encoded in the pfn but in
the page protection even if an address line in the physical address is used).
The patchset has seen some sanity testing by exporting dma_pgprot() and
using it in the vmwgfx mmap handler with SEV enabled.
Cc: Dave Hansen <dave.hansen@...ux.intel.com>
Cc: Andy Lutomirski <luto@...nel.org>
Cc: Peter Zijlstra <peterz@...radead.org>
Cc: Thomas Gleixner <tglx@...utronix.de>
Cc: Ingo Molnar <mingo@...hat.com>
Cc: Borislav Petkov <bp@...en8.de>
Cc: "H. Peter Anvin" <hpa@...or.com>
Cc: Christoph Hellwig <hch@...radead.org>
Cc: Christian König <christian.koenig@....com>
Cc: Marek Szyprowski <m.szyprowski@...sung.com>
Cc: Tom Lendacky <thomas.lendacky@....com>
Powered by blists - more mailing lists