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.3 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 151C5C6379D for ; Tue, 24 Nov 2020 11:00:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BC1E520872 for ; Tue, 24 Nov 2020 11:00:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732381AbgKXK76 (ORCPT ); Tue, 24 Nov 2020 05:59:58 -0500 Received: from mail.kernel.org ([198.145.29.99]:59012 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732373AbgKXK76 (ORCPT ); Tue, 24 Nov 2020 05:59:58 -0500 Received: from gaia (unknown [95.146.230.165]) (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 BBA3E2076B; Tue, 24 Nov 2020 10:59:50 +0000 (UTC) Date: Tue, 24 Nov 2020 10:59:48 +0000 From: Catalin Marinas To: Mike Rapoport Cc: Andrew Morton , Alexander Viro , Andy Lutomirski , Arnd Bergmann , Borislav Petkov , Christopher Lameter , Dan Williams , Dave Hansen , David Hildenbrand , Elena Reshetova , "H. Peter Anvin" , Ingo Molnar , James Bottomley , "Kirill A. Shutemov" , Matthew Wilcox , Mark Rutland , Mike Rapoport , Michael Kerrisk , Palmer Dabbelt , Paul Walmsley , Peter Zijlstra , Rick Edgecombe , Roman Gushchin , Shuah Khan , 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-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-nvdimm@lists.01.org, linux-riscv@lists.infradead.org, x86@kernel.org, Hagen Paul Pfeifer Subject: Re: [PATCH v11 4/9] mm: introduce memfd_secret system call to create "secret" memory areas Message-ID: <20201124105947.GA5527@gaia> References: <20201124092556.12009-1-rppt@kernel.org> <20201124092556.12009-5-rppt@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201124092556.12009-5-rppt@kernel.org> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org Hi Mike, On Tue, Nov 24, 2020 at 11:25:51AM +0200, Mike Rapoport wrote: > +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; > + vm_fault_t ret = 0; > + unsigned long addr; > + struct page *page; > + int err; > + > + if (((loff_t)vmf->pgoff << PAGE_SHIFT) >= i_size_read(inode)) > + return vmf_error(-EINVAL); > + > + page = find_get_page(mapping, offset); > + if (!page) { > + > + page = secretmem_alloc_page(vmf->gfp_mask); > + if (!page) > + return vmf_error(-ENOMEM); > + > + err = add_to_page_cache(page, mapping, offset, vmf->gfp_mask); > + if (unlikely(err)) > + goto err_put_page; > + > + err = set_direct_map_invalid_noflush(page, 1); > + if (err) > + goto err_del_page_cache; On arm64, set_direct_map_default_noflush() returns 0 if !rodata_full but no pgtable changes happen since the linear map can be a mix of small and huge pages. The arm64 implementation doesn't break large mappings. I presume we don't want to tell the user that the designated memory is "secret" but the kernel silently ignored it. We could change the arm64 set_direct_map* to return an error, however, I think it would be pretty unexpected for the user to get a fault when trying to access it. It may be better to return a -ENOSYS or something on the actual syscall if the fault-in wouldn't be allowed later. Alternatively, we could make the linear map always use pages on arm64, irrespective of other config or cmdline options (maybe not justified unless we have clear memsecret users). Yet another idea is to get set_direct_map* to break pmd/pud mappings into pte but that's not always possible without a stop_machine() and potentially disabling the MMU. > + > + 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(err); > +} -- 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.2 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 A4622C56201 for ; Tue, 24 Nov 2020 11:00:01 +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 4377120782 for ; Tue, 24 Nov 2020 11:00:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4377120782 Authentication-Results: mail.kernel.org; dmarc=fail (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 A6F74100EB82E; Tue, 24 Nov 2020 03:00:00 -0800 (PST) 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 CC64A100EF252 for ; Tue, 24 Nov 2020 02:59:57 -0800 (PST) Received: from gaia (unknown [95.146.230.165]) (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 BBA3E2076B; Tue, 24 Nov 2020 10:59:50 +0000 (UTC) Date: Tue, 24 Nov 2020 10:59:48 +0000 From: Catalin Marinas To: Mike Rapoport Subject: Re: [PATCH v11 4/9] mm: introduce memfd_secret system call to create "secret" memory areas Message-ID: <20201124105947.GA5527@gaia> References: <20201124092556.12009-1-rppt@kernel.org> <20201124092556.12009-5-rppt@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20201124092556.12009-5-rppt@kernel.org> User-Agent: Mutt/1.10.1 (2018-07-13) Message-ID-Hash: W2FI2BDYLQ3FMT4ARLHWXZOEWCBGQOA3 X-Message-ID-Hash: W2FI2BDYLQ3FMT4ARLHWXZOEWCBGQOA3 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: Andrew Morton , Alexander Viro , Andy Lutomirski , Arnd Bergmann , Borislav Petkov , Christopher Lameter , Dave Hansen , David Hildenbrand , Elena Reshetova , "H. Peter Anvin" , Ingo Molnar , James Bottomley , "Kirill A. Shutemov" , Matthew Wilcox , Mark Rutland , Mike Rapoport , Michael Kerrisk , Palmer Dabbelt , Paul Walmsley , Peter Zijlstra , Rick Edgecombe , Roman Gushchin , Shuah Khan , 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-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-nvdimm@lists.01.org, linux-riscv@lists.infradead.org, x86@kernel.org, Hagen Paul Pfeifer 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 Hi Mike, On Tue, Nov 24, 2020 at 11:25:51AM +0200, Mike Rapoport wrote: > +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; > + vm_fault_t ret = 0; > + unsigned long addr; > + struct page *page; > + int err; > + > + if (((loff_t)vmf->pgoff << PAGE_SHIFT) >= i_size_read(inode)) > + return vmf_error(-EINVAL); > + > + page = find_get_page(mapping, offset); > + if (!page) { > + > + page = secretmem_alloc_page(vmf->gfp_mask); > + if (!page) > + return vmf_error(-ENOMEM); > + > + err = add_to_page_cache(page, mapping, offset, vmf->gfp_mask); > + if (unlikely(err)) > + goto err_put_page; > + > + err = set_direct_map_invalid_noflush(page, 1); > + if (err) > + goto err_del_page_cache; On arm64, set_direct_map_default_noflush() returns 0 if !rodata_full but no pgtable changes happen since the linear map can be a mix of small and huge pages. The arm64 implementation doesn't break large mappings. I presume we don't want to tell the user that the designated memory is "secret" but the kernel silently ignored it. We could change the arm64 set_direct_map* to return an error, however, I think it would be pretty unexpected for the user to get a fault when trying to access it. It may be better to return a -ENOSYS or something on the actual syscall if the fault-in wouldn't be allowed later. Alternatively, we could make the linear map always use pages on arm64, irrespective of other config or cmdline options (maybe not justified unless we have clear memsecret users). Yet another idea is to get set_direct_map* to break pmd/pud mappings into pte but that's not always possible without a stop_machine() and potentially disabling the MMU. > + > + 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(err); > +} -- 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.3 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 2F17FC2D0E4 for ; Tue, 24 Nov 2020 11:00:16 +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 B2C9F2076B for ; Tue, 24 Nov 2020 11:00:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Voe6pFVw" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B2C9F2076B Authentication-Results: mail.kernel.org; dmarc=fail (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=ISKI3ZFCHTK8SFtCbUlmNSeuZXVsUI0MQg34pco9oJ8=; b=Voe6pFVwIlzYgyjHCgX2Lci5R KF3qnsUgivNGW9T7uexG49gABkEcbrT1urD17FEYCM+zXopI6wC+FveWxr2vUF6MPDvk7WoJFVL0Z twrO0JlNhha6FndLW7e0HFIqlD301QZpxDjX9brYwmR7MxaPZ5e0NCETOpG8/lGx06zjtfmMDpLMz xKw7KEo17FgPY+xxcLyPtwBfj5Et3w8Sr4APZjUTtooXSs6W2iSNvg6+H6sZE4t+sihAbSDmsn7dX v2r02CnHESeF6xukc6b/SOO/EVZDgRUmjHG08VrFQWS5T49iTmRp7Er+PC0muweQdEtjZSr+17BQw Fqv+AfSoA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1khW3M-0005ph-Uu; Tue, 24 Nov 2020 11:00:09 +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 1khW3C-0005lL-7L; Tue, 24 Nov 2020 11:00:01 +0000 Received: from gaia (unknown [95.146.230.165]) (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 BBA3E2076B; Tue, 24 Nov 2020 10:59:50 +0000 (UTC) Date: Tue, 24 Nov 2020 10:59:48 +0000 From: Catalin Marinas To: Mike Rapoport Subject: Re: [PATCH v11 4/9] mm: introduce memfd_secret system call to create "secret" memory areas Message-ID: <20201124105947.GA5527@gaia> References: <20201124092556.12009-1-rppt@kernel.org> <20201124092556.12009-5-rppt@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20201124092556.12009-5-rppt@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-20201124_055958_454358_78DAC0B7 X-CRM114-Status: GOOD ( 20.46 ) 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: Mark Rutland , David Hildenbrand , Peter Zijlstra , Dave Hansen , linux-mm@kvack.org, linux-kselftest@vger.kernel.org, "H. Peter Anvin" , Christopher Lameter , Shuah Khan , Thomas Gleixner , 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 , Hagen Paul Pfeifer , Borislav Petkov , Alexander Viro , Andy Lutomirski , Paul Walmsley , "Kirill A. Shutemov" , Dan Williams , 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 , Rick Edgecombe , Roman Gushchin 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 Hi Mike, On Tue, Nov 24, 2020 at 11:25:51AM +0200, Mike Rapoport wrote: > +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; > + vm_fault_t ret = 0; > + unsigned long addr; > + struct page *page; > + int err; > + > + if (((loff_t)vmf->pgoff << PAGE_SHIFT) >= i_size_read(inode)) > + return vmf_error(-EINVAL); > + > + page = find_get_page(mapping, offset); > + if (!page) { > + > + page = secretmem_alloc_page(vmf->gfp_mask); > + if (!page) > + return vmf_error(-ENOMEM); > + > + err = add_to_page_cache(page, mapping, offset, vmf->gfp_mask); > + if (unlikely(err)) > + goto err_put_page; > + > + err = set_direct_map_invalid_noflush(page, 1); > + if (err) > + goto err_del_page_cache; On arm64, set_direct_map_default_noflush() returns 0 if !rodata_full but no pgtable changes happen since the linear map can be a mix of small and huge pages. The arm64 implementation doesn't break large mappings. I presume we don't want to tell the user that the designated memory is "secret" but the kernel silently ignored it. We could change the arm64 set_direct_map* to return an error, however, I think it would be pretty unexpected for the user to get a fault when trying to access it. It may be better to return a -ENOSYS or something on the actual syscall if the fault-in wouldn't be allowed later. Alternatively, we could make the linear map always use pages on arm64, irrespective of other config or cmdline options (maybe not justified unless we have clear memsecret users). Yet another idea is to get set_direct_map* to break pmd/pud mappings into pte but that's not always possible without a stop_machine() and potentially disabling the MMU. > + > + 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(err); > +} -- 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.3 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 E7D51C2D0E4 for ; Tue, 24 Nov 2020 11:00:35 +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 6F11F2076E for ; Tue, 24 Nov 2020 11:00:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="heiN3MEQ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6F11F2076E Authentication-Results: mail.kernel.org; dmarc=fail (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=4g8vtUFFN0eXy3CSqHeb0J+gfY1NeTrGLL4EZ26/liA=; b=heiN3MEQQcSTHJXWzJoK6zHRT 9ndjCCCOlC/w7Nm5tLgfzla5LocmoMS3wvrNJrrWzlZ8R2+4hzq+EkrHKyi6nUSrOP8fXX4UjURXf 9DOKomCohLAJgu8IdFLl8+xvSzVs+anKXosddFoxpIOwbvY1uFMjbBgqHdWBnGIjPIiR9d9rRmX+W jpwjTe4j3GyxJQdkbLmyUAOhvCTXGPwd8BGoYocFxlLGAmNUeUQ4wHi+bPUFOyCUFLIyN/9iIJXCG xiS6YX+0g+Apt423OJJ8f/j6ElDtzfiGKZAB3U3mjk0x+2IxnCeMc3Me5gXJQB+ymGFWjLlQE6ETX wMALxXYcA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1khW3I-0005o2-DO; Tue, 24 Nov 2020 11:00:04 +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 1khW3C-0005lL-7L; Tue, 24 Nov 2020 11:00:01 +0000 Received: from gaia (unknown [95.146.230.165]) (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 BBA3E2076B; Tue, 24 Nov 2020 10:59:50 +0000 (UTC) Date: Tue, 24 Nov 2020 10:59:48 +0000 From: Catalin Marinas To: Mike Rapoport Subject: Re: [PATCH v11 4/9] mm: introduce memfd_secret system call to create "secret" memory areas Message-ID: <20201124105947.GA5527@gaia> References: <20201124092556.12009-1-rppt@kernel.org> <20201124092556.12009-5-rppt@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20201124092556.12009-5-rppt@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-20201124_055958_454358_78DAC0B7 X-CRM114-Status: GOOD ( 20.46 ) 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: Mark Rutland , David Hildenbrand , Peter Zijlstra , Dave Hansen , linux-mm@kvack.org, linux-kselftest@vger.kernel.org, "H. Peter Anvin" , Christopher Lameter , Shuah Khan , Thomas Gleixner , 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 , Hagen Paul Pfeifer , Borislav Petkov , Alexander Viro , Andy Lutomirski , Paul Walmsley , "Kirill A. Shutemov" , Dan Williams , 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 , Rick Edgecombe , Roman Gushchin 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 Hi Mike, On Tue, Nov 24, 2020 at 11:25:51AM +0200, Mike Rapoport wrote: > +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; > + vm_fault_t ret = 0; > + unsigned long addr; > + struct page *page; > + int err; > + > + if (((loff_t)vmf->pgoff << PAGE_SHIFT) >= i_size_read(inode)) > + return vmf_error(-EINVAL); > + > + page = find_get_page(mapping, offset); > + if (!page) { > + > + page = secretmem_alloc_page(vmf->gfp_mask); > + if (!page) > + return vmf_error(-ENOMEM); > + > + err = add_to_page_cache(page, mapping, offset, vmf->gfp_mask); > + if (unlikely(err)) > + goto err_put_page; > + > + err = set_direct_map_invalid_noflush(page, 1); > + if (err) > + goto err_del_page_cache; On arm64, set_direct_map_default_noflush() returns 0 if !rodata_full but no pgtable changes happen since the linear map can be a mix of small and huge pages. The arm64 implementation doesn't break large mappings. I presume we don't want to tell the user that the designated memory is "secret" but the kernel silently ignored it. We could change the arm64 set_direct_map* to return an error, however, I think it would be pretty unexpected for the user to get a fault when trying to access it. It may be better to return a -ENOSYS or something on the actual syscall if the fault-in wouldn't be allowed later. Alternatively, we could make the linear map always use pages on arm64, irrespective of other config or cmdline options (maybe not justified unless we have clear memsecret users). Yet another idea is to get set_direct_map* to break pmd/pud mappings into pte but that's not always possible without a stop_machine() and potentially disabling the MMU. > + > + 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(err); > +} -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel