[lkml]   [2019]   [Sep]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 0/2] Fix SEV user-space mapping of unencrypted coherent memory
On 9/11/19 7:59 AM, Ingo Molnar wrote:
> * Thomas Hellström (VMware) <> 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

I'll update the changelog to be more clear about that.



 \ /
  Last update: 2019-09-11 10:07    [W:0.038 / U:1.872 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site