[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190911055913.GB104115@gmail.com>
Date: Wed, 11 Sep 2019 07:59:14 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Thomas Hellström (VMware)
<thomas_os@...pmail.org>
Cc: linux-kernel@...r.kernel.org, pv-drivers@...are.com,
linux-graphics-maintainer@...are.com, x86@...nel.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: Re: [PATCH 0/2] Fix SEV user-space mapping of unencrypted coherent
memory
* Thomas Hellström (VMware) <thomas_os@...pmail.org> wrote:
> 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.
> Therefore make sme_me_mask part of _PAGE_CHG_MASK and make sure
> pgprot_modify() preserves also cleared bits that are part of _PAGE_CHG_MASK,
> not just set bits. The use of pgprot_modify() is currently quite limited and
> easy to audit.
>
> (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.
>
> Changes since:
> RFC:
> - Make sme_me_mask port of _PAGE_CHG_MASK rather than using it by its own in
> pgprot_modify().
Could you please add a "why is this patch-set needed", not just describe
the "what does this patch set do"? I've seen zero discussion in the three
changelogs of exactly why we'd want this, which drivers and features are
affected and in what way, etc.
It's called a "fix" but doesn't explain what bad behavior it fixes.
Thanks,
Ingo
Powered by blists - more mailing lists