From: "Reshetova, Elena" <email@example.com> To: Mike Rapoport <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org> Cc: Alexey Dobriyan <email@example.com>, Andrew Morton <firstname.lastname@example.org>, Andy Lutomirski <email@example.com>, Arnd Bergmann <firstname.lastname@example.org>, Borislav Petkov <email@example.com>, Dave Hansen <firstname.lastname@example.org>, James Bottomley <email@example.com>, "Peter Zijlstra" <firstname.lastname@example.org>, Steven Rostedt <email@example.com>, Thomas Gleixner <firstname.lastname@example.org>, Ingo Molnar <email@example.com>, "H. Peter Anvin" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, Mike Rapoport <email@example.com>, Tycho Andersen <firstname.lastname@example.org>, Alan Cox <email@example.com> Subject: RE: [PATCH RFC] mm: add MAP_EXCLUSIVE to create exclusive user mappings Date: Tue, 29 Oct 2019 11:25:12 +0000 Message-ID: <2236FBA76BA1254E88B949DDB74E612BA4EEC0CE@IRSMSX102.ger.corp.intel.com> (raw) In-Reply-To: <firstname.lastname@example.org> > The patch below aims to allow applications to create mappins that have > pages visible only to the owning process. Such mappings could be used to > store secrets so that these secrets are not visible neither to other > processes nor to the kernel. Hi Mike, I have actually been looking into the closely related problem for the past couple of weeks (on and off). What is common here is the need for userspace to indicate to kernel that some pages contain secrets. And then there are actually a number of things that kernel can do to try to protect these secrets better. Unmap from direct map is one of them. Another thing is to map such pages as non-cached, which can help us to prevent or considerably restrict speculation on such pages. The initial proof of concept for marking pages as "UNCACHED" that I got from Dave Hansen was actually based on mlock2() and a new flag for it for this purpose. Since then I have been thinking on what interface suits the use case better and actually selected going with new madvise() flag instead because of all possible implications for fragmentation and performance. My logic was that we better allocate the secret data explicitly (using mmap()) to make sure that no other process data accidentally gets to suffer. Imagine I would allocate a buffer to hold a secret key, signal with mlock to protect it and suddenly my other high throughput non-secret buffer (which happened to live on the same page by chance) became very slow and I don't even have an easy way (apart from mmap()ing it!) to guarantee that it won't be affected. So, I ended up towards smth like: secret_buffer = mmap(NULL, PAGE_SIZE, ...) madvise(secret_buffer, size, MADV_SECRET) I have work in progress code here: https://github.com/ereshetova/linux/commits/madvise I haven't sent it for review, because it is not ready yet and I am now working on trying to add the page wiping functionality. Otherwise it would be useless to protect the page during the time it is used in userspace, but then allow it to get reused by a different process later after it has been released back and userspace was stupid enough not to wipe the contents (or was crashed on purpose before it was able to wipe anything out). We have also had some discussions with Tycho that XPFO can be also applied selectively for such "SECRET" marked pages and I know that he has also did some initial prototyping on this, so I think it would be great to decide on userspace interface first and then see how we can assemble together all these features. The *very* far fetching goal for all of this would be something that Alan Cox suggested when I started looking into this - actually have a new libc function to allocate memory in a secure way, which can hide all the dancing with mmap()/madvise() (or/and potentially interaction with a chardev that Andy was suggesting also) and implement an efficient allocator for such secret pages. Openssl has its own version of "secure heap", which is essentially mmap area with additional MLOCK_ONFAULT and MADV_DONTDUMP flags for protection. Some other apps or libs must use smth similar if they want additional protection, which makes them to reimplement the same concept again and again. Sadly or surprisingly other major libs like boringssl, mbedTLS or client like openssh do not user any mlock()/ madvise() flags for any additional protection of secrets that they hold in memory. Maybe if all of it would be behind a single secure API situation would start to change in userspace towards better. Best Regards, Elena. .
next prev parent reply index Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-10-27 10:17 Mike Rapoport 2019-10-27 10:17 ` Mike Rapoport 2019-10-28 12:31 ` Kirill A. Shutemov 2019-10-28 13:00 ` Mike Rapoport 2019-10-28 13:16 ` Kirill A. Shutemov 2019-10-28 13:55 ` Peter Zijlstra 2019-10-28 19:59 ` Edgecombe, Rick P 2019-10-28 21:00 ` Peter Zijlstra 2019-10-29 17:27 ` Edgecombe, Rick P 2019-10-30 10:04 ` Peter Zijlstra 2019-10-30 15:35 ` Alexei Starovoitov 2019-10-30 18:39 ` Peter Zijlstra 2019-10-30 18:52 ` Alexei Starovoitov 2019-10-30 17:48 ` Edgecombe, Rick P 2019-10-30 17:58 ` Dave Hansen 2019-10-30 18:01 ` Dave Hansen 2019-10-29 5:43 ` Dan Williams 2019-10-29 6:43 ` Kirill A. Shutemov 2019-10-29 8:56 ` Peter Zijlstra 2019-10-29 11:00 ` Kirill A. Shutemov 2019-10-29 12:39 ` AMD TLB errata, (Was: [PATCH RFC] mm: add MAP_EXCLUSIVE to create exclusive user mappings) Peter Zijlstra 2019-11-15 14:12 ` Tom Lendacky 2019-11-15 14:31 ` Peter Zijlstra 2019-10-29 19:43 ` [PATCH RFC] mm: add MAP_EXCLUSIVE to create exclusive user mappings Dan Williams 2019-10-29 20:07 ` Dave Hansen 2019-10-29 7:08 ` Christopher Lameter 2019-10-29 8:55 ` Mike Rapoport 2019-10-29 10:12 ` Christopher Lameter 2019-10-30 7:11 ` Mike Rapoport 2019-10-30 12:09 ` Christopher Lameter 2019-10-28 14:55 ` David Hildenbrand 2019-10-28 17:12 ` Dave Hansen 2019-10-28 17:32 ` Sean Christopherson 2019-10-28 18:08 ` Matthew Wilcox 2019-10-29 9:28 ` Mike Rapoport 2019-10-29 9:19 ` Mike Rapoport 2019-10-28 18:02 ` Andy Lutomirski 2019-10-29 11:02 ` David Hildenbrand 2019-10-30 8:15 ` Mike Rapoport 2019-10-30 8:19 ` David Hildenbrand 2019-10-31 19:16 ` Mike Rapoport 2019-10-31 21:52 ` Dan Williams 2019-10-27 10:30 ` Florian Weimer 2019-10-27 11:00 ` Mike Rapoport 2019-10-28 20:23 ` Florian Weimer 2019-10-29 9:01 ` Mike Rapoport 2019-10-28 20:44 ` Andy Lutomirski 2019-10-29 9:32 ` Mike Rapoport 2019-10-29 17:00 ` Andy Lutomirski 2019-10-30 8:40 ` Mike Rapoport 2019-10-30 21:28 ` Andy Lutomirski 2019-10-31 7:21 ` Mike Rapoport 2019-12-05 15:34 ` Mike Rapoport 2019-12-08 14:10 ` [PATCH] mm: extend memfd with ability to create secret memory kbuild test robot 2019-10-29 11:25 ` Reshetova, Elena [this message] 2019-10-29 15:13 ` [PATCH RFC] mm: add MAP_EXCLUSIVE to create exclusive user mappings Tycho Andersen 2019-10-29 17:03 ` Andy Lutomirski 2019-10-29 17:37 ` Alan Cox 2019-10-29 17:43 ` James Bottomley 2019-10-29 18:10 ` Andy Lutomirski
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=2236FBA76BA1254E88B949DDB74E612BA4EEC0CE@IRSMSX102.ger.corp.intel.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
LKML Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git git clone --mirror https://lore.kernel.org/lkml/9 lkml/git/9.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \ firstname.lastname@example.org public-inbox-index lkml Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git