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  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 14 Jun 2019 12:11:23 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Alison Schofield <alison.schofield@...el.com>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        Andrew Morton <akpm@...ux-foundation.org>, x86@...nel.org,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>, Borislav Petkov <bp@...en8.de>,
        Andy Lutomirski <luto@...capital.net>,
        David Howells <dhowells@...hat.com>,
        Kees Cook <keescook@...omium.org>,
        Kai Huang <kai.huang@...ux.intel.com>,
        Jacob Pan <jacob.jun.pan@...ux.intel.com>, linux-mm@...ck.org,
        kvm@...r.kernel.org, keyrings@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH, RFC 44/62] x86/mm: Set KeyIDs in encrypted VMAs for MKTME

On 6/14/19 11:46 AM, Alison Schofield wrote:
> On Fri, Jun 14, 2019 at 11:26:10AM -0700, Dave Hansen wrote:
>> On 6/14/19 10:33 AM, Alison Schofield wrote:
>>> Preserving the data across encryption key changes has not
>>> been a requirement. I'm not clear if it was ever considered
>>> and rejected. I believe that copying in order to preserve
>>> the data was never considered.
>>
>> We could preserve the data pretty easily.  It's just annoying, though.
>> Right now, our only KeyID conversions happen in the page allocator.  If
>> we were to convert in-place, we'd need something along the lines of:
>>
>> 	1. Allocate a scratch page
>> 	2. Unmap target page, or at least make it entirely read-only
>> 	3. Copy plaintext into scratch page
>> 	4. Do cache KeyID conversion of page being converted:
>> 	   Flush caches, change page_ext metadata
>> 	5. Copy plaintext back into target page from scratch area
>> 	6. Re-establish PTEs with new KeyID
> 
> Seems like the 'Copy plaintext' steps might disappoint the user, as
> much as the 'we don't preserve your data' design. Would users be happy
> w the plain text steps ?

Well, it got to be plaintext because they wrote it to memory in
plaintext in the first place, so it's kinda hard to disappoint them. :)

IMNHO, the *vast* majority of cases, folks will allocate memory and then
put a secret in it.  They aren't going to *get* a secret in some
mysterious fashion and then later decide they want to protect it.  In
other words, the inability to convert it is pretty academic and not
worth the complexity.

Powered by blists - more mailing lists