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=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 E39A5C433DF for ; Thu, 30 Jul 2020 20:44:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BCA552083E for ; Thu, 30 Jul 2020 20:44:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1596141867; bh=sZKYPMSX12eBmbaRqySKTHS1smjkmdh3zWo010nIk8M=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=gzGyBcZOn8EPKhz3+obHlGe68EjIXg/EeZdnaurtxffQUKon4uO67nc8XSQBPJcsi WXHrdZZ3B7UTTAKntpimyXh9KHP25jqfvl1rHO/cFpzjMFVDqq0uj2wPOwk9OkufCv Ua9N2HxuzmPubqsm4Z4iK7IJBq8/sP//QeGI7qbc= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728612AbgG3Uo1 (ORCPT ); Thu, 30 Jul 2020 16:44:27 -0400 Received: from mail.kernel.org ([198.145.29.99]:39082 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728586AbgG3Uo1 (ORCPT ); Thu, 30 Jul 2020 16:44:27 -0400 Received: from kernel.org (unknown [87.70.91.42]) (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 715E220838; Thu, 30 Jul 2020 20:44:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1596141866; bh=sZKYPMSX12eBmbaRqySKTHS1smjkmdh3zWo010nIk8M=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=BmsOo3YUFCDw4gkyz7ZfQOn2kMn5QK/7KTwPtnQBqKiwbYcNBoz+qwKW/hGKQwn6F B9NMUdyu3EPJylOAMbuE0DD99sT3k6OWuEoKFMV4rR/rqwql2n/fAPL1B+he1E2TFF 0UoU05MxTEQpp1qzhn8HCcZC6Zx2ZqD62fqBrpYw= Date: Thu, 30 Jul 2020 23:44:09 +0300 From: Mike Rapoport To: Catalin Marinas 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: <20200730204409.GB534153@kernel.org> References: <20200727162935.31714-1-rppt@kernel.org> <20200727162935.31714-4-rppt@kernel.org> <20200730162209.GB3128@gaia> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200730162209.GB3128@gaia> 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 05:22:10PM +0100, Catalin Marinas wrote: > Hi Mike, > > 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 struct page *secretmem_alloc_page(gfp_t gfp) > > +{ > > + /* > > + * FIXME: use a cache of large pages to reduce the direct map > > + * fragmentation > > + */ > > + return alloc_page(gfp); > > +} > > + > > +static vm_fault_t secretmem_fault(struct vm_fault *vmf) > > +{ > > + struct address_space *mapping = vmf->vma->vm_file->f_mapping; > > + struct inode *inode = file_inode(vmf->vma->vm_file); > > + pgoff_t offset = vmf->pgoff; > > + unsigned long addr; > > + struct page *page; > > + int ret = 0; > > + > > + if (((loff_t)vmf->pgoff << PAGE_SHIFT) >= i_size_read(inode)) > > + return vmf_error(-EINVAL); > > + > > + page = find_get_entry(mapping, offset); > > + if (!page) { > > + page = secretmem_alloc_page(vmf->gfp_mask); > > + if (!page) > > + return vmf_error(-ENOMEM); > > + > > + ret = add_to_page_cache(page, mapping, offset, vmf->gfp_mask); > > + if (unlikely(ret)) > > + goto err_put_page; > > + > > + ret = set_direct_map_invalid_noflush(page); > > + if (ret) > > + goto err_del_page_cache; > > + > > + addr = (unsigned long)page_address(page); > > + flush_tlb_kernel_range(addr, addr + PAGE_SIZE); > > + > > + __SetPageUptodate(page); > > + > > + ret = VM_FAULT_LOCKED; > > + } > > + > > + vmf->page = page; > > + return ret; > > + > > +err_del_page_cache: > > + delete_from_page_cache(page); > > +err_put_page: > > + put_page(page); > > + return vmf_error(ret); > > +} > > + > > +static const struct vm_operations_struct secretmem_vm_ops = { > > + .fault = secretmem_fault, > > +}; > > + > > +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? > 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. [1] https://lore.kernel.org/lkml/2236FBA76BA1254E88B949DDB74E612BA4EEC0CE@IRSMSX102.ger.corp.intel.com/ -- Sincerely yours, Mike. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Rapoport Subject: Re: [PATCH v2 3/7] mm: introduce memfd_secret system call to create "secret" memory areas Date: Thu, 30 Jul 2020 23:44:09 +0300 Message-ID: <20200730204409.GB534153@kernel.org> References: <20200727162935.31714-1-rppt@kernel.org> <20200727162935.31714-4-rppt@kernel.org> <20200730162209.GB3128@gaia> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20200730162209.GB3128@gaia> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Catalin Marinas 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 05:22:10PM +0100, Catalin Marinas wrote: > Hi Mike, > > 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 struct page *secretmem_alloc_page(gfp_t gfp) > > +{ > > + /* > > + * FIXME: use a cache of large pages to reduce the direct map > > + * fragmentation > > + */ > > + return alloc_page(gfp); > > +} > > + > > +static vm_fault_t secretmem_fault(struct vm_fault *vmf) > > +{ > > + struct address_space *mapping = vmf->vma->vm_file->f_mapping; > > + struct inode *inode = file_inode(vmf->vma->vm_file); > > + pgoff_t offset = vmf->pgoff; > > + unsigned long addr; > > + struct page *page; > > + int ret = 0; > > + > > + if (((loff_t)vmf->pgoff << PAGE_SHIFT) >= i_size_read(inode)) > > + return vmf_error(-EINVAL); > > + > > + page = find_get_entry(mapping, offset); > > + if (!page) { > > + page = secretmem_alloc_page(vmf->gfp_mask); > > + if (!page) > > + return vmf_error(-ENOMEM); > > + > > + ret = add_to_page_cache(page, mapping, offset, vmf->gfp_mask); > > + if (unlikely(ret)) > > + goto err_put_page; > > + > > + ret = set_direct_map_invalid_noflush(page); > > + if (ret) > > + goto err_del_page_cache; > > + > > + addr = (unsigned long)page_address(page); > > + flush_tlb_kernel_range(addr, addr + PAGE_SIZE); > > + > > + __SetPageUptodate(page); > > + > > + ret = VM_FAULT_LOCKED; > > + } > > + > > + vmf->page = page; > > + return ret; > > + > > +err_del_page_cache: > > + delete_from_page_cache(page); > > +err_put_page: > > + put_page(page); > > + return vmf_error(ret); > > +} > > + > > +static const struct vm_operations_struct secretmem_vm_ops = { > > + .fault = secretmem_fault, > > +}; > > + > > +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? > 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. [1] https://lore.kernel.org/lkml/2236FBA76BA1254E88B949DDB74E612BA4EEC0CE-kPTMFJFq+rFP9JyJpTNKArfspsVTdybXVpNB7YpNyf8@public.gmane.org/ -- Sincerely yours, Mike. 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=-3.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 B471CC433E0 for ; Thu, 30 Jul 2020 20:44:32 +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 5C5A52083E for ; Thu, 30 Jul 2020 20:44:32 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="BmsOo3YU" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5C5A52083E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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 3E14C1274FC22; Thu, 30 Jul 2020 13:44:32 -0700 (PDT) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=198.145.29.99; helo=mail.kernel.org; envelope-from=rppt@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 A2B1F126114AB for ; Thu, 30 Jul 2020 13:44:26 -0700 (PDT) Received: from kernel.org (unknown [87.70.91.42]) (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 715E220838; Thu, 30 Jul 2020 20:44:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1596141866; bh=sZKYPMSX12eBmbaRqySKTHS1smjkmdh3zWo010nIk8M=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=BmsOo3YUFCDw4gkyz7ZfQOn2kMn5QK/7KTwPtnQBqKiwbYcNBoz+qwKW/hGKQwn6F B9NMUdyu3EPJylOAMbuE0DD99sT3k6OWuEoKFMV4rR/rqwql2n/fAPL1B+he1E2TFF 0UoU05MxTEQpp1qzhn8HCcZC6Zx2ZqD62fqBrpYw= Date: Thu, 30 Jul 2020 23:44:09 +0300 From: Mike Rapoport To: Catalin Marinas Subject: Re: [PATCH v2 3/7] mm: introduce memfd_secret system call to create "secret" memory areas Message-ID: <20200730204409.GB534153@kernel.org> References: <20200727162935.31714-1-rppt@kernel.org> <20200727162935.31714-4-rppt@kernel.org> <20200730162209.GB3128@gaia> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200730162209.GB3128@gaia> Message-ID-Hash: VJCI3FASTZPAD6CG4U7MKUSVWQOKYH4C X-Message-ID-Hash: VJCI3FASTZPAD6CG4U7MKUSVWQOKYH4C X-MailFrom: rppt@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 05:22:10PM +0100, Catalin Marinas wrote: > Hi Mike, > > 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 struct page *secretmem_alloc_page(gfp_t gfp) > > +{ > > + /* > > + * FIXME: use a cache of large pages to reduce the direct map > > + * fragmentation > > + */ > > + return alloc_page(gfp); > > +} > > + > > +static vm_fault_t secretmem_fault(struct vm_fault *vmf) > > +{ > > + struct address_space *mapping = vmf->vma->vm_file->f_mapping; > > + struct inode *inode = file_inode(vmf->vma->vm_file); > > + pgoff_t offset = vmf->pgoff; > > + unsigned long addr; > > + struct page *page; > > + int ret = 0; > > + > > + if (((loff_t)vmf->pgoff << PAGE_SHIFT) >= i_size_read(inode)) > > + return vmf_error(-EINVAL); > > + > > + page = find_get_entry(mapping, offset); > > + if (!page) { > > + page = secretmem_alloc_page(vmf->gfp_mask); > > + if (!page) > > + return vmf_error(-ENOMEM); > > + > > + ret = add_to_page_cache(page, mapping, offset, vmf->gfp_mask); > > + if (unlikely(ret)) > > + goto err_put_page; > > + > > + ret = set_direct_map_invalid_noflush(page); > > + if (ret) > > + goto err_del_page_cache; > > + > > + addr = (unsigned long)page_address(page); > > + flush_tlb_kernel_range(addr, addr + PAGE_SIZE); > > + > > + __SetPageUptodate(page); > > + > > + ret = VM_FAULT_LOCKED; > > + } > > + > > + vmf->page = page; > > + return ret; > > + > > +err_del_page_cache: > > + delete_from_page_cache(page); > > +err_put_page: > > + put_page(page); > > + return vmf_error(ret); > > +} > > + > > +static const struct vm_operations_struct secretmem_vm_ops = { > > + .fault = secretmem_fault, > > +}; > > + > > +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? > 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. [1] https://lore.kernel.org/lkml/2236FBA76BA1254E88B949DDB74E612BA4EEC0CE@IRSMSX102.ger.corp.intel.com/ -- Sincerely yours, Mike. _______________________________________________ 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=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 0F3FEC433E0 for ; Thu, 30 Jul 2020 20:44:51 +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 C92F620838 for ; Thu, 30 Jul 2020 20:44:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="qTjI4DG+"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="BmsOo3YU" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C92F620838 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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=hXfDGo0VgCOjbx7jKVaLanLh//sc4fFRAmX2P2NyVQU=; b=qTjI4DG+WgrWN7JuHoudf8GkX wfeKNXbaUaRXjFqxNdLGXSCRvZmHXmvH7D+wKKFaRh9WyZTAvvulfKlFZ3BZHqGmqjC9FzggYYaOk OupIaeLp8cKWDMg4GKBZ72As3WX59F+dineo/duXTyfNsIoszebJiE2Nm5pE4mKMlR9zdSCMtBpTY p6KeMqxtimcXmQ3zP3+kj5bQx+KgkXX9IAKX/Fe74VL9tk0fNuMEygdLBZfA+ILi3eCEHt0dHe0yy jOWTLKr18fO9Q5bD6Z4AheTOXHyGvmq+ZU353Ws9gpPbGsSkAVPdvDoxKd78cRHLwHLteMgXrooCw zVApXMJbQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k1FPl-000499-1c; Thu, 30 Jul 2020 20:44:33 +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 1k1FPg-000477-BM; Thu, 30 Jul 2020 20:44:29 +0000 Received: from kernel.org (unknown [87.70.91.42]) (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 715E220838; Thu, 30 Jul 2020 20:44:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1596141866; bh=sZKYPMSX12eBmbaRqySKTHS1smjkmdh3zWo010nIk8M=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=BmsOo3YUFCDw4gkyz7ZfQOn2kMn5QK/7KTwPtnQBqKiwbYcNBoz+qwKW/hGKQwn6F B9NMUdyu3EPJylOAMbuE0DD99sT3k6OWuEoKFMV4rR/rqwql2n/fAPL1B+he1E2TFF 0UoU05MxTEQpp1qzhn8HCcZC6Zx2ZqD62fqBrpYw= Date: Thu, 30 Jul 2020 23:44:09 +0300 From: Mike Rapoport To: Catalin Marinas Subject: Re: [PATCH v2 3/7] mm: introduce memfd_secret system call to create "secret" memory areas Message-ID: <20200730204409.GB534153@kernel.org> References: <20200727162935.31714-1-rppt@kernel.org> <20200727162935.31714-4-rppt@kernel.org> <20200730162209.GB3128@gaia> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200730162209.GB3128@gaia> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200730_164428_511895_9B7B9C07 X-CRM114-Status: GOOD ( 30.74 ) 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 05:22:10PM +0100, Catalin Marinas wrote: > Hi Mike, > > 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 struct page *secretmem_alloc_page(gfp_t gfp) > > +{ > > + /* > > + * FIXME: use a cache of large pages to reduce the direct map > > + * fragmentation > > + */ > > + return alloc_page(gfp); > > +} > > + > > +static vm_fault_t secretmem_fault(struct vm_fault *vmf) > > +{ > > + struct address_space *mapping = vmf->vma->vm_file->f_mapping; > > + struct inode *inode = file_inode(vmf->vma->vm_file); > > + pgoff_t offset = vmf->pgoff; > > + unsigned long addr; > > + struct page *page; > > + int ret = 0; > > + > > + if (((loff_t)vmf->pgoff << PAGE_SHIFT) >= i_size_read(inode)) > > + return vmf_error(-EINVAL); > > + > > + page = find_get_entry(mapping, offset); > > + if (!page) { > > + page = secretmem_alloc_page(vmf->gfp_mask); > > + if (!page) > > + return vmf_error(-ENOMEM); > > + > > + ret = add_to_page_cache(page, mapping, offset, vmf->gfp_mask); > > + if (unlikely(ret)) > > + goto err_put_page; > > + > > + ret = set_direct_map_invalid_noflush(page); > > + if (ret) > > + goto err_del_page_cache; > > + > > + addr = (unsigned long)page_address(page); > > + flush_tlb_kernel_range(addr, addr + PAGE_SIZE); > > + > > + __SetPageUptodate(page); > > + > > + ret = VM_FAULT_LOCKED; > > + } > > + > > + vmf->page = page; > > + return ret; > > + > > +err_del_page_cache: > > + delete_from_page_cache(page); > > +err_put_page: > > + put_page(page); > > + return vmf_error(ret); > > +} > > + > > +static const struct vm_operations_struct secretmem_vm_ops = { > > + .fault = secretmem_fault, > > +}; > > + > > +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? > 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. [1] https://lore.kernel.org/lkml/2236FBA76BA1254E88B949DDB74E612BA4EEC0CE@IRSMSX102.ger.corp.intel.com/ -- Sincerely yours, Mike. _______________________________________________ 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=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 28F0BC433DF for ; Thu, 30 Jul 2020 20:46:17 +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 E2BB82083E for ; Thu, 30 Jul 2020 20:46:16 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="qzPYFR9O"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="BmsOo3YU" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E2BB82083E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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=mFHLDuxi0GnD81C6dzTh2seGetgh4j00WUJnRUWjYj8=; b=qzPYFR9OOBY4zWKSGRcrwvNil dBZMbFcfIHFnIRojcwszWhsmYx894MiVYVhxuk56BtflCaNTKGwcEQ41XjJrkcxTcMtafdvu7xJzu WK9UCi5Lde8TUgsjuuZzzA5oarvipStYwOCOPdja7qJ6KhjmDE3qOd4Vmh37iGJBs7knr4ypvaKHI q+alyfZ9XL0NIZiAEQKKNt1HTC1UuNcG0U+d0/D60ogYJUunRwp21Y11kPNvCS7Smrn5fVYeVCm+a 5JKfLtQWxT/z8pMSAEYxvm0bU4svmJXPkH38EUxoMSvnxpX0Oc2J7VpeBlXEehWc01XtCo+9Y4inR n4kCkg0UQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k1FPj-00048T-BY; Thu, 30 Jul 2020 20:44:31 +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 1k1FPg-000477-BM; Thu, 30 Jul 2020 20:44:29 +0000 Received: from kernel.org (unknown [87.70.91.42]) (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 715E220838; Thu, 30 Jul 2020 20:44:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1596141866; bh=sZKYPMSX12eBmbaRqySKTHS1smjkmdh3zWo010nIk8M=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=BmsOo3YUFCDw4gkyz7ZfQOn2kMn5QK/7KTwPtnQBqKiwbYcNBoz+qwKW/hGKQwn6F B9NMUdyu3EPJylOAMbuE0DD99sT3k6OWuEoKFMV4rR/rqwql2n/fAPL1B+he1E2TFF 0UoU05MxTEQpp1qzhn8HCcZC6Zx2ZqD62fqBrpYw= Date: Thu, 30 Jul 2020 23:44:09 +0300 From: Mike Rapoport To: Catalin Marinas Subject: Re: [PATCH v2 3/7] mm: introduce memfd_secret system call to create "secret" memory areas Message-ID: <20200730204409.GB534153@kernel.org> References: <20200727162935.31714-1-rppt@kernel.org> <20200727162935.31714-4-rppt@kernel.org> <20200730162209.GB3128@gaia> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200730162209.GB3128@gaia> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200730_164428_511895_9B7B9C07 X-CRM114-Status: GOOD ( 30.74 ) 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 05:22:10PM +0100, Catalin Marinas wrote: > Hi Mike, > > 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 struct page *secretmem_alloc_page(gfp_t gfp) > > +{ > > + /* > > + * FIXME: use a cache of large pages to reduce the direct map > > + * fragmentation > > + */ > > + return alloc_page(gfp); > > +} > > + > > +static vm_fault_t secretmem_fault(struct vm_fault *vmf) > > +{ > > + struct address_space *mapping = vmf->vma->vm_file->f_mapping; > > + struct inode *inode = file_inode(vmf->vma->vm_file); > > + pgoff_t offset = vmf->pgoff; > > + unsigned long addr; > > + struct page *page; > > + int ret = 0; > > + > > + if (((loff_t)vmf->pgoff << PAGE_SHIFT) >= i_size_read(inode)) > > + return vmf_error(-EINVAL); > > + > > + page = find_get_entry(mapping, offset); > > + if (!page) { > > + page = secretmem_alloc_page(vmf->gfp_mask); > > + if (!page) > > + return vmf_error(-ENOMEM); > > + > > + ret = add_to_page_cache(page, mapping, offset, vmf->gfp_mask); > > + if (unlikely(ret)) > > + goto err_put_page; > > + > > + ret = set_direct_map_invalid_noflush(page); > > + if (ret) > > + goto err_del_page_cache; > > + > > + addr = (unsigned long)page_address(page); > > + flush_tlb_kernel_range(addr, addr + PAGE_SIZE); > > + > > + __SetPageUptodate(page); > > + > > + ret = VM_FAULT_LOCKED; > > + } > > + > > + vmf->page = page; > > + return ret; > > + > > +err_del_page_cache: > > + delete_from_page_cache(page); > > +err_put_page: > > + put_page(page); > > + return vmf_error(ret); > > +} > > + > > +static const struct vm_operations_struct secretmem_vm_ops = { > > + .fault = secretmem_fault, > > +}; > > + > > +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? > 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. [1] https://lore.kernel.org/lkml/2236FBA76BA1254E88B949DDB74E612BA4EEC0CE@IRSMSX102.ger.corp.intel.com/ -- Sincerely yours, Mike. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel