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=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 93BE8C433ED for ; Thu, 6 May 2021 23:16:26 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0B0FB613C5 for ; Thu, 6 May 2021 23:16:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0B0FB613C5 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=ics.forth.gr Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id EDFB26B0070; Thu, 6 May 2021 19:16:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EB6B26B0071; Thu, 6 May 2021 19:16:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CE23D6B0072; Thu, 6 May 2021 19:16:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0043.hostedemail.com [216.40.44.43]) by kanga.kvack.org (Postfix) with ESMTP id B34176B0070 for ; Thu, 6 May 2021 19:16:24 -0400 (EDT) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 65FED443F for ; Thu, 6 May 2021 23:16:24 +0000 (UTC) X-FDA: 78112367088.20.CD6699C Received: from mailgate.ics.forth.gr (mailgate.ics.forth.gr [139.91.1.2]) by imf06.hostedemail.com (Postfix) with ESMTP id AC2CCC0007CF for ; Thu, 6 May 2021 23:16:24 +0000 (UTC) Received: from av3.ics.forth.gr (av3in.ics.forth.gr [139.91.1.77]) by mailgate.ics.forth.gr (8.15.2/ICS-FORTH/V10-1.8-GATE) with ESMTP id 146NGIi3043563 for ; Fri, 7 May 2021 02:16:20 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; d=ics.forth.gr; s=av; c=relaxed/simple; q=dns/txt; i=@ics.forth.gr; t=1620342973; x=1622934973; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=uf0onNfnHBzOPbID0tZ8t011w+r/nxI4x/Q1TyEOdQE=; b=PM4UzE0tjJb0ton6+hFqgkCcvCPtBByAxRm712TdGgM8oH0uKI3fYmQulecm+EDP VX/y3RFo1wqeqd0M0KT/NGXp67dMJ3EswjXL7/Rvs2m3exSNibfkcTfc4Ds1LdVZ zIO1mwOOSeXB/gkB+gBayO9ehtfE1kOLWrgcVaes3kdO9vNH4wOxJv3okCWEcOXq 7wxQ55OdhLAsE3nZ4q/4x7s7ycQC0w3Gol5dj1eF7An6hnmST3jy8YU3tIa2mTWi ctsjP4o/QYbATmSPpaRFC0hLvogkCgCc8SAFLAmz5IdYCrO9I64z/wBrUohkg55F bxOCRdo40Lnk7VwOyEhcoA==; X-AuditID: 8b5b014d-a70347000000209f-ba-609478bd5c23 Received: from enigma.ics.forth.gr (enigma.ics.forth.gr [139.91.151.35]) by av3.ics.forth.gr (Symantec Messaging Gateway) with SMTP id EB.87.08351.DB874906; Fri, 7 May 2021 02:16:13 +0300 (EEST) X-ICS-AUTH-INFO: Authenticated user: at ics.forth.gr MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Date: Fri, 07 May 2021 02:16:03 +0300 From: Nick Kossifidis To: jejb@linux.ibm.com Cc: David Hildenbrand , 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 Subject: Re: [PATCH v18 0/9] mm: introduce memfd_secret system call to create "secret" memory areas Organization: FORTH In-Reply-To: <8eb933f921c9dfe4c9b1b304e8f8fa4fbc249d84.camel@linux.ibm.com> References: <20210303162209.8609-1-rppt@kernel.org> <20210505120806.abfd4ee657ccabf2f221a0eb@linux-foundation.org> <996dbc29-e79c-9c31-1e47-cbf20db2937d@redhat.com> <8eb933f921c9dfe4c9b1b304e8f8fa4fbc249d84.camel@linux.ibm.com> Message-ID: <77fe28bd940b2c1afd69d65b6d349352@mailhost.ics.forth.gr> X-Sender: mick@mailhost.ics.forth.gr User-Agent: Roundcube Webmail/1.3.16 X-Brightmail-Tracker: H4sIAAAAAAAAA03SfUwTZxzA8Tx317uDrOFEGZdKwNWRbGwrmsn8JTKijs2LRuLMFhUW5AI3 YEMkLRAmc2EC8qqjtS+uRXlRAUlHoWUwCoQXZQUFXwpaNhHr4I91MNxkTEaHjK5bwj9PPsnv l+f5/vHQuH+HSEKnpmcK8nQ+TUr6EmVxus1vdOeoE7Y8rwmBSpORhGXV9xTMNz8n4UldOQLH n7MIdJo7CH5uLkKwYFrCoW5eTcCC6g4J2pZAqB1vw8CorMHB8qyYhGLrAgHmqfsi6OoeImDU WkmCbuIJCZPGFRHkKx9Q0DZfQMJt6zciuOK4i8GjszvB3luNwb3HBgJuVDgpcI2W43Ba7we2 M70YLP+wegzftIvguqkdg3F1Hgl992cQqF1NFFjMGhxODZgwuL1sE0HBRAS4F1cfXWyeEu18 jXtWeJbgjBeNiHMvqRA363IRnDJ/juI69A8prtqcxVkawrhLXS6MMzeWkJz5qYri5m7dorjB 826Cmx7TYVxFbS/iLg69fyAo1jcySUhLzRbk4VEJvilu0zSWcdUvx5CnovKQ9oVS5EOzzDZ2 pP4SKkW+tD8zgNjxDhXlHUSwhu4S5LGYWccOfT1NeIwzwGrGepDXIWz+twbcY4IJZQunlzGP SeZVtsret7pP0xuYF9k5Y7B3fUHMOpThHq9nBLbu0SjpsR+znn368K7IYx9mH/tTWRfh7WnE 2CbVH/81RLNttnukt+1l9je3k/LcH7BqywVpBVqnX1OqX1OqX1NajfBGxPDZb8pSExWyj4/L M1NkyXIz+vd3of3foQeWX2X9CKNRP2JpXLpBfLP2XIK/OIn/7IQgP35UnpUmKPrRRpqQBorF soqj/kwynyl8KggZgvz/KUb7SPIw2ye49vWaA7G7646gV97u3FS/vSc+sGAXzQTzA+8ym22D fVdq9w5+0HCygX4skW48Nzw+c3lP/kRMg7mocleU6PCxbbGNY6f4SbrqWkzPaEn5mb25xS99 eCI0Lqp+UR2wPTc7aEYjuyHZpI4+KZS3HYmov1z11Wyc1nb+gmEpMqA874uglMPD82NO7Zxj x+fh4cnYwc6t6SO7i6xJDvvgis+P7YfYmD36GVPxlwMfheXwzEF5xu9ME52YteN0HHM1VP2L zKjtlBiynFH7nWVNrVN/C9b49ux3qt5rPRapmNTxRSst5MhkdHohWWFShiRu+ev6W/amVs2h ay1B4vjS4FwpoUjht4bhcgX/D3XLkQHMAwAA Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=ics.forth.gr header.s=av header.b=PM4UzE0t; dmarc=pass (policy=none) header.from=ics.forth.gr; spf=pass (imf06.hostedemail.com: domain of mick@ics.forth.gr designates 139.91.1.2 as permitted sender) smtp.mailfrom=mick@ics.forth.gr X-Stat-Signature: 1cbzwh1ubsibiuq4fmwdb44jwya9ydxc X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: AC2CCC0007CF Received-SPF: none (ics.forth.gr>: No applicable sender policy available) receiver=imf06; identity=mailfrom; envelope-from=""; helo=mailgate.ics.forth.gr; client-ip=139.91.1.2 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1620342984-167359 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: =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: >>=20 >> Also, there is a way to still read that memory when root by >>=20 >> 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. >=20 > 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 ... >=20 >> 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 :) >=20 > 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=20 considered cleaning up keyrings before jumping to the new kernel. The=20 problem is we can't provide guarantees in that case, once the kernel has=20 crashed and we are on our way to run crashkernel, we can't be sure we=20 can reliably zero-out anything, the more code we add to that path the=20 more risky it gets. However during reboot/normal kexec() we should do=20 some cleanup, it makes sense and secretmem can indeed be useful in that=20 case. Regarding loading custom kexec() kernels, we mitigate this with=20 the kexec file-based API where we can verify the signature of the loaded=20 kimage (assuming the system runs a kernel provided by a trusted 3rd=20 party and we 've maintained a chain of trust since booting).