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=-7.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 490C9C43462 for ; Thu, 6 May 2021 16:45:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1C73861157 for ; Thu, 6 May 2021 16:45:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236009AbhEFQqM (ORCPT ); Thu, 6 May 2021 12:46:12 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:40182 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235933AbhEFQqK (ORCPT ); Thu, 6 May 2021 12:46:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1620319511; 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=YKgqzUJ4GOTx6bmW4NSxv6DPiIY3WWTz3FO8rQ9MCvHhPyTMuh9yxAK3jWqjYG+oTtyTrK FmZ1McC87KPhPOaBsNJfacaqvRUgVuc4LR9lkAyuKIEyxOvZq1T4/SzaK6ibEd7/xIjK4X /bZeAWZxWEv9GLcVfWb2W6jkgzXXN4k= Received: from mail-ej1-f70.google.com (mail-ej1-f70.google.com [209.85.218.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-151-f8cQdCYTOp-rerV8u3SOuA-1; Thu, 06 May 2021 12:45:10 -0400 X-MC-Unique: f8cQdCYTOp-rerV8u3SOuA-1 Received: by mail-ej1-f70.google.com with SMTP id 16-20020a1709063010b029037417ca2d43so1945508ejz.5 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=CS44VYveaTbN98HNJbeijXzSxokfdjulO5Gusa1inkGpld7CqxOrjdn5Gyh6ChzndV MkA29dMIS+3wpqqprgJTpXDjzL4etVMowxDuvhOxBf7GTlYO6Qjz0BbWl/Kq5SxslM3b ZLYKX91Bi8KMs9OEN6YeNqbiXASbdV1YGvv0ThZPA/sfhkqA1fWNRREVm7fGtxC+ZiQw PF9c4BtMS7MyIoQJlzlls5ObRyi2Te8K5IVvFXsksIaxoLY/Onu2OBEQroYuW0UJl9rd iERp1ecAIPOIUeU9F2AGJX6kL+X/jTXcf1OAafObZ3wqvy0R4AkuQ8hllCtfdlI85f4E SFdg== X-Gm-Message-State: AOAM530HwZeM292saTivQChNj19wTll5XR8JlMegp49Mc33Xxb2KR3vP kOsSMlUv7fitpuUxlShxfyN0XJKRufI6pxpFijjUT6bC8eh6rT9tJQye5O4iwGyWohVD2Z+gNhs az4w6D4wVLQDaem+d4Hbb1sDU X-Received: by 2002:a17:907:1c98:: with SMTP id nb24mr5478119ejc.206.1620319508729; 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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > > 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 use space code. Once the secret memory is > allocated, the user can't accidentally pass it into the kernel to 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 problem. > I was wondering if this also helps against CPU microcode issues like 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? > > 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_SECRETMEM? 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 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 the content from disk. Or, as an attacker, load a custom kexec() kernel and read memory from the new environment. Of course, the latter two are advanced mechanisms, but they are possible when root. We might be able to mitigate, for example, by zeroing out secretmem pages before booting into the kexec kernel, if we care :) -- Thanks, David / dhildenb 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.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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 1E445C433ED for ; Thu, 6 May 2021 16:45:40 +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 6EDEF61154 for ; Thu, 6 May 2021 16:45:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6EDEF61154 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.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=desiato.20200630; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:Subject: From:References:Cc:To:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=64Mll5Me07OreAjvPOzlUQ6AESDDL+GsGfMBMxsVBJQ=; b=JLE2eVylOcXkXUrpL67MBbhfh Ve/HrnhPPJwAiJWoOMeoT+zHbdLFjnwuCsX4juOacmQQlVdyHjNP6D02zh078qhWHN6Apoz+4etgi A1JdQxuObGL71yw5dGzixIrA/QPBQyIwMkPJSRfyw5USIXzIz6eJAUrvhbfST5FN0fVy93791luce JioFzxykNun1+cz5SCUvuCr2JHRDScK8wDsujJN20VcimWaygudSXOkgoE9gaYNEwq5dIwVv4xunF fXBVsWJKlMbAt1K8cqgB2JZpE8MsYODUDGx7/TZCfJq9HcKAvscniEm89YFYkZ1jgmD27OzOhl75i zfaSvWTXw==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1leh7q-004qWn-GT; Thu, 06 May 2021 16:45:22 +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 1leh7n-004qWR-IU for linux-riscv@desiato.infradead.org; Thu, 06 May 2021 16:45:20 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Transfer-Encoding: Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:Subject:From:References :Cc:To:Sender:Reply-To:Content-ID:Content-Description; bh=0s/7VDcOT9Z56vBvGNlao04OZufq+cCm9HLSATOe2hs=; b=rcI+jn5oUfgtkOsYmTagVukg34 Xlb4hhHCzcz/IB4e4C9R7P8aE9YxGcxgKAMLutIKkig4usLUGgKzBIgI9wtH+KkjqxjLTSawjjhJl Lv+mjbfJBWL4yTER5585voZaly02NDJiDeORIDaRag9QviuLueqJ8rlB/RTmx5uTC+LqhLJ8hBXDK 2x/+b62ncswUFIu7qTEkYmzkp6xSClQQKM6tDh2GWdAlBuGdrZfhsLUJzyUh9xwveF8499cdNZAI6 /mREsGNNtDXhEwtChGNtdR9QWlon3nO0t5cNJwPUTcPXeF2V1TFDXYH+UkBPnJFiOCqV0AOMqhdlD iXvnUl7Q==; Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1leh7k-006E6D-AD for linux-riscv@lists.infradead.org; Thu, 06 May 2021 16:45:18 +0000 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-ej1-f72.google.com (mail-ej1-f72.google.com [209.85.218.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-141-DNXMhpXINp6HYbAp919_Ig-1; Thu, 06 May 2021 12:45:10 -0400 X-MC-Unique: DNXMhpXINp6HYbAp919_Ig-1 Received: by mail-ej1-f72.google.com with SMTP id z6-20020a17090665c6b02903700252d1ccso1938808ejn.10 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=aMhhpVdzlulf/0pu5zFdhkUlk54yRNMM+7VbvpO4v8u7RQkTuoXWarXqqv5Rn27dkx 3hFm+ikMhTTPqtPc7c8QytgiZUJt92fPs6uQmu4tSxZQv8BlA1zgY5FOxo6Wumama/9/ faV+/TSS2Nna4IYxOK4Gh229mf1euWkXeFSy6PPl5fKC2K5NLRDJuBhnPtWfG7C0cJUp nalkstIPLIzH0DYFqe2IW8FdrRPZt+Twx1dwS+3b9hCN1YGG30cYlliO2avaSNQ7Jqov OqHgY/ptU58Vgv4dYoGM5e5F3HemWDU+IwXqmxVDKPJC1NUAgKr6UmCmK/tfcG4vEsxV cLYQ== X-Gm-Message-State: AOAM531O+JX0LYS1nI7C2GLSIcgBrNAVKmqjGkQLPJ+1zgUybvfCct8u FG3p7j+Qkodu3T+22iVKGvtGEBOTgQRpuUC9xcquv71Ua9M8/ocx5AhKIA6o50Ugc3LjbTylkvq Gzmf9UkR26MGG9H4fRfgLFNSnLvP4 X-Received: by 2002:a17:907:1c98:: with SMTP id nb24mr5478150ejc.206.1620319508753; 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: Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=david@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210506_094516_444779_E338B200 X-CRM114-Status: GOOD ( 34.19 ) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org 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. > > 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 use space code. Once the secret memory is > allocated, the user can't accidentally pass it into the kernel to 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 problem. > I was wondering if this also helps against CPU microcode issues like 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? > > 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_SECRETMEM? 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 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 the content from disk. Or, as an attacker, load a custom kexec() kernel and read memory from the new environment. Of course, the latter two are advanced mechanisms, but they are possible when root. We might be able to mitigate, for example, by zeroing out secretmem pages before booting into the kexec kernel, if we care :) -- Thanks, David / dhildenb _______________________________________________ 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.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 0205CC433ED for ; Thu, 6 May 2021 16:45:20 +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 4C96E610D2 for ; Thu, 6 May 2021 16:45:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4C96E610D2 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.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 EC534100EAB47; Thu, 6 May 2021 09:45:16 -0700 (PDT) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=170.10.133.124; helo=us-smtp-delivery-124.mimecast.com; envelope-from=david@redhat.com; receiver= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (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 57842100EC1CF for ; Thu, 6 May 2021 09:45:14 -0700 (PDT) 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-ej1-f71.google.com (mail-ej1-f71.google.com [209.85.218.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-234--_YesuR3PlKBsvu_T8-73Q-1; Thu, 06 May 2021 12:45:10 -0400 X-MC-Unique: -_YesuR3PlKBsvu_T8-73Q-1 Received: by mail-ej1-f71.google.com with SMTP id z15-20020a170906074fb029038ca4d43d48so1949031ejb.17 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=r5+oXpz+rONxZYRPV49MEpk1qOvbPfG/9w3RSAVgzVtaYWt3uXVsylHbgztR6b4jSx 8PsO//NyoZ5RNtkW91IYfO2G13+B0pcThmd/qJI17OYcorGjhHtUIR1TrM1rhz0A9HH+ PmWwHpv1Y2+mb99jWpjMM/B0gvNSHJNCE2BIhKVeGjVxZzmvAqjlYV8TBEloEmC+p2Si BD6JlPmxK6WQTh+qGGpg1MulGv80cSmZL2DqcLQzfOhkY+FKhdSlKeVP+vj6Z58rbnNA vMn4MLCJTyP2LQ6eujEw/cn4BW8HcHwuN2Ru04FybNMqAYbn6rqGKWW+fJynp4RznEJC 9n6g== X-Gm-Message-State: AOAM5337a4tq1eyP2tgbidmYDqaDFZ+BkXD0GRsdOsM8xC68Q8W84i5i sf5Qa/448KsK/kb5PLSBGeYK/jPWnMNRsSPp0d+98RrWYBgJlGHBDTAGPavgkkxD5BGr7rtI+hR +BBGUIgsq84CXz4WI2lLI X-Received: by 2002:a17:907:1c98:: with SMTP id nb24mr5478137ejc.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 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: Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=david@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Message-ID-Hash: EXQVSP7OQAMC32UVWMPOFXORBY2A4ASY X-Message-ID-Hash: EXQVSP7OQAMC32UVWMPOFXORBY2A4ASY X-MailFrom: david@redhat.com X-Mailman-Rule-Hits: nonmember-moderation X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation CC: Alexander Viro , Andy Lutomirski , Arnd Bergmann , Borislav Petkov , Catalin Marinas , Christopher Lameter , 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 Anderse n , 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 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"; format="flowed" Content-Transfer-Encoding: 7bit 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. > > 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 use space code. Once the secret memory is > allocated, the user can't accidentally pass it into the kernel to 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 problem. > I was wondering if this also helps against CPU microcode issues like 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? > > 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_SECRETMEM? 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 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 the content from disk. Or, as an attacker, load a custom kexec() kernel and read memory from the new environment. Of course, the latter two are advanced mechanisms, but they are possible when root. We might be able to mitigate, for example, by zeroing out secretmem pages before booting into the kexec kernel, if we care :) -- Thanks, David / dhildenb _______________________________________________ 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.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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 CA0FAC433B4 for ; Thu, 6 May 2021 16:47:22 +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 2F71261157 for ; Thu, 6 May 2021 16:47:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2F71261157 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.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=desiato.20200630; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:Subject: From:References:Cc:To:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=KqwGvVVto2nRjaRP8u8YtzQ+ql4sUVreELT0eYSgl54=; b=M/WWX49YxG89x0UeEl6DdOMmY QvaGt5wi4BexvS0SL/QGzugFFFcz5hWgbsn6DItPnrEV74lGeWERpIE4o+Am/ToBqDdsYXONWaB6b J0Dd/COraXpmv4zBUZqLwN0/hsY6d682Idw0z8BOFBa0XG6n7oA3UgIwO5TWlp48XAZQyarv8Z1SA VXzyVessRkL5/IDoX4ae+1c5cqp+yafadaVlI24JHtvKwVQnNsMOq/GDT24QgivFNzddG4JHTnMWY b5Y0+uXSDCA3/Z3bpiFVpVyi41/UVrfiRhxQxQy4uaA8XznM6oKUMnTRTDfqwtyHJr1SOO4jGAPVv 6lSF+QM+Q==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1leh7t-004qX7-CA; Thu, 06 May 2021 16:45:25 +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 1leh7n-004qWL-Ee for linux-arm-kernel@desiato.infradead.org; Thu, 06 May 2021 16:45:20 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Transfer-Encoding: Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:Subject:From:References :Cc:To:Sender:Reply-To:Content-ID:Content-Description; bh=0s/7VDcOT9Z56vBvGNlao04OZufq+cCm9HLSATOe2hs=; b=rcI+jn5oUfgtkOsYmTagVukg34 Xlb4hhHCzcz/IB4e4C9R7P8aE9YxGcxgKAMLutIKkig4usLUGgKzBIgI9wtH+KkjqxjLTSawjjhJl Lv+mjbfJBWL4yTER5585voZaly02NDJiDeORIDaRag9QviuLueqJ8rlB/RTmx5uTC+LqhLJ8hBXDK 2x/+b62ncswUFIu7qTEkYmzkp6xSClQQKM6tDh2GWdAlBuGdrZfhsLUJzyUh9xwveF8499cdNZAI6 /mREsGNNtDXhEwtChGNtdR9QWlon3nO0t5cNJwPUTcPXeF2V1TFDXYH+UkBPnJFiOCqV0AOMqhdlD iXvnUl7Q==; Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1leh7k-006E6B-9D for linux-arm-kernel@lists.infradead.org; Thu, 06 May 2021 16:45:17 +0000 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-f70.google.com (mail-ed1-f70.google.com [209.85.208.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-234-0NKuB6UmOgCmDFDSnsOcjA-1; Thu, 06 May 2021 12:45:10 -0400 X-MC-Unique: 0NKuB6UmOgCmDFDSnsOcjA-1 Received: by mail-ed1-f70.google.com with SMTP id d13-20020a056402144db0290387e63c95d8so2974364edx.11 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=tmfaOPZzrzyuhQyN+DOaO1rHRJeRt/PH8pwwXQmzfF0icvs6oit5pOJdzBf4IQ6Np9 XJ49QJdW+QuQhn08L8nIshqfgUtxs9uJUI/RLQrJYkPv7+giyyDG9Faad1u+5oT0NCoI 4MKs+z8U8gWVokXpWN3GFcluxfLQWLfklkHxlNfMITfU640g16ICOq3W+dG87tCmBSUq YgrlpRJOLhoFqxTA68nKU3DK+NoAdOKEAGI8dcxx671Xk9S385Ka+LB8ONGKNEa4V3Lx vnnQOJzVmpApSDh1Pdjdy+rB0z+80WEKFXNdwrqtR9s6EqCRTeJ5j+ayOBoJOQ2iQfqk xZPg== X-Gm-Message-State: AOAM530rfKCMT2BVyVT59ijusv4j7XAWYLKDo2YSSgrPIcxKic+sDQ6L bykfieu08tSJtHWlJOiWJooWAcntB6Rr5Nb6sj8vm/ZZ8L166S2cMrpzq2ECanIQaP3dAEbMJz6 oYbzaSvmnBUnuFTrpPEsjXcmdY8lOUiV7xg4= X-Received: by 2002:a17:907:1c98:: with SMTP id nb24mr5478147ejc.206.1620319508742; 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: Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=david@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210506_094516_406833_BCAC52F6 X-CRM114-Status: GOOD ( 35.67 ) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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. > > 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 use space code. Once the secret memory is > allocated, the user can't accidentally pass it into the kernel to 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 problem. > I was wondering if this also helps against CPU microcode issues like 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? > > 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_SECRETMEM? 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 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 the content from disk. Or, as an attacker, load a custom kexec() kernel and read memory from the new environment. Of course, the latter two are advanced mechanisms, but they are possible when root. We might be able to mitigate, for example, by zeroing out secretmem pages before booting into the kexec kernel, if we care :) -- Thanks, David / dhildenb _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel