linux-kernel - Re: [PATCH 0/2] Fix SEV user-space mapping of unencrypted coherent memory

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <e50cc9fc-4c3e-90c7-1139-f414766b648f@shipmail.org>
Date:   Wed, 11 Sep 2019 10:07:06 +0200
From:   Thomas Hellström (VMware) 
        <thomas_os@...pmail.org>
To:     Ingo Molnar <mingo@...nel.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

On 9/11/19 7:59 AM, Ingo Molnar wrote:
> * 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

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

Thanks,

Thomas