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 A07B2C43461 for ; Fri, 7 May 2021 23:58:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 69B6661435 for ; Fri, 7 May 2021 23:58:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230197AbhEGX67 (ORCPT ); Fri, 7 May 2021 19:58:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40852 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230140AbhEGX67 (ORCPT ); Fri, 7 May 2021 19:58:59 -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 18CE7C06138A for ; Fri, 7 May 2021 16:57:59 -0700 (PDT) Received: by mail-pj1-x102b.google.com with SMTP id g24so6104530pji.4 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=hC648UbhzwVGVSMkhvsTa0lUfFRzDU5FhAXK6/4fqVI/OEhrOfwL4JY3SLplGFIM7D Y0PQwuyHhSZPMHgUzH38qaNYc/sOD8AihJl0523etJOKHpjmv9gRAQ22DKs52L8OHPCl 1EZoK9ise0f1Q21ILxXirqmsOkWNph4wARw0rCI4Fx8yh/ElsvQksmRlvAFnHX2waNT+ D+cK3QpJ3VdtfWRUhlpnDwjuw6bHHJgaeQelMtMy7nGkdC3Q/nXg9Z1W9nZH4Vtv6dhR VgXnq+WbSgvpmIWH60GeZM8EjKpEJRrciv0qSDeboyVUmvt3zl//noX7BFBRlMF2pi5C USJQ== X-Gm-Message-State: AOAM530ZrXweCkXXMCROLz/betWWLLJYQllUEziQUPk+lOVS1lSdzqWj TqwSlDAtjTs7wdhfeodPXvjSBA== 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> Precedence: bulk List-ID: X-Mailing-List: linux-arch@vger.kernel.org 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