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 23E40C433ED for ; Fri, 7 May 2021 07:35:54 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 68F456141B for ; Fri, 7 May 2021 07:35:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 68F456141B 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 CBD126B00A1; Fri, 7 May 2021 03:35:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C59286B00A4; Fri, 7 May 2021 03:35:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AAD008D0002; Fri, 7 May 2021 03:35:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0170.hostedemail.com [216.40.44.170]) by kanga.kvack.org (Postfix) with ESMTP id 9138E6B00A1 for ; Fri, 7 May 2021 03:35:52 -0400 (EDT) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 420638249980 for ; Fri, 7 May 2021 07:35:52 +0000 (UTC) X-FDA: 78113625744.16.22CE5A9 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf02.hostedemail.com (Postfix) with ESMTP id 2CF0640002C0 for ; Fri, 7 May 2021 07:35:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1620372951; 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=YRLhFcul/s0bAb0h6pwheuix10YVXJYp5em6Jk4RpTY=; b=LKQ8IWaBht40hQ37zGhiXWlx+x+Dj6an1dgqmq+UDQ3Msuggv1C2b3TezDAWLG/j28CUxx SYtxDjtmTeLa6lateTlt99a9Vpwn/iZBxnYdboXBfMzDsZa4lqARUwn76xIegra1nQR16K nHeDtHsZAN4JgiRXzfUjQ3eqptexoS4= 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-602-4Y5WXGS1P5SJP9pf-PRoYg-1; Fri, 07 May 2021 03:35:49 -0400 X-MC-Unique: 4Y5WXGS1P5SJP9pf-PRoYg-1 Received: by mail-ed1-f71.google.com with SMTP id c15-20020a056402100fb029038518e5afc5so4016854edu.18 for ; Fri, 07 May 2021 00:35:49 -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=YRLhFcul/s0bAb0h6pwheuix10YVXJYp5em6Jk4RpTY=; b=VfA4DU68MDh6afB+KkYjCtiAqnO/7PA6c7iWpc0pAAIMzZazGaLInplyYIn75Nlk0V TQSbuQPCuii/MZSiCPZKbAC/3TH1nFi20i3YOifkTz9axkTXv+7HXYt0MGc+uZsTXT7M Hr/Mkg9V46ifu5NL4rZ1GBEL3sWf5AX3QMrgKA1Z8Vv8sYA/fm5SHLAhWzhc7lYtMkNf Z2fAOsc5ZXRh1UFYxr0CeA060zoVfAXMNeAa6vKPfb+/VafiYf2M7FtxwVE10rbbZG5G MVNaDiI29FpYh8Q4IdMEq0C2gqkyREQtwyVaZAWVrX+BHysMFeU/CQ3A4uEUZ/lW9xOD 3bnQ== X-Gm-Message-State: AOAM531TT35yEKBrZ6HHAd1fjaDmfOLwHsI7LkKa7I8CKBFPF4yXMq0p 3i7H91+aG7JIGPY3HrDB6/VnPxh1971taK9YY572SPqSmMzvuehb+4SBEP382M4o5gmHrIXqVMd px7HCsE3Zx6g= X-Received: by 2002:a17:907:174a:: with SMTP id lf10mr8861603ejc.433.1620372948261; Fri, 07 May 2021 00:35:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx5XI2zKUbsKazvcW2Vr5jvMDeiB+dtOEKTtfzbIqz37aYae3i7ugq6B0OmfMhiabycSZroRA== X-Received: by 2002:a17:907:174a:: with SMTP id lf10mr8861569ejc.433.1620372947917; Fri, 07 May 2021 00:35:47 -0700 (PDT) Received: from [192.168.3.132] (p5b0c63c0.dip0.t-ipconnect.de. [91.12.99.192]) by smtp.gmail.com with ESMTPSA id l17sm2925176ejk.22.2021.05.07.00.35.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 07 May 2021 00:35:47 -0700 (PDT) To: Nick Kossifidis , jejb@linux.ibm.com Cc: Andrew Morton , Mike Rapoport , 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> <996dbc29-e79c-9c31-1e47-cbf20db2937d@redhat.com> <8eb933f921c9dfe4c9b1b304e8f8fa4fbc249d84.camel@linux.ibm.com> <77fe28bd940b2c1afd69d65b6d349352@mailhost.ics.forth.gr> 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: <5232c8a7-8a05-9d0f-69ff-3dba2b04e784@redhat.com> Date: Fri, 7 May 2021 09:35:45 +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: <77fe28bd940b2c1afd69d65b6d349352@mailhost.ics.forth.gr> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 2CF0640002C0 X-Stat-Signature: qjiz9mmo1c8j7ywci9xubzdk7eyhe7hu Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=LKQ8IWaB; spf=none (imf02.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 Received-SPF: none (redhat.com>: No applicable sender policy available) receiver=imf02; 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: 1620372919-116763 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 07.05.21 01:16, Nick Kossifidis wrote: > =CE=A3=CF=84=CE=B9=CF=82 2021-05-06 20:05, James Bottomley =CE=AD=CE=B3= =CF=81=CE=B1=CF=88=CE=B5: >> On Thu, 2021-05-06 at 18:45 +0200, David Hildenbrand wrote: >>> >>> 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. >> >> Anything that can leave physical memory intact but boot to a kernel >> where the missing direct map entry is restored could theoretically >> extract the secret. However, it's not exactly going to be a stealthy >> extraction ... >> >>> 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 :) >> >> I think we could handle it by marking the region, yes, and a zero on >> shutdown might be useful ... it would prevent all warm reboot type >> attacks. >> >=20 > I had similar concerns about recovering secrets with kdump, and > considered cleaning up keyrings before jumping to the new kernel. The > problem is we can't provide guarantees in that case, once the kernel ha= s > crashed and we are on our way to run crashkernel, we can't be sure we > can reliably zero-out anything, the more code we add to that path the Well, I think it depends. Assume we do the following 1) Zero out any secretmem pages when handing them back to the buddy.=20 (alternative: init_on_free=3D1) -- if not already done, I didn't check th= e=20 code. 2) On kdump(), zero out all allocated secretmem. It'd be easier if we'd=20 just allocated from a fixed physical memory area; otherwise we have to=20 walk process page tables or use a PFN walker. And zeroing out secretmem=20 pages without a direct mapping is a different challenge. Now, during 2) it can happen that a) We crash in our clearing code (e.g., something is seriously messed=20 up) and fail to start the kdump kernel. That's actually good, instead of=20 leaking data we fail hard. b) We don't find all secretmem pages, for example, because process page=20 tables are messed up or something messed up our memmap (if we'd use that=20 to identify secretmem pages via a PFN walker somehow) But for the simple cases (e.g., malicious root tries to crash the kernel=20 via /proc/sysrq-trigger) both a) and b) wouldn't apply. Obviously, if an admin would want to mitigate right now, he would want=20 to disable kdump completely, meaning any attempt to load a crashkernel=20 would fail and cannot be enabled again for that kernel (also not via=20 cmdline an attacker could modify to reboot into a system with the option=20 for a crashkernel). Disabling kdump in the kernel when secretmem pages=20 are allocated is one approach, although sub-optimal. > more risky it gets. However during reboot/normal kexec() we should do > some cleanup, it makes sense and secretmem can indeed be useful in that > case. Regarding loading custom kexec() kernels, we mitigate this with > the kexec file-based API where we can verify the signature of the loade= d > kimage (assuming the system runs a kernel provided by a trusted 3rd > party and we 've maintained a chain of trust since booting). For example in VMs (like QEMU), we often don't clear physical memory=20 during a reboot. So if an attacker manages to load a kernel that you can=20 trick into reading random physical memory areas, we can leak secretmem=20 data I think. And there might be ways to achieve that just using the cmdline, not=20 necessarily loading a different kernel. For example if you limit the=20 kernel footprint ("mem=3D256M") and disable strict_iomem_checks=20 ("strict_iomem_checks=3Drelaxed") you can just extract that memory via=20 /dev/mem if I am not wrong. So as an attacker, modify the (grub) cmdline to "mem=3D256M=20 strict_iomem_checks=3Drelaxed", reboot, and read all memory via /dev/mem.= =20 Or load a signed kexec kernel with that cmdline and boot into it. Interesting problem :) --=20 Thanks, David / dhildenb