From: Mark Rutland <mark.rutland@arm.com> To: Catalin Marinas <catalin.marinas@arm.com> Cc: Mike Rapoport <rppt@kernel.org>, linux-kernel@vger.kernel.org, Alexander Viro <viro@zeniv.linux.org.uk>, Andrew Morton <akpm@linux-foundation.org>, Andy Lutomirski <luto@kernel.org>, Arnd Bergmann <arnd@arndb.de>, Borislav Petkov <bp@alien8.de>, Christopher Lameter <cl@linux.com>, Dan Williams <dan.j.williams@intel.com>, Dave Hansen <dave.hansen@linux.intel.com>, Elena Reshetova <elena.reshetova@intel.com>, "H. Peter Anvin" <hpa@zytor.com>, Idan Yaniv <idan.yaniv@ibm.com>, Ingo Molnar <mingo@redhat.com>, James Bottomley <jejb@linux.ibm.com>, "Kirill A. Shutemov" <kirill@shutemov.name>, Matthew Wilcox <willy@infradead.org>, Mike Rapoport <rppt@linux.ibm.com>, Michael Kerrisk <mtk.manpages@gmail.com>, Palmer Dabbelt <palmer@dabbelt.com>, Paul Walmsley <paul.walmsley@sifive.com>, Peter Zijlstra <peterz@infradead.org>, Thomas Gleixner <tglx@linutronix.de>, Tycho Andersen <tycho@tycho.ws>, Will Deacon <will@kernel.org>, linux-api@vger.kernel.org, linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-nvdimm@lists.01.org, linux-riscv@lists.infradead.org, x86@kernel.org Subject: Re: [PATCH v2 3/7] mm: introduce memfd_secret system call to create "secret" memory areas Date: Fri, 31 Jul 2020 15:29:05 +0100 Message-ID: <20200731142905.GA67415@C02TD0UTHF1T.local> (raw) In-Reply-To: <20200730162209.GB3128@gaia> On Thu, Jul 30, 2020 at 05:22:10PM +0100, Catalin Marinas wrote: > On Mon, Jul 27, 2020 at 07:29:31PM +0300, Mike Rapoport wrote: > > +static int secretmem_mmap(struct file *file, struct vm_area_struct *vma) > > +{ > > + struct secretmem_ctx *ctx = file->private_data; > > + unsigned long mode = ctx->mode; > > + unsigned long len = vma->vm_end - vma->vm_start; > > + > > + if (!mode) > > + return -EINVAL; > > + > > + if ((vma->vm_flags & (VM_SHARED | VM_MAYSHARE)) == 0) > > + return -EINVAL; > > + > > + if (mlock_future_check(vma->vm_mm, vma->vm_flags | VM_LOCKED, len)) > > + return -EAGAIN; > > + > > + switch (mode) { > > + case SECRETMEM_UNCACHED: > > + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); > > + fallthrough; > > + case SECRETMEM_EXCLUSIVE: > > + vma->vm_ops = &secretmem_vm_ops; > > + break; > > + default: > > + return -EINVAL; > > + } > > + > > + vma->vm_flags |= VM_LOCKED; > > + > > + return 0; > > +} > > I think the uncached mapping is not the right thing for arm/arm64. First > of all, pgprot_noncached() gives us Strongly Ordered (Device memory) > semantics together with not allowing unaligned accesses. I suspect the > semantics are different on x86. > The second, more serious problem, is that I can't find any place where > the caches are flushed for the page mapped on fault. When a page is > allocated, assuming GFP_ZERO, only the caches are guaranteed to be > zeroed. Exposing this subsequently to user space as uncached would allow > the user to read stale data prior to zeroing. The arm64 > set_direct_map_default_noflush() doesn't do any cache maintenance. It's also worth noting that in a virtual machine this is liable to be either broken (with a potential loss of coherency if the host has a cacheable alias as existing KVM hosts have), or pointless (if the host uses S2FWB to upgrade Stage-1 attribues to cacheable as existing KVM hosts also have). I think that trying to avoid the data caches creates many more problems than it solves, and I don't think there's a strong justification for trying to support that on arm64 to begin with, so I'd rather entirely opt-out on supporting SECRETMEM_UNCACHED. Thanks, Mark.
next prev parent reply index Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-07-27 16:29 [PATCH v2 0/7] " Mike Rapoport 2020-07-27 16:29 ` [PATCH v2 1/7] mm: add definition of PMD_PAGE_ORDER Mike Rapoport 2020-07-27 16:29 ` [PATCH v2 2/7] mmap: make mlock_future_check() global Mike Rapoport 2020-07-27 16:29 ` [PATCH v2 3/7] mm: introduce memfd_secret system call to create "secret" memory areas Mike Rapoport 2020-07-30 16:22 ` Catalin Marinas 2020-07-30 20:44 ` Mike Rapoport 2020-07-31 14:10 ` Catalin Marinas 2020-07-31 14:29 ` Mark Rutland [this message] 2020-07-31 16:22 ` Catalin Marinas 2020-07-27 16:29 ` [PATCH v2 4/7] arch, mm: wire up memfd_secret system call were relevant Mike Rapoport 2020-07-27 17:25 ` Arnd Bergmann 2020-07-27 16:29 ` [PATCH v2 5/7] mm: secretmem: use PMD-size pages to amortize direct map fragmentation Mike Rapoport 2020-07-27 16:29 ` [PATCH v2 6/7] mm: secretmem: add ability to reserve memory at boot Mike Rapoport 2020-07-27 16:29 ` [PATCH v2 7/7] " Mike Rapoport 2020-07-27 17:11 ` Mike Rapoport
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=20200731142905.GA67415@C02TD0UTHF1T.local \ --to=mark.rutland@arm.com \ --cc=akpm@linux-foundation.org \ --cc=arnd@arndb.de \ --cc=bp@alien8.de \ --cc=catalin.marinas@arm.com \ --cc=cl@linux.com \ --cc=dan.j.williams@intel.com \ --cc=dave.hansen@linux.intel.com \ --cc=elena.reshetova@intel.com \ --cc=hpa@zytor.com \ --cc=idan.yaniv@ibm.com \ --cc=jejb@linux.ibm.com \ --cc=kirill@shutemov.name \ --cc=linux-api@vger.kernel.org \ --cc=linux-arch@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux-nvdimm@lists.01.org \ --cc=linux-riscv@lists.infradead.org \ --cc=luto@kernel.org \ --cc=mingo@redhat.com \ --cc=mtk.manpages@gmail.com \ --cc=palmer@dabbelt.com \ --cc=paul.walmsley@sifive.com \ --cc=peterz@infradead.org \ --cc=rppt@kernel.org \ --cc=rppt@linux.ibm.com \ --cc=tglx@linutronix.de \ --cc=tycho@tycho.ws \ --cc=viro@zeniv.linux.org.uk \ --cc=will@kernel.org \ --cc=willy@infradead.org \ --cc=x86@kernel.org \ /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
Linux-api Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-api/0 linux-api/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-api linux-api/ https://lore.kernel.org/linux-api \ linux-api@vger.kernel.org public-inbox-index linux-api Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-api AGPL code for this site: git clone https://public-inbox.org/public-inbox.git