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=-11.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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 8E92AC433ED for ; Thu, 6 May 2021 17:34:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5BC546112F for ; Thu, 6 May 2021 17:34:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236430AbhEFRfS (ORCPT ); Thu, 6 May 2021 13:35:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60856 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236347AbhEFRfA (ORCPT ); Thu, 6 May 2021 13:35:00 -0400 Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0B4F4C06138E for ; Thu, 6 May 2021 10:34:02 -0700 (PDT) Received: by mail-pj1-x102b.google.com with SMTP id cl24-20020a17090af698b0290157efd14899so3884691pjb.2 for ; Thu, 06 May 2021 10:34:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=q86nNhjQAX/9YA17XxCEC8XTgKMZ0iQVDMWn6ZwwmV4=; b=WLAqQoqw48jOzw8f9p6prW1rJg+FyYJR569JKscj76Ppy52fovesCTQzh4jjLM6cFG oA2zCTxbtBPlmwTl2CsL7ant2pq37h+3CfJGFY8HReNZg9qxKHwYWxMH7Uv9yQexDxUv n2rE5uY4GJi+O+1caz3ajBWbJLxgfRdZXvX84= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=q86nNhjQAX/9YA17XxCEC8XTgKMZ0iQVDMWn6ZwwmV4=; b=lU2lPUZ7+HMDZim3gRq/hPqJMh0fKIu7jQVDqeUjWXqimh/gNYgT64PIM5jxJyxaDz uv7j8XufToSilUcZ+NnEuBrMZ2FeRRtOTFX5ohY5LORx21rqlpLREHeFcg4NbUHEUqrf cKwjHuJjycscI2EMTWgyG7ScH1zTYdA7KnRO0MTGAxGdZcJMjJETjn3walclBWsgMZPo BRKVHLucdaNyfrpRJS8Mb672bUHTLQJWM1OAOIT2nNP9sYSRXgHnapkn3dJm2gwtURNU TOT0TKkgvRWCzSCyu5EAfD86BliZhbSKoYpZg1iclj+cDkEWfX0ZuEFKGdjZyiTTJr2T /o6w== X-Gm-Message-State: AOAM5307z1gSNePDOd6+EpTWf7MqekyZHYQf/fsmGgXTugRalImzCA7E p3RkIs3xqnugY1ttNbEvfkBdTg== X-Google-Smtp-Source: ABdhPJxGZgYr7hOPC3bWDKZ6efqMzDck/orngaQkbfLWsHj/YvSX/6GL/dLtiJuMO2v8NNa6bgKivA== X-Received: by 2002:a17:90a:f283:: with SMTP id fs3mr19998936pjb.122.1620322441400; Thu, 06 May 2021 10:34:01 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id t12sm2414795pjw.51.2021.05.06.10.34.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 May 2021 10:34:00 -0700 (PDT) Date: Thu, 6 May 2021 10:33:59 -0700 From: Kees Cook To: James Bottomley Cc: Andrew Morton , Mike Rapoport , Alexander Viro , Andy Lutomirski , Arnd Bergmann , Borislav Petkov , Catalin Marinas , Christopher Lameter , Dan Williams , Dave Hansen , David Hildenbrand , Elena Reshetova , "H. Peter Anvin" , Ingo Molnar , "Kirill A. Shutemov" , Matthew Wilcox , Matthew Garrett , Mark Rutland , Michal Hocko , Mike Rapoport , Michael Kerrisk , Palmer Dabbelt , Paul Walmsley , Peter Zijlstra , "Rafael J. Wysocki" , Rick Edgecombe , Roman Gushchin , Shakeel Butt , 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 Subject: Re: [PATCH v18 0/9] mm: introduce memfd_secret system call to create "secret" memory areas Message-ID: <202105060916.ECDEC21@keescook> References: <20210303162209.8609-1-rppt@kernel.org> <20210505120806.abfd4ee657ccabf2f221a0eb@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 06, 2021 at 08:26:41AM -0700, James Bottomley wrote: > On Wed, 2021-05-05 at 12:08 -0700, Andrew Morton wrote: > > On Wed, 3 Mar 2021 18:22:00 +0200 Mike Rapoport > > wrote: > > > > > This is an implementation of "secret" mappings backed by a file > > > descriptor. tl;dr: I like this series, I think there are number of clarifications needed, though. See below. > > > > > > The file descriptor backing secret memory mappings is created using > > > a dedicated memfd_secret system call The desired protection mode > > > for the memory is configured using flags parameter of the system > > > call. The mmap() of the file descriptor created with memfd_secret() > > > will create a "secret" memory mapping. The pages in that mapping > > > will be marked as not present in the direct map and will be present > > > only in the page table of the owning mm. > > > > > > Although normally Linux userspace mappings are protected from other > > > users, such secret mappings are useful for environments where a > > > hostile tenant is trying to trick the kernel into giving them > > > access to other tenants mappings. > > > > I continue to struggle with this and I don't recall seeing much > > enthusiasm from others. Perhaps we're all missing the value point > > and some additional selling is needed. > > > > Am I correct in understanding that the overall direction here is to > > protect keys (and perhaps other things) from kernel bugs? That if > > the kernel was bug-free then there would be no need for this > > feature? If so, that's a bit sad. But realistic I guess. > > Secret memory really serves several purposes. The "increase the level > of difficulty of secret exfiltration" you describe. And, as you say, > if the kernel were bug free this wouldn't be necessary. > > But also: > > 1. Memory safety for user space code. Once the secret memory is > allocated, the user can't accidentally pass it into the kernel to be > transmitted somewhere. In my first read through, I didn't see how cross-userspace operations were blocked, but it looks like it's the various gup paths where {vma,page}_is_secretmem() is called. (Thank you for the self-test! That helped me follow along.) I think this access pattern should be more clearly spelled out in the cover later (i.e. "This will block things like process_vm_readv()"). I like the results (inaccessible outside the process), though I suspect this will absolutely melt gdb or other ptracers that try to see into the memory. Don't get me wrong, I'm a big fan of such concepts[0], but I see nothing in the cover letter about it (e.g. the effects on "ptrace" or "gdb" are not mentioned.) There is also a risk here of this becoming a forensics nightmare: userspace malware will just download their entire executable region into a memfd_secret region. Can we, perhaps, disallow mmap/mprotect with PROT_EXEC when vma_is_secretmem()? The OpenSSL example, for example, certainly doesn't need PROT_EXEC. What's happening with O_CLOEXEC in this code? I don't see that mentioned in the cover letter either. Why is it disallowed? That seems a strange limitation for something trying to avoid leaking secrets into other processes. And just so I'm sure I understand: if a vma_is_secretmem() check is missed in future mm code evolutions, it seems there is nothing to block the kernel from accessing the contents directly through copy_from_user() via the userspace virtual address, yes? > 2. It also serves as a basis for context protection of virtual > machines, but other groups are working on this aspect, and it is > broadly similar to the secret exfiltration from the kernel problem. > > > > > Is this intended to protect keys/etc after the attacker has gained > > the ability to run arbitrary kernel-mode code? If so, that seems > > optimistic, doesn't it? > > Not exactly: there are many types of kernel attack, but mostly the > attacker either manages to effect a privilege escalation to root or > gets the ability to run a ROP gadget. The object of this code is to be > completely secure against root trying to extract the secret (some what > similar to the lockdown idea), thus defeating privilege escalation and > to provide "sufficient" protection against ROP gadgets. > > The ROP gadget thing needs more explanation: the usual defeatist > approach is to say that once the attacker gains the stack, they can do > anything because they can find enough ROP gadgets to be turing > complete. However, in the real world, given the kernel stack size > limit and address space layout randomization making finding gadgets > really hard, usually the attacker gets one or at most two gadgets to > string together. Not having any in-kernel primitive for accessing > secret memory means the one gadget ROP attack can't work. Since the > only way to access secret memory is to reconstruct the missing mapping > entry, the attacker has to recover the physical page and insert a PTE > pointing to it in the kernel and then retrieve the contents. That > takes at least three gadgets which is a level of difficulty beyond most > standard attacks. As for protecting against exploited kernel flaws I also see benefits here. While the kernel is already blocked from directly reading contents from userspace virtual addresses (i.e. SMAP), this feature does help by blocking the kernel from directly reading contents via the direct map alias. (i.e. this feature is a specialized version of XPFO[1], which tried to do this for ALL user memory.) So in that regard, yes, this has value in the sense that to perform exfiltration, an attacker would need a significant level of control over kernel execution or over page table contents. Sufficient control over PTE allocation and positioning is possible without kernel execution control[3], and "only" having an arbitrary write primitive can lead to direct PTE control. Because of this, it would be nice to have page tables strongly protected[2] in the kernel. They remain a viable "data only" attack given a sufficiently "capable" write flaw. I would argue that page table entries are a more important asset to protect than userspace secrets, but given the difficulties with XPFO and the not-yet-available PKS I can understand starting here. It does, absolutely, narrow the ways exploits must be written to exfiltrate secret contents. (We are starting to now constrict[4] many attack methods into attacking the page table itself, which is good in the sense that protecting page tables will be a big win, and bad in the sense that focusing attack research on page tables means we're going to see some very powerful attacks.) > > I think that a very complete description of the threats which this > > feature addresses would be helpful. > > It's designed to protect against three different threats: > > 1. Detection of user secret memory mismanagement I would say "cross-process secret userspace memory exposures" (via a number of common interfaces by blocking it at the GUP level). > 2. significant protection against privilege escalation I don't see how this series protects against privilege escalation. (It protects against exfiltration.) Maybe you mean include this in the first bullet point (i.e. "cross-process secret userspace memory exposures, even in the face of privileged processes")? > 3. enhanced protection (in conjunction with all the other in-kernel > attack prevention systems) against ROP attacks. Same here, I don't see it preventing ROP, but I see it making "simple" ROP insufficient to perform exfiltration. -Kees [0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/security/yama/yama_lsm.c?h=v5.12#n410 [1] https://lore.kernel.org/linux-mm/cover.1554248001.git.khalid.aziz@oracle.com/ [2] https://lore.kernel.org/lkml/20210505003032.489164-1-rick.p.edgecombe@intel.com/ [3] https://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html [4] https://git.kernel.org/linus/cf68fffb66d60d96209446bfc4a15291dc5a5d41 -- Kees Cook 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=-9.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 C6079C433ED for ; Thu, 6 May 2021 17:34:31 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 05A386112F for ; Thu, 6 May 2021 17:34:30 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 05A386112F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.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=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:Cc: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=GMSeqA8eeWdYiabtM19sgLjWwGwabkbPmxiHjVrFvBE=; b=ImpMenlTvdgiwXB9RwHh4fsDQ usxiShc51mhjguoCqPGEv/Zwsx0xGn4UwZ0Fyr9LHuF0DNweyuOYwg8nPWoKVdeeGClgj9hcSfQTP UZ9Nxz+ieEC8uCQvWLuWpZvkSCpKPfw4t6C+IGFc2OVU5+IkGIBeBOirfqjKaqpuw3PskivmbpEL2 rDQy0B0g8gIGH5chLjjDH/WmxHmH008exqcs1hy4DOdEgyzBYRBwZOtIW3ZsM1mJTDjJQRx3g7ttM Ro0kOI+MWlyCNkJmjyTjjL8LCuElqSKDAvFVmvaLvc/du/uqeicBxnnNuIHmGpkXQxLdp008OTZ5f 9Eam1ncIw==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1leht6-004wPr-JT; Thu, 06 May 2021 17:34:12 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1leht4-004wOv-7A for linux-riscv@desiato.infradead.org; Thu, 06 May 2021 17:34:10 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=q86nNhjQAX/9YA17XxCEC8XTgKMZ0iQVDMWn6ZwwmV4=; b=3dedms7kTsn+NqbNO2EmlIiIWo Jk/K8J7nVArmQNfVEB9erkm8J47Nl4WgXropL/4Tx3TFK+bZdfGugV83Pxlx5bTXqygJcdnI3JieR 4zgSBvCYhteNnX3aK6d2hvvyZ58BY8aJ5FJnELmgeXNlnACPlythu3tkVutQaxJ99lsvD3mOuuqxh s37+qOeuuJoQTGK17Stk6OxdxQt4SGGm7yyDowRKb7EN2dc+WyZCGS9ags9+4Uqp/eZecLtDADp7I flKyH9mZ292O2N7eyVRt9us66gZLgmDwIXcyM9Qejbm70VEitkfwa9r9w3tiQfOznVi07RfNA/6YY 6xvHgLWw==; Received: from mail-pl1-x635.google.com ([2607:f8b0:4864:20::635]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lehsx-006FwN-Mz for linux-riscv@lists.infradead.org; Thu, 06 May 2021 17:34:06 +0000 Received: by mail-pl1-x635.google.com with SMTP id b21so3807102plz.0 for ; Thu, 06 May 2021 10:34:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=q86nNhjQAX/9YA17XxCEC8XTgKMZ0iQVDMWn6ZwwmV4=; b=WLAqQoqw48jOzw8f9p6prW1rJg+FyYJR569JKscj76Ppy52fovesCTQzh4jjLM6cFG oA2zCTxbtBPlmwTl2CsL7ant2pq37h+3CfJGFY8HReNZg9qxKHwYWxMH7Uv9yQexDxUv n2rE5uY4GJi+O+1caz3ajBWbJLxgfRdZXvX84= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=q86nNhjQAX/9YA17XxCEC8XTgKMZ0iQVDMWn6ZwwmV4=; b=DT4O1VyaVvym14kmdwKqFf9bV9SN/wJFb73agoFSungnh1beS7HFeisJXMNbzbMYe9 05gE9vx5GjI1EzpVDMeN0lAPqWRb5cfE4NnmrqTC44gxfLIQ+4q9JVyU7i7UWxbsouQd Lf/En8NgVAxxf3iPaRWP1LeXd53xYufWHtGgl6/u08L7TBYGNp+q1lSKkmhjhA2FHAFS fnvH+L181Dhl+pdHPzfRlMvsvjN3Soj6etDhkVxzODHaPYjUOTJZj7b5ido6JdG25oFO nbd3JiV4U70WY83tv2oHQyYfqi4LI9mOTPB41reMe2P6tNkAYL53lMxenxa8O+ZTJV+B cKPA== X-Gm-Message-State: AOAM5305aOJ9ILnGlCgAPjXxyKHUTBJ/F+uEeUuBDZ7CmvgY2sBnDakh KD82e/gLoTifyeQATuSWHjnm6g== X-Google-Smtp-Source: ABdhPJxGZgYr7hOPC3bWDKZ6efqMzDck/orngaQkbfLWsHj/YvSX/6GL/dLtiJuMO2v8NNa6bgKivA== X-Received: by 2002:a17:90a:f283:: with SMTP id fs3mr19998936pjb.122.1620322441400; Thu, 06 May 2021 10:34:01 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id t12sm2414795pjw.51.2021.05.06.10.34.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 May 2021 10:34:00 -0700 (PDT) Date: Thu, 6 May 2021 10:33:59 -0700 From: Kees Cook To: James Bottomley Cc: Andrew Morton , Mike Rapoport , Alexander Viro , Andy Lutomirski , Arnd Bergmann , Borislav Petkov , Catalin Marinas , Christopher Lameter , Dan Williams , Dave Hansen , David Hildenbrand , Elena Reshetova , "H. Peter Anvin" , Ingo Molnar , "Kirill A. Shutemov" , Matthew Wilcox , Matthew Garrett , Mark Rutland , Michal Hocko , Mike Rapoport , Michael Kerrisk , Palmer Dabbelt , Paul Walmsley , Peter Zijlstra , "Rafael J. Wysocki" , Rick Edgecombe , Roman Gushchin , Shakeel Butt , 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 Subject: Re: [PATCH v18 0/9] mm: introduce memfd_secret system call to create "secret" memory areas Message-ID: <202105060916.ECDEC21@keescook> References: <20210303162209.8609-1-rppt@kernel.org> <20210505120806.abfd4ee657ccabf2f221a0eb@linux-foundation.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210506_103403_805066_8AE87E4F X-CRM114-Status: GOOD ( 55.49 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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, May 06, 2021 at 08:26:41AM -0700, James Bottomley wrote: > On Wed, 2021-05-05 at 12:08 -0700, Andrew Morton wrote: > > On Wed, 3 Mar 2021 18:22:00 +0200 Mike Rapoport > > wrote: > > > > > This is an implementation of "secret" mappings backed by a file > > > descriptor. tl;dr: I like this series, I think there are number of clarifications needed, though. See below. > > > > > > The file descriptor backing secret memory mappings is created using > > > a dedicated memfd_secret system call The desired protection mode > > > for the memory is configured using flags parameter of the system > > > call. The mmap() of the file descriptor created with memfd_secret() > > > will create a "secret" memory mapping. The pages in that mapping > > > will be marked as not present in the direct map and will be present > > > only in the page table of the owning mm. > > > > > > Although normally Linux userspace mappings are protected from other > > > users, such secret mappings are useful for environments where a > > > hostile tenant is trying to trick the kernel into giving them > > > access to other tenants mappings. > > > > I continue to struggle with this and I don't recall seeing much > > enthusiasm from others. Perhaps we're all missing the value point > > and some additional selling is needed. > > > > Am I correct in understanding that the overall direction here is to > > protect keys (and perhaps other things) from kernel bugs? That if > > the kernel was bug-free then there would be no need for this > > feature? If so, that's a bit sad. But realistic I guess. > > Secret memory really serves several purposes. The "increase the level > of difficulty of secret exfiltration" you describe. And, as you say, > if the kernel were bug free this wouldn't be necessary. > > But also: > > 1. Memory safety for user space code. Once the secret memory is > allocated, the user can't accidentally pass it into the kernel to be > transmitted somewhere. In my first read through, I didn't see how cross-userspace operations were blocked, but it looks like it's the various gup paths where {vma,page}_is_secretmem() is called. (Thank you for the self-test! That helped me follow along.) I think this access pattern should be more clearly spelled out in the cover later (i.e. "This will block things like process_vm_readv()"). I like the results (inaccessible outside the process), though I suspect this will absolutely melt gdb or other ptracers that try to see into the memory. Don't get me wrong, I'm a big fan of such concepts[0], but I see nothing in the cover letter about it (e.g. the effects on "ptrace" or "gdb" are not mentioned.) There is also a risk here of this becoming a forensics nightmare: userspace malware will just download their entire executable region into a memfd_secret region. Can we, perhaps, disallow mmap/mprotect with PROT_EXEC when vma_is_secretmem()? The OpenSSL example, for example, certainly doesn't need PROT_EXEC. What's happening with O_CLOEXEC in this code? I don't see that mentioned in the cover letter either. Why is it disallowed? That seems a strange limitation for something trying to avoid leaking secrets into other processes. And just so I'm sure I understand: if a vma_is_secretmem() check is missed in future mm code evolutions, it seems there is nothing to block the kernel from accessing the contents directly through copy_from_user() via the userspace virtual address, yes? > 2. It also serves as a basis for context protection of virtual > machines, but other groups are working on this aspect, and it is > broadly similar to the secret exfiltration from the kernel problem. > > > > > Is this intended to protect keys/etc after the attacker has gained > > the ability to run arbitrary kernel-mode code? If so, that seems > > optimistic, doesn't it? > > Not exactly: there are many types of kernel attack, but mostly the > attacker either manages to effect a privilege escalation to root or > gets the ability to run a ROP gadget. The object of this code is to be > completely secure against root trying to extract the secret (some what > similar to the lockdown idea), thus defeating privilege escalation and > to provide "sufficient" protection against ROP gadgets. > > The ROP gadget thing needs more explanation: the usual defeatist > approach is to say that once the attacker gains the stack, they can do > anything because they can find enough ROP gadgets to be turing > complete. However, in the real world, given the kernel stack size > limit and address space layout randomization making finding gadgets > really hard, usually the attacker gets one or at most two gadgets to > string together. Not having any in-kernel primitive for accessing > secret memory means the one gadget ROP attack can't work. Since the > only way to access secret memory is to reconstruct the missing mapping > entry, the attacker has to recover the physical page and insert a PTE > pointing to it in the kernel and then retrieve the contents. That > takes at least three gadgets which is a level of difficulty beyond most > standard attacks. As for protecting against exploited kernel flaws I also see benefits here. While the kernel is already blocked from directly reading contents from userspace virtual addresses (i.e. SMAP), this feature does help by blocking the kernel from directly reading contents via the direct map alias. (i.e. this feature is a specialized version of XPFO[1], which tried to do this for ALL user memory.) So in that regard, yes, this has value in the sense that to perform exfiltration, an attacker would need a significant level of control over kernel execution or over page table contents. Sufficient control over PTE allocation and positioning is possible without kernel execution control[3], and "only" having an arbitrary write primitive can lead to direct PTE control. Because of this, it would be nice to have page tables strongly protected[2] in the kernel. They remain a viable "data only" attack given a sufficiently "capable" write flaw. I would argue that page table entries are a more important asset to protect than userspace secrets, but given the difficulties with XPFO and the not-yet-available PKS I can understand starting here. It does, absolutely, narrow the ways exploits must be written to exfiltrate secret contents. (We are starting to now constrict[4] many attack methods into attacking the page table itself, which is good in the sense that protecting page tables will be a big win, and bad in the sense that focusing attack research on page tables means we're going to see some very powerful attacks.) > > I think that a very complete description of the threats which this > > feature addresses would be helpful. > > It's designed to protect against three different threats: > > 1. Detection of user secret memory mismanagement I would say "cross-process secret userspace memory exposures" (via a number of common interfaces by blocking it at the GUP level). > 2. significant protection against privilege escalation I don't see how this series protects against privilege escalation. (It protects against exfiltration.) Maybe you mean include this in the first bullet point (i.e. "cross-process secret userspace memory exposures, even in the face of privileged processes")? > 3. enhanced protection (in conjunction with all the other in-kernel > attack prevention systems) against ROP attacks. Same here, I don't see it preventing ROP, but I see it making "simple" ROP insufficient to perform exfiltration. -Kees [0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/security/yama/yama_lsm.c?h=v5.12#n410 [1] https://lore.kernel.org/linux-mm/cover.1554248001.git.khalid.aziz@oracle.com/ [2] https://lore.kernel.org/lkml/20210505003032.489164-1-rick.p.edgecombe@intel.com/ [3] https://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html [4] https://git.kernel.org/linus/cf68fffb66d60d96209446bfc4a15291dc5a5d41 -- Kees Cook _______________________________________________ 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=-8.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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 66472C43600 for ; Thu, 6 May 2021 17:34:05 +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 03EAF61289 for ; Thu, 6 May 2021 17:34:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 03EAF61289 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.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 B0407100EAB58; Thu, 6 May 2021 10:34:04 -0700 (PDT) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2607:f8b0:4864:20::631; helo=mail-pl1-x631.google.com; envelope-from=keescook@chromium.org; receiver= Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 6BAE1100EAB54 for ; Thu, 6 May 2021 10:34:02 -0700 (PDT) Received: by mail-pl1-x631.google.com with SMTP id h7so3788203plt.1 for ; Thu, 06 May 2021 10:34:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=q86nNhjQAX/9YA17XxCEC8XTgKMZ0iQVDMWn6ZwwmV4=; b=WLAqQoqw48jOzw8f9p6prW1rJg+FyYJR569JKscj76Ppy52fovesCTQzh4jjLM6cFG oA2zCTxbtBPlmwTl2CsL7ant2pq37h+3CfJGFY8HReNZg9qxKHwYWxMH7Uv9yQexDxUv n2rE5uY4GJi+O+1caz3ajBWbJLxgfRdZXvX84= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=q86nNhjQAX/9YA17XxCEC8XTgKMZ0iQVDMWn6ZwwmV4=; b=KDVoh4gR/NicfVM5zinODo0/H9zc4woxA/s6Im8zVcQzYbUNpg5q7igUH7unKDixk1 +z6HROKNgr+CXBWbpqrd9Zm/N5wPmmVbwVpU2WYO6obIXsDG5HZM+4X54wxriCPb6N8d kHvqKkarPUXtrXueiIfnJDdBqYeexEZr0Udqj6Ho3stjMy9/le+kiZHY7rGwdpjX3VGA 2qW3TMm7cZbHRYMD2Sr9RMgEXX5CJb6VGzLLo7crdi+IqY+Kpcof2qXyh4+WNRo9EgB8 BEhEIJJrRnb41SRzzxk4ccE6dvI5QuiaiqXIWleoxIuxzc2HglYZsH0ydkH2jZVtZTUf Emnw== X-Gm-Message-State: AOAM531/UxkfGm5uxttssVIG2W0l8PZkDYX1ZNcmsixSRZJb7KNGx6AS ucDKi2MgBhl3oAzceJhunRT+qg== X-Google-Smtp-Source: ABdhPJxGZgYr7hOPC3bWDKZ6efqMzDck/orngaQkbfLWsHj/YvSX/6GL/dLtiJuMO2v8NNa6bgKivA== X-Received: by 2002:a17:90a:f283:: with SMTP id fs3mr19998936pjb.122.1620322441400; Thu, 06 May 2021 10:34:01 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id t12sm2414795pjw.51.2021.05.06.10.34.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 May 2021 10:34:00 -0700 (PDT) Date: Thu, 6 May 2021 10:33:59 -0700 From: Kees Cook To: James Bottomley Subject: Re: [PATCH v18 0/9] mm: introduce memfd_secret system call to create "secret" memory areas Message-ID: <202105060916.ECDEC21@keescook> References: <20210303162209.8609-1-rppt@kernel.org> <20210505120806.abfd4ee657ccabf2f221a0eb@linux-foundation.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Message-ID-Hash: IE3BWMO7FDSV2LTYAIEDACBX3RTPDFJA X-Message-ID-Hash: IE3BWMO7FDSV2LTYAIEDACBX3RTPDFJA X-MailFrom: keescook@chromium.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 , Mike Rapoport , Alexander Viro , Andy Lutomirski , Arnd Bergmann , Borislav Petkov , Catalin Marinas , Christopher Lameter , Dave Hansen , David Hildenbrand , Elena Reshetova , "H. Peter Anvin" , Ingo Molnar , "Kirill A. Shutemov" , Matthew Wilcox , Matthew Garrett , Mark Rutland , Michal Hocko , Mike Rapoport , Michael Kerrisk , Palmer Dabbelt , Paul Walmsley , Peter Zijlstra , "Rafael J. Wysocki" , Rick Edgecombe , Roman Gushchin , Shak eel Butt , 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 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, May 06, 2021 at 08:26:41AM -0700, James Bottomley wrote: > On Wed, 2021-05-05 at 12:08 -0700, Andrew Morton wrote: > > On Wed, 3 Mar 2021 18:22:00 +0200 Mike Rapoport > > wrote: > > > > > This is an implementation of "secret" mappings backed by a file > > > descriptor. tl;dr: I like this series, I think there are number of clarifications needed, though. See below. > > > > > > The file descriptor backing secret memory mappings is created using > > > a dedicated memfd_secret system call The desired protection mode > > > for the memory is configured using flags parameter of the system > > > call. The mmap() of the file descriptor created with memfd_secret() > > > will create a "secret" memory mapping. The pages in that mapping > > > will be marked as not present in the direct map and will be present > > > only in the page table of the owning mm. > > > > > > Although normally Linux userspace mappings are protected from other > > > users, such secret mappings are useful for environments where a > > > hostile tenant is trying to trick the kernel into giving them > > > access to other tenants mappings. > > > > I continue to struggle with this and I don't recall seeing much > > enthusiasm from others. Perhaps we're all missing the value point > > and some additional selling is needed. > > > > Am I correct in understanding that the overall direction here is to > > protect keys (and perhaps other things) from kernel bugs? That if > > the kernel was bug-free then there would be no need for this > > feature? If so, that's a bit sad. But realistic I guess. > > Secret memory really serves several purposes. The "increase the level > of difficulty of secret exfiltration" you describe. And, as you say, > if the kernel were bug free this wouldn't be necessary. > > But also: > > 1. Memory safety for user space code. Once the secret memory is > allocated, the user can't accidentally pass it into the kernel to be > transmitted somewhere. In my first read through, I didn't see how cross-userspace operations were blocked, but it looks like it's the various gup paths where {vma,page}_is_secretmem() is called. (Thank you for the self-test! That helped me follow along.) I think this access pattern should be more clearly spelled out in the cover later (i.e. "This will block things like process_vm_readv()"). I like the results (inaccessible outside the process), though I suspect this will absolutely melt gdb or other ptracers that try to see into the memory. Don't get me wrong, I'm a big fan of such concepts[0], but I see nothing in the cover letter about it (e.g. the effects on "ptrace" or "gdb" are not mentioned.) There is also a risk here of this becoming a forensics nightmare: userspace malware will just download their entire executable region into a memfd_secret region. Can we, perhaps, disallow mmap/mprotect with PROT_EXEC when vma_is_secretmem()? The OpenSSL example, for example, certainly doesn't need PROT_EXEC. What's happening with O_CLOEXEC in this code? I don't see that mentioned in the cover letter either. Why is it disallowed? That seems a strange limitation for something trying to avoid leaking secrets into other processes. And just so I'm sure I understand: if a vma_is_secretmem() check is missed in future mm code evolutions, it seems there is nothing to block the kernel from accessing the contents directly through copy_from_user() via the userspace virtual address, yes? > 2. It also serves as a basis for context protection of virtual > machines, but other groups are working on this aspect, and it is > broadly similar to the secret exfiltration from the kernel problem. > > > > > Is this intended to protect keys/etc after the attacker has gained > > the ability to run arbitrary kernel-mode code? If so, that seems > > optimistic, doesn't it? > > Not exactly: there are many types of kernel attack, but mostly the > attacker either manages to effect a privilege escalation to root or > gets the ability to run a ROP gadget. The object of this code is to be > completely secure against root trying to extract the secret (some what > similar to the lockdown idea), thus defeating privilege escalation and > to provide "sufficient" protection against ROP gadgets. > > The ROP gadget thing needs more explanation: the usual defeatist > approach is to say that once the attacker gains the stack, they can do > anything because they can find enough ROP gadgets to be turing > complete. However, in the real world, given the kernel stack size > limit and address space layout randomization making finding gadgets > really hard, usually the attacker gets one or at most two gadgets to > string together. Not having any in-kernel primitive for accessing > secret memory means the one gadget ROP attack can't work. Since the > only way to access secret memory is to reconstruct the missing mapping > entry, the attacker has to recover the physical page and insert a PTE > pointing to it in the kernel and then retrieve the contents. That > takes at least three gadgets which is a level of difficulty beyond most > standard attacks. As for protecting against exploited kernel flaws I also see benefits here. While the kernel is already blocked from directly reading contents from userspace virtual addresses (i.e. SMAP), this feature does help by blocking the kernel from directly reading contents via the direct map alias. (i.e. this feature is a specialized version of XPFO[1], which tried to do this for ALL user memory.) So in that regard, yes, this has value in the sense that to perform exfiltration, an attacker would need a significant level of control over kernel execution or over page table contents. Sufficient control over PTE allocation and positioning is possible without kernel execution control[3], and "only" having an arbitrary write primitive can lead to direct PTE control. Because of this, it would be nice to have page tables strongly protected[2] in the kernel. They remain a viable "data only" attack given a sufficiently "capable" write flaw. I would argue that page table entries are a more important asset to protect than userspace secrets, but given the difficulties with XPFO and the not-yet-available PKS I can understand starting here. It does, absolutely, narrow the ways exploits must be written to exfiltrate secret contents. (We are starting to now constrict[4] many attack methods into attacking the page table itself, which is good in the sense that protecting page tables will be a big win, and bad in the sense that focusing attack research on page tables means we're going to see some very powerful attacks.) > > I think that a very complete description of the threats which this > > feature addresses would be helpful. > > It's designed to protect against three different threats: > > 1. Detection of user secret memory mismanagement I would say "cross-process secret userspace memory exposures" (via a number of common interfaces by blocking it at the GUP level). > 2. significant protection against privilege escalation I don't see how this series protects against privilege escalation. (It protects against exfiltration.) Maybe you mean include this in the first bullet point (i.e. "cross-process secret userspace memory exposures, even in the face of privileged processes")? > 3. enhanced protection (in conjunction with all the other in-kernel > attack prevention systems) against ROP attacks. Same here, I don't see it preventing ROP, but I see it making "simple" ROP insufficient to perform exfiltration. -Kees [0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/security/yama/yama_lsm.c?h=v5.12#n410 [1] https://lore.kernel.org/linux-mm/cover.1554248001.git.khalid.aziz@oracle.com/ [2] https://lore.kernel.org/lkml/20210505003032.489164-1-rick.p.edgecombe@intel.com/ [3] https://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html [4] https://git.kernel.org/linus/cf68fffb66d60d96209446bfc4a15291dc5a5d41 -- Kees Cook _______________________________________________ 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=-9.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 83F22C433ED for ; Thu, 6 May 2021 17:36:58 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 B66CA61041 for ; Thu, 6 May 2021 17:36:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B66CA61041 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.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=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:Cc: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=BO46jPqG3mUkUQh048rycXO6koEzDOmIf62MK/BvCeI=; b=c9vk3/K44vtecKGntZQBqjAau 9X8SgTs7sLxMzSBbVtp4RXu1+92C69d4prKTdIUGdgGxv9GCLyO09ol4uIMSMy4xGvvEQSSoFqlNI CtcDGqhebATO5GyqLTu70FgKAGgouIoetwVWfgQyVq3ns/mRJJFMb188gdnQzkAxFiJdUbKAqynmF 1tZYgJQyb4NymlPJwZliy28mTVGlRpYnxe3Z2aYnIloIkCJla59lsxHqFxU6N12SA1dY/JRNff4D3 YN33lNx01CQz6Y9nHu81gM5xf3gDaCn52LmyKlidr5uJiziT5Txei7T4Agc3HoGxkomiBrX9K6wg/ sHCvrgKkw==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1leht8-004wQ0-Ee; Thu, 06 May 2021 17:34:14 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1leht4-004wOt-7A for linux-arm-kernel@desiato.infradead.org; Thu, 06 May 2021 17:34:10 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=q86nNhjQAX/9YA17XxCEC8XTgKMZ0iQVDMWn6ZwwmV4=; b=3dedms7kTsn+NqbNO2EmlIiIWo Jk/K8J7nVArmQNfVEB9erkm8J47Nl4WgXropL/4Tx3TFK+bZdfGugV83Pxlx5bTXqygJcdnI3JieR 4zgSBvCYhteNnX3aK6d2hvvyZ58BY8aJ5FJnELmgeXNlnACPlythu3tkVutQaxJ99lsvD3mOuuqxh s37+qOeuuJoQTGK17Stk6OxdxQt4SGGm7yyDowRKb7EN2dc+WyZCGS9ags9+4Uqp/eZecLtDADp7I flKyH9mZ292O2N7eyVRt9us66gZLgmDwIXcyM9Qejbm70VEitkfwa9r9w3tiQfOznVi07RfNA/6YY 6xvHgLWw==; Received: from mail-pl1-x634.google.com ([2607:f8b0:4864:20::634]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lehsx-006FwM-OD for linux-arm-kernel@lists.infradead.org; Thu, 06 May 2021 17:34:06 +0000 Received: by mail-pl1-x634.google.com with SMTP id h7so3788204plt.1 for ; Thu, 06 May 2021 10:34:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=q86nNhjQAX/9YA17XxCEC8XTgKMZ0iQVDMWn6ZwwmV4=; b=WLAqQoqw48jOzw8f9p6prW1rJg+FyYJR569JKscj76Ppy52fovesCTQzh4jjLM6cFG oA2zCTxbtBPlmwTl2CsL7ant2pq37h+3CfJGFY8HReNZg9qxKHwYWxMH7Uv9yQexDxUv n2rE5uY4GJi+O+1caz3ajBWbJLxgfRdZXvX84= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=q86nNhjQAX/9YA17XxCEC8XTgKMZ0iQVDMWn6ZwwmV4=; b=jQbKFXcnLKRvIRMl21jHIgtsIGE2nl4Sw/KGtF7j4tM2l/FJaDTNFikeNQSO4lAX+1 avw4OOzs+EWQmTjXyLNgy9IlCZJaUSvZ4cnAi+nf9J/CKYOj0UXtBtkE6VQnURrxft0v 0UvxXrXoajZ9CbJuBaeCHyHaPw8tkrPiLqifptKA1wpUfwKyZK2FCD5gUUMrEViDUN+A aIrYnztwvCOJzgXYUmlgk71rIBEpQOarUTZKdQQXPDjzIsA7aM7D1LGmaHvoQxkQFTKl Sb2qFuDR8XJjRfMqmCphAuNKCxvu/Xd/ecm4938cmtcSd0VfJnt9yYLY8Vl7n9d3el3Q 646w== X-Gm-Message-State: AOAM531WO9SfsyEBvnMYDCMgBotlxp4W++udjJHiVr4N7maCNVfRDUKP qh/kAA3m5oy9rRsBDf5GNSp8ZQ== X-Google-Smtp-Source: ABdhPJxGZgYr7hOPC3bWDKZ6efqMzDck/orngaQkbfLWsHj/YvSX/6GL/dLtiJuMO2v8NNa6bgKivA== X-Received: by 2002:a17:90a:f283:: with SMTP id fs3mr19998936pjb.122.1620322441400; Thu, 06 May 2021 10:34:01 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id t12sm2414795pjw.51.2021.05.06.10.34.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 May 2021 10:34:00 -0700 (PDT) Date: Thu, 6 May 2021 10:33:59 -0700 From: Kees Cook To: James Bottomley Cc: Andrew Morton , Mike Rapoport , Alexander Viro , Andy Lutomirski , Arnd Bergmann , Borislav Petkov , Catalin Marinas , Christopher Lameter , Dan Williams , Dave Hansen , David Hildenbrand , Elena Reshetova , "H. Peter Anvin" , Ingo Molnar , "Kirill A. Shutemov" , Matthew Wilcox , Matthew Garrett , Mark Rutland , Michal Hocko , Mike Rapoport , Michael Kerrisk , Palmer Dabbelt , Paul Walmsley , Peter Zijlstra , "Rafael J. Wysocki" , Rick Edgecombe , Roman Gushchin , Shakeel Butt , 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 Subject: Re: [PATCH v18 0/9] mm: introduce memfd_secret system call to create "secret" memory areas Message-ID: <202105060916.ECDEC21@keescook> References: <20210303162209.8609-1-rppt@kernel.org> <20210505120806.abfd4ee657ccabf2f221a0eb@linux-foundation.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210506_103403_806485_EFB1D343 X-CRM114-Status: GOOD ( 56.97 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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, May 06, 2021 at 08:26:41AM -0700, James Bottomley wrote: > On Wed, 2021-05-05 at 12:08 -0700, Andrew Morton wrote: > > On Wed, 3 Mar 2021 18:22:00 +0200 Mike Rapoport > > wrote: > > > > > This is an implementation of "secret" mappings backed by a file > > > descriptor. tl;dr: I like this series, I think there are number of clarifications needed, though. See below. > > > > > > The file descriptor backing secret memory mappings is created using > > > a dedicated memfd_secret system call The desired protection mode > > > for the memory is configured using flags parameter of the system > > > call. The mmap() of the file descriptor created with memfd_secret() > > > will create a "secret" memory mapping. The pages in that mapping > > > will be marked as not present in the direct map and will be present > > > only in the page table of the owning mm. > > > > > > Although normally Linux userspace mappings are protected from other > > > users, such secret mappings are useful for environments where a > > > hostile tenant is trying to trick the kernel into giving them > > > access to other tenants mappings. > > > > I continue to struggle with this and I don't recall seeing much > > enthusiasm from others. Perhaps we're all missing the value point > > and some additional selling is needed. > > > > Am I correct in understanding that the overall direction here is to > > protect keys (and perhaps other things) from kernel bugs? That if > > the kernel was bug-free then there would be no need for this > > feature? If so, that's a bit sad. But realistic I guess. > > Secret memory really serves several purposes. The "increase the level > of difficulty of secret exfiltration" you describe. And, as you say, > if the kernel were bug free this wouldn't be necessary. > > But also: > > 1. Memory safety for user space code. Once the secret memory is > allocated, the user can't accidentally pass it into the kernel to be > transmitted somewhere. In my first read through, I didn't see how cross-userspace operations were blocked, but it looks like it's the various gup paths where {vma,page}_is_secretmem() is called. (Thank you for the self-test! That helped me follow along.) I think this access pattern should be more clearly spelled out in the cover later (i.e. "This will block things like process_vm_readv()"). I like the results (inaccessible outside the process), though I suspect this will absolutely melt gdb or other ptracers that try to see into the memory. Don't get me wrong, I'm a big fan of such concepts[0], but I see nothing in the cover letter about it (e.g. the effects on "ptrace" or "gdb" are not mentioned.) There is also a risk here of this becoming a forensics nightmare: userspace malware will just download their entire executable region into a memfd_secret region. Can we, perhaps, disallow mmap/mprotect with PROT_EXEC when vma_is_secretmem()? The OpenSSL example, for example, certainly doesn't need PROT_EXEC. What's happening with O_CLOEXEC in this code? I don't see that mentioned in the cover letter either. Why is it disallowed? That seems a strange limitation for something trying to avoid leaking secrets into other processes. And just so I'm sure I understand: if a vma_is_secretmem() check is missed in future mm code evolutions, it seems there is nothing to block the kernel from accessing the contents directly through copy_from_user() via the userspace virtual address, yes? > 2. It also serves as a basis for context protection of virtual > machines, but other groups are working on this aspect, and it is > broadly similar to the secret exfiltration from the kernel problem. > > > > > Is this intended to protect keys/etc after the attacker has gained > > the ability to run arbitrary kernel-mode code? If so, that seems > > optimistic, doesn't it? > > Not exactly: there are many types of kernel attack, but mostly the > attacker either manages to effect a privilege escalation to root or > gets the ability to run a ROP gadget. The object of this code is to be > completely secure against root trying to extract the secret (some what > similar to the lockdown idea), thus defeating privilege escalation and > to provide "sufficient" protection against ROP gadgets. > > The ROP gadget thing needs more explanation: the usual defeatist > approach is to say that once the attacker gains the stack, they can do > anything because they can find enough ROP gadgets to be turing > complete. However, in the real world, given the kernel stack size > limit and address space layout randomization making finding gadgets > really hard, usually the attacker gets one or at most two gadgets to > string together. Not having any in-kernel primitive for accessing > secret memory means the one gadget ROP attack can't work. Since the > only way to access secret memory is to reconstruct the missing mapping > entry, the attacker has to recover the physical page and insert a PTE > pointing to it in the kernel and then retrieve the contents. That > takes at least three gadgets which is a level of difficulty beyond most > standard attacks. As for protecting against exploited kernel flaws I also see benefits here. While the kernel is already blocked from directly reading contents from userspace virtual addresses (i.e. SMAP), this feature does help by blocking the kernel from directly reading contents via the direct map alias. (i.e. this feature is a specialized version of XPFO[1], which tried to do this for ALL user memory.) So in that regard, yes, this has value in the sense that to perform exfiltration, an attacker would need a significant level of control over kernel execution or over page table contents. Sufficient control over PTE allocation and positioning is possible without kernel execution control[3], and "only" having an arbitrary write primitive can lead to direct PTE control. Because of this, it would be nice to have page tables strongly protected[2] in the kernel. They remain a viable "data only" attack given a sufficiently "capable" write flaw. I would argue that page table entries are a more important asset to protect than userspace secrets, but given the difficulties with XPFO and the not-yet-available PKS I can understand starting here. It does, absolutely, narrow the ways exploits must be written to exfiltrate secret contents. (We are starting to now constrict[4] many attack methods into attacking the page table itself, which is good in the sense that protecting page tables will be a big win, and bad in the sense that focusing attack research on page tables means we're going to see some very powerful attacks.) > > I think that a very complete description of the threats which this > > feature addresses would be helpful. > > It's designed to protect against three different threats: > > 1. Detection of user secret memory mismanagement I would say "cross-process secret userspace memory exposures" (via a number of common interfaces by blocking it at the GUP level). > 2. significant protection against privilege escalation I don't see how this series protects against privilege escalation. (It protects against exfiltration.) Maybe you mean include this in the first bullet point (i.e. "cross-process secret userspace memory exposures, even in the face of privileged processes")? > 3. enhanced protection (in conjunction with all the other in-kernel > attack prevention systems) against ROP attacks. Same here, I don't see it preventing ROP, but I see it making "simple" ROP insufficient to perform exfiltration. -Kees [0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/security/yama/yama_lsm.c?h=v5.12#n410 [1] https://lore.kernel.org/linux-mm/cover.1554248001.git.khalid.aziz@oracle.com/ [2] https://lore.kernel.org/lkml/20210505003032.489164-1-rick.p.edgecombe@intel.com/ [3] https://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html [4] https://git.kernel.org/linus/cf68fffb66d60d96209446bfc4a15291dc5a5d41 -- Kees Cook _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel