From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C88EDC433DF for ; Fri, 31 Jul 2020 14:10:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AB1732087C for ; Fri, 31 Jul 2020 14:10:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727851AbgGaOKk (ORCPT ); Fri, 31 Jul 2020 10:10:40 -0400 Received: from mail.kernel.org ([198.145.29.99]:58696 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728206AbgGaOKk (ORCPT ); Fri, 31 Jul 2020 10:10:40 -0400 Received: from gaia (unknown [95.146.230.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 52369206DA; Fri, 31 Jul 2020 14:10:34 +0000 (UTC) Date: Fri, 31 Jul 2020 15:10:31 +0100 From: Catalin Marinas To: Mike Rapoport Cc: linux-kernel@vger.kernel.org, Alexander Viro , Andrew Morton , Andy Lutomirski , Arnd Bergmann , Borislav Petkov , Christopher Lameter , Dan Williams , Dave Hansen , Elena Reshetova , "H. Peter Anvin" , Idan Yaniv , Ingo Molnar , James Bottomley , "Kirill A. Shutemov" , Matthew Wilcox , Mike Rapoport , Michael Kerrisk , Palmer Dabbelt , Paul Walmsley , Peter Zijlstra , Thomas Gleixner , Tycho Andersen , Will Deacon , 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 Message-ID: <20200731141031.GD29569@gaia> References: <20200727162935.31714-1-rppt@kernel.org> <20200727162935.31714-4-rppt@kernel.org> <20200730162209.GB3128@gaia> <20200730204409.GB534153@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200730204409.GB534153@kernel.org> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-api-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org On Thu, Jul 30, 2020 at 11:44:09PM +0300, Mike Rapoport wrote: > 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: > > > For instance, the following example will create an uncached mapping (error > > > handling is omitted): > > > > > > fd = memfd_secret(SECRETMEM_UNCACHED); > > > ftruncate(fd, MAP_SIZE); > > > ptr = mmap(NULL, MAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); [...] > > > +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. > > Hmm, on x86 it's also Strongly Ordered, but I didn't find any alignment > restrictions. Is there a mode for arm64 that can provide similar > semantics? > > Would it make sence to use something like > > #define pgprot_uncached(prot) \ > __pgprot_modify(prot, PTE_ATTRINDX_MASK, \ > PTE_ATTRINDX(MT_NORMAL_NC) | PTE_PXN) > > or is it too weak? Reading Elena's email, that's about preventing speculative loads. While the arm64 Normal NC is non-cacheable (equivalent to write-combine), a CPU is allowed to speculatively read from it. A carefully crafted gadget could leave an imprint on a different part of the cache via speculative execution based on a value in the secret memory. So IIUC, we want memory that cannot be speculatively loaded from and that would be Device memory on arm64 (with the alignment restrictions). Now, I think we could relax this to Device_GRE. So maybe add a pgprot_nospec() and allow architectures to define whatever they find suitable. The exact semantics will be different between architectures. > > 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. > > Well, the idea of uncached mappings came from Elena [1] to prevent > possibility of side channels that leak user space memory. So I think > even without cache flushing after the allocation, user space is > protected as all its memory accesses bypass cache so even after the page > is freed there won't be stale data in the cache. > > I think that it makes sense to limit SECRETMEM_UNCACHED only for > architectures that define an appropriate protection, e.g. > pgprot_uncahced(). For x86 it can be aliased to pgprot_noncached() and > other architecures can define their versions. Indeed, though as I said above, maybe use a name that suggests no speculation since non-cacheable doesn't always guarantee that. Something like pgprot_nospec() and SECRETMEM_NOSPEC. However, your implementation still has the problem that such memory must have the caches flushed before being mapped in user-space, otherwise we leak other secrets via such pages to the caller. The only generic API we have in the kernel for such things is the DMA one. If hch doesn't mind, you could abuse it and call arch_dma_prep_coherent() prior to set_direct_map_invalid_noflush() (if the mapping is non-cacheable). -- Catalin From mboxrd@z Thu Jan 1 00:00:00 1970 From: Catalin Marinas Subject: Re: [PATCH v2 3/7] mm: introduce memfd_secret system call to create "secret" memory areas Date: Fri, 31 Jul 2020 15:10:31 +0100 Message-ID: <20200731141031.GD29569@gaia> References: <20200727162935.31714-1-rppt@kernel.org> <20200727162935.31714-4-rppt@kernel.org> <20200730162209.GB3128@gaia> <20200730204409.GB534153@kernel.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20200730204409.GB534153-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Mike Rapoport Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Alexander Viro , Andrew Morton , Andy Lutomirski , Arnd Bergmann , Borislav Petkov , Christopher Lameter , Dan Williams , Dave Hansen , Elena Reshetova , "H. Peter Anvin" , Idan Yaniv , Ingo Molnar , James Bottomley , "Kirill A. Shutemov" , Matthew Wilcox , Mike Rapoport , Michael Kerrisk , Palmer Dabbelt , Paul Walmsley List-Id: linux-arch.vger.kernel.org On Thu, Jul 30, 2020 at 11:44:09PM +0300, Mike Rapoport wrote: > 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: > > > For instance, the following example will create an uncached mapping (error > > > handling is omitted): > > > > > > fd = memfd_secret(SECRETMEM_UNCACHED); > > > ftruncate(fd, MAP_SIZE); > > > ptr = mmap(NULL, MAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); [...] > > > +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. > > Hmm, on x86 it's also Strongly Ordered, but I didn't find any alignment > restrictions. Is there a mode for arm64 that can provide similar > semantics? > > Would it make sence to use something like > > #define pgprot_uncached(prot) \ > __pgprot_modify(prot, PTE_ATTRINDX_MASK, \ > PTE_ATTRINDX(MT_NORMAL_NC) | PTE_PXN) > > or is it too weak? Reading Elena's email, that's about preventing speculative loads. While the arm64 Normal NC is non-cacheable (equivalent to write-combine), a CPU is allowed to speculatively read from it. A carefully crafted gadget could leave an imprint on a different part of the cache via speculative execution based on a value in the secret memory. So IIUC, we want memory that cannot be speculatively loaded from and that would be Device memory on arm64 (with the alignment restrictions). Now, I think we could relax this to Device_GRE. So maybe add a pgprot_nospec() and allow architectures to define whatever they find suitable. The exact semantics will be different between architectures. > > 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. > > Well, the idea of uncached mappings came from Elena [1] to prevent > possibility of side channels that leak user space memory. So I think > even without cache flushing after the allocation, user space is > protected as all its memory accesses bypass cache so even after the page > is freed there won't be stale data in the cache. > > I think that it makes sense to limit SECRETMEM_UNCACHED only for > architectures that define an appropriate protection, e.g. > pgprot_uncahced(). For x86 it can be aliased to pgprot_noncached() and > other architecures can define their versions. Indeed, though as I said above, maybe use a name that suggests no speculation since non-cacheable doesn't always guarantee that. Something like pgprot_nospec() and SECRETMEM_NOSPEC. However, your implementation still has the problem that such memory must have the caches flushed before being mapped in user-space, otherwise we leak other secrets via such pages to the caller. The only generic API we have in the kernel for such things is the DMA one. If hch doesn't mind, you could abuse it and call arch_dma_prep_coherent() prior to set_direct_map_invalid_noflush() (if the mapping is non-cacheable). -- Catalin From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 40DC9C433E1 for ; Fri, 31 Jul 2020 14:10:43 +0000 (UTC) Received: from ml01.01.org (ml01.01.org [198.145.21.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 126552087C for ; Fri, 31 Jul 2020 14:10:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 126552087C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-nvdimm-bounces@lists.01.org Received: from ml01.vlan13.01.org (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id D807812905F80; Fri, 31 Jul 2020 07:10:42 -0700 (PDT) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=198.145.29.99; helo=mail.kernel.org; envelope-from=cmarinas@kernel.org; receiver= Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 64F89128CBC2C for ; Fri, 31 Jul 2020 07:10:39 -0700 (PDT) Received: from gaia (unknown [95.146.230.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 52369206DA; Fri, 31 Jul 2020 14:10:34 +0000 (UTC) Date: Fri, 31 Jul 2020 15:10:31 +0100 From: Catalin Marinas To: Mike Rapoport Subject: Re: [PATCH v2 3/7] mm: introduce memfd_secret system call to create "secret" memory areas Message-ID: <20200731141031.GD29569@gaia> References: <20200727162935.31714-1-rppt@kernel.org> <20200727162935.31714-4-rppt@kernel.org> <20200730162209.GB3128@gaia> <20200730204409.GB534153@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200730204409.GB534153@kernel.org> User-Agent: Mutt/1.10.1 (2018-07-13) Message-ID-Hash: B2VUHDWYETYTHAKHYSB6ZCGCWITPFWSH X-Message-ID-Hash: B2VUHDWYETYTHAKHYSB6ZCGCWITPFWSH X-MailFrom: cmarinas@kernel.org X-Mailman-Rule-Hits: nonmember-moderation X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation CC: linux-kernel@vger.kernel.org, Alexander Viro , Andrew Morton , Andy Lutomirski , Arnd Bergmann , Borislav Petkov , Christopher Lameter , Dave Hansen , Elena Reshetova , "H. Peter Anvin" , Idan Yaniv , Ingo Molnar , James Bottomley , "Kirill A. Shutemov" , Matthew Wilcox , Mike Rapoport , Michael Kerrisk , Palmer Dabbelt , Paul Walmsley , Peter Zijlstra , Thomas Gleixner , Tycho Andersen , Will Deacon , 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 X-Mailman-Version: 3.1.1 Precedence: list List-Id: "Linux-nvdimm developer list." Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Thu, Jul 30, 2020 at 11:44:09PM +0300, Mike Rapoport wrote: > 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: > > > For instance, the following example will create an uncached mapping (error > > > handling is omitted): > > > > > > fd = memfd_secret(SECRETMEM_UNCACHED); > > > ftruncate(fd, MAP_SIZE); > > > ptr = mmap(NULL, MAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); [...] > > > +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. > > Hmm, on x86 it's also Strongly Ordered, but I didn't find any alignment > restrictions. Is there a mode for arm64 that can provide similar > semantics? > > Would it make sence to use something like > > #define pgprot_uncached(prot) \ > __pgprot_modify(prot, PTE_ATTRINDX_MASK, \ > PTE_ATTRINDX(MT_NORMAL_NC) | PTE_PXN) > > or is it too weak? Reading Elena's email, that's about preventing speculative loads. While the arm64 Normal NC is non-cacheable (equivalent to write-combine), a CPU is allowed to speculatively read from it. A carefully crafted gadget could leave an imprint on a different part of the cache via speculative execution based on a value in the secret memory. So IIUC, we want memory that cannot be speculatively loaded from and that would be Device memory on arm64 (with the alignment restrictions). Now, I think we could relax this to Device_GRE. So maybe add a pgprot_nospec() and allow architectures to define whatever they find suitable. The exact semantics will be different between architectures. > > 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. > > Well, the idea of uncached mappings came from Elena [1] to prevent > possibility of side channels that leak user space memory. So I think > even without cache flushing after the allocation, user space is > protected as all its memory accesses bypass cache so even after the page > is freed there won't be stale data in the cache. > > I think that it makes sense to limit SECRETMEM_UNCACHED only for > architectures that define an appropriate protection, e.g. > pgprot_uncahced(). For x86 it can be aliased to pgprot_noncached() and > other architecures can define their versions. Indeed, though as I said above, maybe use a name that suggests no speculation since non-cacheable doesn't always guarantee that. Something like pgprot_nospec() and SECRETMEM_NOSPEC. However, your implementation still has the problem that such memory must have the caches flushed before being mapped in user-space, otherwise we leak other secrets via such pages to the caller. The only generic API we have in the kernel for such things is the DMA one. If hch doesn't mind, you could abuse it and call arch_dma_prep_coherent() prior to set_direct_map_invalid_noflush() (if the mapping is non-cacheable). -- Catalin _______________________________________________ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-leave@lists.01.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9AB27C433DF for ; Fri, 31 Jul 2020 14:11:05 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 644AB206DA for ; Fri, 31 Jul 2020 14:11:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="H2L4g4d7" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 644AB206DA Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=UTOq5mFTFz2EAb65pNKjGb1rQEzcfVYPFr+EM06wluM=; b=H2L4g4d7okstVAN3+a/sKmupg y3YFCsinA3M5bUlxe7nRqvDi/taER/5xH63o9NV5OjAf1RfAZeQU6PTNN3+g0lCIWgPYlL4igmqBB mdJKnxWBMmZtR/I+U6tNmZAzPKVH+zXIrHG5hvJmCVAMJ7CHMVbal/xdgYLL+/DfQPcVH/bNuynmW dufqUsEBQwriDI3tIzmoeE2l9KCdw/e+WybzxwktwlcG0gAkEYL3fUk7UcLOJljkFQfE51wH7jkRF /Vn3UKfMhfprpKrjWgfznDg9xzKS/kuNP31OqOZ0Jsm/QYZw8CCRlbrDAQQwKjiN04tSBXWfGde5b oA55+2hBA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k1VkF-0005RI-6Q; Fri, 31 Jul 2020 14:10:47 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1k1Vk7-0005OQ-Uq; Fri, 31 Jul 2020 14:10:40 +0000 Received: from gaia (unknown [95.146.230.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 52369206DA; Fri, 31 Jul 2020 14:10:34 +0000 (UTC) Date: Fri, 31 Jul 2020 15:10:31 +0100 From: Catalin Marinas To: Mike Rapoport Subject: Re: [PATCH v2 3/7] mm: introduce memfd_secret system call to create "secret" memory areas Message-ID: <20200731141031.GD29569@gaia> References: <20200727162935.31714-1-rppt@kernel.org> <20200727162935.31714-4-rppt@kernel.org> <20200730162209.GB3128@gaia> <20200730204409.GB534153@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200730204409.GB534153@kernel.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200731_101040_126789_DF9E38EB X-CRM114-Status: GOOD ( 36.33 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peter Zijlstra , Dave Hansen , linux-mm@kvack.org, "H. Peter Anvin" , Christopher Lameter , Idan Yaniv , Dan Williams , Elena Reshetova , linux-arch@vger.kernel.org, Tycho Andersen , linux-nvdimm@lists.01.org, Will Deacon , x86@kernel.org, Matthew Wilcox , Mike Rapoport , Ingo Molnar , Michael Kerrisk , Arnd Bergmann , James Bottomley , Borislav Petkov , Alexander Viro , Andy Lutomirski , Paul Walmsley , "Kirill A. Shutemov" , Thomas Gleixner , linux-arm-kernel@lists.infradead.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, Palmer Dabbelt , linux-fsdevel@vger.kernel.org, Andrew Morton Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org On Thu, Jul 30, 2020 at 11:44:09PM +0300, Mike Rapoport wrote: > 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: > > > For instance, the following example will create an uncached mapping (error > > > handling is omitted): > > > > > > fd = memfd_secret(SECRETMEM_UNCACHED); > > > ftruncate(fd, MAP_SIZE); > > > ptr = mmap(NULL, MAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); [...] > > > +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. > > Hmm, on x86 it's also Strongly Ordered, but I didn't find any alignment > restrictions. Is there a mode for arm64 that can provide similar > semantics? > > Would it make sence to use something like > > #define pgprot_uncached(prot) \ > __pgprot_modify(prot, PTE_ATTRINDX_MASK, \ > PTE_ATTRINDX(MT_NORMAL_NC) | PTE_PXN) > > or is it too weak? Reading Elena's email, that's about preventing speculative loads. While the arm64 Normal NC is non-cacheable (equivalent to write-combine), a CPU is allowed to speculatively read from it. A carefully crafted gadget could leave an imprint on a different part of the cache via speculative execution based on a value in the secret memory. So IIUC, we want memory that cannot be speculatively loaded from and that would be Device memory on arm64 (with the alignment restrictions). Now, I think we could relax this to Device_GRE. So maybe add a pgprot_nospec() and allow architectures to define whatever they find suitable. The exact semantics will be different between architectures. > > 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. > > Well, the idea of uncached mappings came from Elena [1] to prevent > possibility of side channels that leak user space memory. So I think > even without cache flushing after the allocation, user space is > protected as all its memory accesses bypass cache so even after the page > is freed there won't be stale data in the cache. > > I think that it makes sense to limit SECRETMEM_UNCACHED only for > architectures that define an appropriate protection, e.g. > pgprot_uncahced(). For x86 it can be aliased to pgprot_noncached() and > other architecures can define their versions. Indeed, though as I said above, maybe use a name that suggests no speculation since non-cacheable doesn't always guarantee that. Something like pgprot_nospec() and SECRETMEM_NOSPEC. However, your implementation still has the problem that such memory must have the caches flushed before being mapped in user-space, otherwise we leak other secrets via such pages to the caller. The only generic API we have in the kernel for such things is the DMA one. If hch doesn't mind, you could abuse it and call arch_dma_prep_coherent() prior to set_direct_map_invalid_noflush() (if the mapping is non-cacheable). -- Catalin _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 864D6C433E0 for ; Fri, 31 Jul 2020 14:12:23 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4F13D206DA for ; Fri, 31 Jul 2020 14:12:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="vpGoikL2" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4F13D206DA Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=2+IJ99Vx8FdbJ31+IDAg/wscj5gRQvNFmKhHo3j2ul0=; b=vpGoikL2bb/JScZ+juWmWx16H sXVD7uSY3GMQcYcsfR+UAthz0opyxHKrh1BQ+bRu5Qnu5YXQD1tJP2jPDvnSyOxZE0dVXzNMkpqJg Iz4RVlWqY5uhab0m4fLZ4342fuXMNku3TQDIotau9qIyr4EMMoNgPrGOmvzo5D3xE8lXZ+kvX0Bsa 8qnKJwqWcY3GqGRC/tpTaJjpIG2TLtJN38A40uHRDz/EXUeyxI3mHGyAtsDqGBhNEAmvHDionssfq rKWizLYml1cynWLHQboXV3GJamAs1yvYMZwLlCGb/5mqJm4Blq6ctFx+hfgEFDEK8tV6IywACMDTY EoEJOieMg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k1VkA-0005PC-1e; Fri, 31 Jul 2020 14:10:42 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1k1Vk7-0005OQ-Uq; Fri, 31 Jul 2020 14:10:40 +0000 Received: from gaia (unknown [95.146.230.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 52369206DA; Fri, 31 Jul 2020 14:10:34 +0000 (UTC) Date: Fri, 31 Jul 2020 15:10:31 +0100 From: Catalin Marinas To: Mike Rapoport Subject: Re: [PATCH v2 3/7] mm: introduce memfd_secret system call to create "secret" memory areas Message-ID: <20200731141031.GD29569@gaia> References: <20200727162935.31714-1-rppt@kernel.org> <20200727162935.31714-4-rppt@kernel.org> <20200730162209.GB3128@gaia> <20200730204409.GB534153@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200730204409.GB534153@kernel.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200731_101040_126789_DF9E38EB X-CRM114-Status: GOOD ( 36.33 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peter Zijlstra , Dave Hansen , linux-mm@kvack.org, "H. Peter Anvin" , Christopher Lameter , Idan Yaniv , Dan Williams , Elena Reshetova , linux-arch@vger.kernel.org, Tycho Andersen , linux-nvdimm@lists.01.org, Will Deacon , x86@kernel.org, Matthew Wilcox , Mike Rapoport , Ingo Molnar , Michael Kerrisk , Arnd Bergmann , James Bottomley , Borislav Petkov , Alexander Viro , Andy Lutomirski , Paul Walmsley , "Kirill A. Shutemov" , Thomas Gleixner , linux-arm-kernel@lists.infradead.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, Palmer Dabbelt , linux-fsdevel@vger.kernel.org, Andrew Morton Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Jul 30, 2020 at 11:44:09PM +0300, Mike Rapoport wrote: > 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: > > > For instance, the following example will create an uncached mapping (error > > > handling is omitted): > > > > > > fd = memfd_secret(SECRETMEM_UNCACHED); > > > ftruncate(fd, MAP_SIZE); > > > ptr = mmap(NULL, MAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); [...] > > > +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. > > Hmm, on x86 it's also Strongly Ordered, but I didn't find any alignment > restrictions. Is there a mode for arm64 that can provide similar > semantics? > > Would it make sence to use something like > > #define pgprot_uncached(prot) \ > __pgprot_modify(prot, PTE_ATTRINDX_MASK, \ > PTE_ATTRINDX(MT_NORMAL_NC) | PTE_PXN) > > or is it too weak? Reading Elena's email, that's about preventing speculative loads. While the arm64 Normal NC is non-cacheable (equivalent to write-combine), a CPU is allowed to speculatively read from it. A carefully crafted gadget could leave an imprint on a different part of the cache via speculative execution based on a value in the secret memory. So IIUC, we want memory that cannot be speculatively loaded from and that would be Device memory on arm64 (with the alignment restrictions). Now, I think we could relax this to Device_GRE. So maybe add a pgprot_nospec() and allow architectures to define whatever they find suitable. The exact semantics will be different between architectures. > > 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. > > Well, the idea of uncached mappings came from Elena [1] to prevent > possibility of side channels that leak user space memory. So I think > even without cache flushing after the allocation, user space is > protected as all its memory accesses bypass cache so even after the page > is freed there won't be stale data in the cache. > > I think that it makes sense to limit SECRETMEM_UNCACHED only for > architectures that define an appropriate protection, e.g. > pgprot_uncahced(). For x86 it can be aliased to pgprot_noncached() and > other architecures can define their versions. Indeed, though as I said above, maybe use a name that suggests no speculation since non-cacheable doesn't always guarantee that. Something like pgprot_nospec() and SECRETMEM_NOSPEC. However, your implementation still has the problem that such memory must have the caches flushed before being mapped in user-space, otherwise we leak other secrets via such pages to the caller. The only generic API we have in the kernel for such things is the DMA one. If hch doesn't mind, you could abuse it and call arch_dma_prep_coherent() prior to set_direct_map_invalid_noflush() (if the mapping is non-cacheable). -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel