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.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, 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 45365C433B4 for ; Thu, 6 May 2021 16:45:16 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A992A610D2 for ; Thu, 6 May 2021 16:45:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A992A610D2 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 0A5FC6B006C; Thu, 6 May 2021 12:45:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 042BC6B0071; Thu, 6 May 2021 12:45:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DB0846B0072; Thu, 6 May 2021 12:45:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0080.hostedemail.com [216.40.44.80]) by kanga.kvack.org (Postfix) with ESMTP id BA9366B006C for ; Thu, 6 May 2021 12:45:14 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 725C9A2DD for ; Thu, 6 May 2021 16:45:14 +0000 (UTC) X-FDA: 78111381348.27.70C5342 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf17.hostedemail.com (Postfix) with ESMTP id 4339040002E6 for ; Thu, 6 May 2021 16:45:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1620319513; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0s/7VDcOT9Z56vBvGNlao04OZufq+cCm9HLSATOe2hs=; b=G5LPTYpGrR3Su1IYZH1gXqMZwyHEAvgcI0l4Cj1aXNS6shNfJON3gJTdPjf3ompWBEJ2LN EQ4LMPXce2x77OY4EVTML8jSDO6jIkyQXqcVhLCqvdmiBIhWvEUTbl/ljZkurD2bJc2szN j7l5HSE1oWhHw/AzrwaZ+Rj07xVscEk= Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-180-9iF77jkyOKm08pu-_ZtTTQ-1; Thu, 06 May 2021 12:45:10 -0400 X-MC-Unique: 9iF77jkyOKm08pu-_ZtTTQ-1 Received: by mail-ed1-f71.google.com with SMTP id w20-20020aa7dcd40000b02903886b9b0013so2946975edu.22 for ; Thu, 06 May 2021 09:45:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:organization:subject :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=0s/7VDcOT9Z56vBvGNlao04OZufq+cCm9HLSATOe2hs=; b=GTitMgiv4vmwQmpQZagxherCDtBUQSMW9J4PhoMM7EaZYUblNTeiy8Me5GDthoHio6 5OMG+L+AsIrQOqPExqhqPc2Hz9yOEqSK9nXUbRqqprFpKttTLtFHKMlj/UH4ofZUBiV+ b0gjEBMJSTuPJJHhfbhfx39ldq0momr69yS3hfe/FDlYGHoU4aEBY9D8IfBMUzOzzIW/ NxkcWH3LN8dCoDCFou/5BHWYQAZbNzgQ6EsZTTNZX3iOItIDPj8K3JcgebBGEAAILcID ghXEvAYO6NQv318mcPfJqcDpo0PicMqmRqeUnKYbOAyHhAtMe1dolERiVoxYDj8rMqpm 94cA== X-Gm-Message-State: AOAM532m6H6rzW8wp1IEcv56EiIHRpMEmSarOzW7YL4hqwj6lYSY5Fr6 W0xSyV328netowTl8ADSQdM8U/AvInrnpoVV64xhbdda/iUOJ5wzvFlETzXjQ6gckLZB7NIZRIm ZKieJIsh0euE= X-Received: by 2002:a17:907:1c98:: with SMTP id nb24mr5478141ejc.206.1620319508732; Thu, 06 May 2021 09:45:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzw+5/fwG+KvK+SBzoVexxr801GBTZ6Zrmz5O+rAzTFPxJI4yj9g+Ax3izTWEuuMsZJC630XQ== X-Received: by 2002:a17:907:1c98:: with SMTP id nb24mr5478083ejc.206.1620319508409; Thu, 06 May 2021 09:45:08 -0700 (PDT) Received: from [192.168.3.132] (p5b0c64ae.dip0.t-ipconnect.de. [91.12.100.174]) by smtp.gmail.com with ESMTPSA id f19sm2095318edu.12.2021.05.06.09.45.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 06 May 2021 09:45:08 -0700 (PDT) To: jejb@linux.ibm.com, Andrew Morton , Mike Rapoport Cc: Alexander Viro , Andy Lutomirski , Arnd Bergmann , Borislav Petkov , Catalin Marinas , Christopher Lameter , Dan Williams , Dave Hansen , 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, x86@kernel.org References: <20210303162209.8609-1-rppt@kernel.org> <20210505120806.abfd4ee657ccabf2f221a0eb@linux-foundation.org> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH v18 0/9] mm: introduce memfd_secret system call to create "secret" memory areas Message-ID: <996dbc29-e79c-9c31-1e47-cbf20db2937d@redhat.com> Date: Thu, 6 May 2021 18:45:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=G5LPTYpG; spf=none (imf17.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 4339040002E6 X-Stat-Signature: 9k3638yyp449ywzunxb35k96mfxp446z Received-SPF: none (redhat.com>: No applicable sender policy available) receiver=imf17; identity=mailfrom; envelope-from=""; helo=us-smtp-delivery-124.mimecast.com; client-ip=170.10.133.124 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1620319509-925649 Content-Transfer-Encoding: quoted-printable 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 06.05.21 17:26, 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. >>> >>> 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. >=20 > 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. >=20 > But also: >=20 > 1. Memory safety for use space code. Once the secret memory is > allocated, the user can't accidentally pass it into the kernel t= o be > transmitted somewhere. That's an interesting point I didn't realize so far. > 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 probl= em. >=20 I was wondering if this also helps against CPU microcode issues like=20 spectre and friends. >> >> 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? >=20 > 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 gadget. What stops "root" from mapping /dev/mem and reading that memory? IOW, would we want to enforce "CONFIG_STRICT_DEVMEM" with CONFIG_SECRETME= M? Also, there is a way to still read that memory when root by 1. Having kdump active (which would often be the case, but maybe not to=20 dump user pages ) 2. Triggering a kernel crash (easy via proc as root) 3. Waiting for the reboot after kump() created the dump and then reading=20 the content from disk. Or, as an attacker, load a custom kexec() kernel and read memory from=20 the new environment. Of course, the latter two are advanced mechanisms,=20 but they are possible when root. We might be able to mitigate, for=20 example, by zeroing out secretmem pages before booting into the kexec=20 kernel, if we care :) --=20 Thanks, David / dhildenb