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=-6.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, 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 D320AC43470 for ; Fri, 7 May 2021 23:58:01 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4586A6142D for ; Fri, 7 May 2021 23:58:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4586A6142D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8AAB66B0099; Fri, 7 May 2021 19:58:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 882316B00A0; Fri, 7 May 2021 19:58:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6FB656B00A3; Fri, 7 May 2021 19:58:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0052.hostedemail.com [216.40.44.52]) by kanga.kvack.org (Postfix) with ESMTP id 4F7BD6B0099 for ; Fri, 7 May 2021 19:58:00 -0400 (EDT) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 0E1B18249980 for ; Fri, 7 May 2021 23:58:00 +0000 (UTC) X-FDA: 78116100720.05.FA00FF7 Received: from mail-pj1-f52.google.com (mail-pj1-f52.google.com [209.85.216.52]) by imf14.hostedemail.com (Postfix) with ESMTP id BE451C0007CE for ; Fri, 7 May 2021 23:57:37 +0000 (UTC) Received: by mail-pj1-f52.google.com with SMTP id h14-20020a17090aea8eb02901553e1cc649so6339740pjz.0 for ; Fri, 07 May 2021 16:57:59 -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=2iQQvEB0+fCpb/rAB5HWawShZb8qZlIcaFuxaSL0oes=; b=EqhSZy45d2y8OQQwraWGhlD9n54vClwPwSn7UuK9xZviJIBJseEIUX0aF36GebrTNP 3Y9esEq2VEVMdpYAd+09juu7yIqSSNYhNNt+rVs1po+n6QlJ3kc6cbxhUV5wUfFprLGx TjvIY1CeOIbcMr4b7WQIEnR9bfI+n///RODlA= 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=2iQQvEB0+fCpb/rAB5HWawShZb8qZlIcaFuxaSL0oes=; b=pBxuK2NHoq5hRPtvMmcBTND4QkIAC1YbhBNkmjLO9E0AZ8OSj3PIv3FTiVmpGTczDW ii55UgTUbLTJbWwjmpbz4JH+4LzbHbjWKgB4HMn+M4bbbmbtYeWcr6NZ0gqqsRuJAUpb modzdaSLEp+7FvYE2IyecTPm+y0XJlx/YxpaGwFs9sMnxGoMgJYXb5aQXhP/OUSh7Yk2 wnKiP06aD19rsBkNgiMJhbl3/WRCoMlw1wD4FErHOvam9Lg3LTdrDPmhxbSncko4JsEw hR1x0PYuKM6Kh8jwwwR2ldUj4ip5Epzvb9Kh4xLxwFXc6jNOOSXju6ceBXw4zvveoAmK VICw== X-Gm-Message-State: AOAM533qfOY8bj2XUpGZ9MI6SuIWHrtOyJwDmASWROAE3Sa+ZvuSoPHj Wx/b1JVPIe9UGy9vbxpqszqkBA== X-Google-Smtp-Source: ABdhPJwW5et97Z//abVIXmo2gBu5V8/Vzg230KpxBawys34RoMW6n/H4x7d7dTWApKrw1+7V8ZstIg== X-Received: by 2002:a17:902:ff09:b029:ed:3b29:ff43 with SMTP id f9-20020a170902ff09b02900ed3b29ff43mr12583115plj.14.1620431878548; Fri, 07 May 2021 16:57:58 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id ha14sm5011198pjb.40.2021.05.07.16.57.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 07 May 2021 16:57:56 -0700 (PDT) Date: Fri, 7 May 2021 16:57:55 -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: <202105071620.E834B1FA92@keescook> References: <20210303162209.8609-1-rppt@kernel.org> <20210505120806.abfd4ee657ccabf2f221a0eb@linux-foundation.org> <202105060916.ECDEC21@keescook> <9e1953a1412fad06a9f7988a280d2d9a74ab0464.camel@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9e1953a1412fad06a9f7988a280d2d9a74ab0464.camel@linux.ibm.com> X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: BE451C0007CE Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=EqhSZy45; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf14.hostedemail.com: domain of keescook@chromium.org designates 209.85.216.52 as permitted sender) smtp.mailfrom=keescook@chromium.org X-Stat-Signature: dc4t6xhzgst9nyfp1cigffkihnt6ngs8 Received-SPF: none (chromium.org>: No applicable sender policy available) receiver=imf14; identity=mailfrom; envelope-from=""; helo=mail-pj1-f52.google.com; client-ip=209.85.216.52 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1620431857-205774 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, May 06, 2021 at 11:47:47AM -0700, James Bottomley wrote: > On Thu, 2021-05-06 at 10:33 -0700, Kees Cook wrote: > > On Thu, May 06, 2021 at 08:26:41AM -0700, James Bottomley wrote: > [...] > > > > 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")? > > It doesn't prevent privilege escalation from happening in the first > place, but once the escalation has happened it protects against > exfiltration by the newly minted root attacker. So, after thinking a bit more about this, I don't think there is protection here against privileged execution. This feature kind of helps against cross-process read/write attempts, but it doesn't help with sufficiently privileged (i.e. ptraced) execution, since we can just ask the process itself to do the reading: $ gdb ./memfd_secret ... ready: 0x7ffff7ffb000 Breakpoint 1, ... (gdb) compile code unsigned long addr = 0x7ffff7ffb000UL; printf("%016lx\n", *((unsigned long *)addr)); 55555555555555555 And since process_vm_readv() requires PTRACE_ATTACH, there's very little difference in effort between process_vm_readv() and the above. So, what other paths through GUP exist that aren't covered by PTRACE_ATTACH? And if none, then should this actually just be done by setting the process undumpable? (This is already what things like gnupg do.) So, the user-space side of this doesn't seem to really help. The kernel side protection is interesting for kernel read/write flaws, though, in the sense that the process is likely not being attacked from "current", so a kernel-side attack would need to either walk the page tables and create new ones, or spawn a new userspace process to do the ptracing. So, while I like the idea of this stuff, and I see how it provides certain coverages, I'm curious to learn more about the threat model to make sure it's actually providing meaningful hurdles to attacks. -- Kees Cook