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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E32F8C5B56A for ; Wed, 12 Aug 2026 10:08:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EBD566B0108; Wed, 12 Aug 2026 06:08:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E95716B0109; Wed, 12 Aug 2026 06:08:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DABDC6B010A; Wed, 12 Aug 2026 06:08:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id B6B866B0108 for ; Wed, 12 Aug 2026 06:08:54 -0400 (EDT) Received: from smtpin29.hostedemail.com (lb01a-stub [10.200.18.249]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 3F325401FA for ; Wed, 12 Aug 2026 10:08:54 +0000 (UTC) X-FDA: 85092193788.29.611AD5B Received: from flow-a7-smtp.messagingengine.com (flow-a7-smtp.messagingengine.com [103.168.172.142]) by imf30.hostedemail.com (Postfix) with ESMTP id 47B2980004 for ; Wed, 12 Aug 2026 10:08:52 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=jaseg.de header.s=fm3 header.b=DcXGvPte; dkim=pass header.d=messagingengine.com header.s=fm3 header.b="U jdjRg4"; dmarc=none; spf=pass (imf30.hostedemail.com: domain of contact@jaseg.de designates 103.168.172.142 as permitted sender) smtp.mailfrom=contact@jaseg.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1786529332; h=from:from:sender: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:dkim-signature; bh=bW88MBwEWiHxXalK9p7mEtRxunSdhzNV0Ppwj/k9i1k=; b=rmskmLH6HhTx/qeUrhgRJD+mNg2oQuwDsMJ2FdzT5nRjx1+PLhbdirOEns+6YDLQmYa2px OJs8vvcUrmxDGe2VDoXdTbi8y74Z5UxPcygJsw8l7ZfOhk+8CGSLqyrhneh3vYSSrY0Bgv tO8xHkMgl+w/Vr0U7Ft4pPe0LxtnYoc= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=jaseg.de header.s=fm3 header.b=DcXGvPte; dkim=pass header.d=messagingengine.com header.s=fm3 header.b="U jdjRg4"; dmarc=none; spf=pass (imf30.hostedemail.com: domain of contact@jaseg.de designates 103.168.172.142 as permitted sender) smtp.mailfrom=contact@jaseg.de ARC-Seal: i=1; a=rsa-sha256; d=hostedemail.com; s=arc-20220608; cv=none; t=1786529332; b=VdygeDxIDKls38ctoYUPD21P0ug7hOJ3XzTT2ACO4CHOPsdDkbrC+q+86HaT1spAClp41G tjLikDw1MECjoA39605HCX3z6+EUMwNtSizeXpgXPrcE4jzbJyC+F3Y/BoQU8XJ2OIZGAX +svLjJgfoxuDAHv3hzpHXyx9jJW7W68= Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailflow.phl.internal (Postfix) with ESMTP id BBF2A1380318; Wed, 12 Aug 2026 06:08:51 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-05.internal (MEProxy); Wed, 12 Aug 2026 06:08:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jaseg.de; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1786529331; x=1786536531; bh=bW88MBwEWiHxXalK9p7mEtRxunSdhzNV0Ppwj/k9i1k=; b= DcXGvPteCscZI/GwRFTH4mv+X4SBB/L2nxEuJXbaNHkr7F0smm74zCR8ytyfyDK2 deNYonkvGo9MorQPdzMgQpumMiqEhc8kh7MDjUKKqGqjt+dgXudLF2NAd+JuTt7x UOp9kU5qnPaxYmSlfLw9SLn1YvREorfEChCB8Vdv59wlD+g3/yCoYgGcpIqSe4Rc Qq1tBLIylDAWQwRLdfmoCCE0zKkoMgVOuw4NGvt6C++AcqG/yFKk+wuMQ/frzzUe WpyHueUkS66e1tAjVlj6aRNRY0MVy/A61UttJXizY4zHHKHxwuCQ04mYK+JdJibV BW5DkvddWVJNd+e4921zzA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1786529331; x= 1786536531; bh=bW88MBwEWiHxXalK9p7mEtRxunSdhzNV0Ppwj/k9i1k=; b=U jdjRg4+0h4GBVHbZWuRmenc5MOZBfXytCFvmTozoVejQhqsVKAEMlXEwYPkPtGUf ngjYTyAlntHn8cPfnVBmFXK6yymSNOQjVjq/zODcJ/9KAsZQleveajikxRPmdHh+ f0699mdyLBUNwQDcrQyRiireEzWnN1ycYuWE7UFyW7W5Vk+y62fJjCiUztDkiwHF hSPudpSXapetWUF82JoBdX+pfYcfIkKdL7WAcPaR+mxL4Agav8Dq2b1FFMhPkhW0 HB0CWybFVT+kC+5ykPmgP4BfbRihc8/zeqNji8x9JptmpqNW06HCLUF8eo8SwZoq IYnBLOl1NKyId+2gBMSzQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTFhXuUc5zonLNYLcZR1VVfiawIf/DLo3p0z5ttoTk/im5FO3AIzDhACbr4L+QCnil kioW5B72/SP07lPyYbCILOUlCTgqnf/GMHpVt2rW3DvDsF8fWXLyV6Ac927tGENmhoEL+J Z6CH2rvUSCSrM3xrC6dBhmoeT9oKOxUe4lTyzrsaEkFV1JXqZigC3Blmzh555hht6TIiKi 4nTF00vMvYIsG9kgYkE+A7k3OF7cYtOAnFjzfRjDuHBWPJ8P5jOo39HJ5TosgHthcL4QlG P7LPfpZKOLHflDDP05PIzu6Ek0lvi9TNUbB3XsXC6/c/eoqN+joQ+KYmRU6qOJdnW6tfk2 b3LcfBVqFT/qDJEWQC1jHMYXTbxwbN1oIMefnFPjOiXoCu9W7XlYR2+Vi6xD+4IcDtaHDf 3Pk7JEFjV5aRi/7eHGIdN9qQLITdCzsUHDcCHNYmXmuCjX0de6WRjIKRBxkr9zr/UoSGMy BNKaooHXOUsyG6uKaR7kNVptOhuOAnNTQ7wosLA3fxbSinTppxLVYVo701XXDmkSXpvxOt 2fnf6YwlDC373uXVWWSjQbW5oUSUiaeZBnj2S+q+kGyVEaXlZUP3YiSxUlbXsnbIPZIJSU LpZLpLWNEokxMls5XhgH+3e+Mki9vSCEGaM/bL8SmICNy1uQbJHeVjIUfaAg X-ME-Proxy: Feedback-ID: i60a14417:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 12 Aug 2026 06:08:41 -0400 (EDT) Message-ID: <9765f7ea-36bb-4c7b-a19b-7facec97b762@jaseg.de> Date: Wed, 12 Aug 2026 12:08:39 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 01/13] kexec: add CRASH_WIPE_SECRETS to wipe secrets before kdump To: Baoquan He , =?UTF-8?Q?Jan_Sebastian_G=C3=B6tte?= Cc: Andrew Morton , Mike Rapoport , Pasha Tatashin , Pratyush Yadav , Dave Young , Catalin Marinas , Will Deacon , David Howells , Jarkko Sakkinen , Jonathan Corbet , Shuah Khan , Paul Moore , James Morris , "Serge E. Hallyn" , Lukas Wunner , Ignat Korchagin , Herbert Xu , "David S. Miller" , Keith Busch , Jens Axboe , Christoph Hellwig , Sagi Grimberg , Trond Myklebust , Anna Schumaker , Mimi Zohar , James Bottomley , Marc Dionne , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Eric Biggers , "Theodore Y. Ts'o" , Jaegeuk Kim , Alexander Viro , Christian Brauner , Jan Kara , Alasdair Kergon , Mike Snitzer , Mikulas Patocka , Benjamin Marzinski , kexec@lists.infradead.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, keyrings@vger.kernel.org, linux-doc@vger.kernel.org, linux-security-module@vger.kernel.org, linux-crypto@vger.kernel.org, linux-nvme@lists.infradead.org, linux-nfs@vger.kernel.org, linux-integrity@vger.kernel.org, linux-afs@lists.infradead.org, netdev@vger.kernel.org, linux-fscrypt@vger.kernel.org, linux-fsdevel@vger.kernel.org, dm-devel@lists.linux.dev References: <20260811-crash-zeroize-rework-v2-0-9561d13c2340@jaseg.de> <20260811-crash-zeroize-rework-v2-1-9561d13c2340@jaseg.de> Content-Language: en-US From: =?UTF-8?Q?Jan_Sebastian_G=C3=B6tte?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Queue-Id: 47B2980004 X-Rspamd-Server: rspam07 X-Stat-Signature: hxajt1ioq698epowsf4zq1s3wyku7u31 X-HE-Tag: 1786529332-613521 X-HE-Meta: U2FsdGVkX1/Dcqg8l2vX0fSJoC0mpKj82a2CxDb8uekDvogrdaAq7n6xp135zNONNFrYYbuyF3IMANknR4kkeEqI0u/wOmSCib04BaVCOxEWfH7DmBwrVRadWt4bDoCR4UJJIkW0dHmWh/tO88Mvk3KDnjbYjvWAZhJfdLrno9NHdpqnCvIrdejKFHd1TIm8+NWHhlXPTiO4p6xlLw6IjO271jX1mLtTKmE8lEIpJn+3WY33p6Lv3YxeaXkKJ+5C/YplOp9WD1g4jDiiiCbYZ0Wa1Vu1gROkuIjkag5DRYOXt4bLFWMIrnGVb4RJf640azbwrUFXq3y6kBUP5BywXBkcR6o4L3xT3sKiHzYKNuOZDT7cNxRNhaUvdA9QgumXDc0j/ItikzknCtpHJKM480goUrqN+wyyh6BoT2AMdTkG1TF3/BzyhF3zDS7NcEnqDo+8QC1o/w//7WEtD32HmOwf3uXMZMntMRZa1i8/oDxTHOxlJ8/jWfC0eq9w9cugmy23couHNTHBq6jmEPaS3MIsxE5XL0mLAXoZJIeMeItvwGjHRJ6ljRrOQ8LMIiYZoxL/CwAeTyQTLHYex8NICxZhgTT97lRem8yw9G5TfzveyRQfOTzEjfaGVCLwD5BilxkJqLGhA+B2eV3+TFfsNqEMYmu6PtI4GgDbZXivpTLUlrGyLTlB5xHzT/Ufh7daoSu8UGyz33YFazCyt+bIeZEvO6zQ+MQgLSIYMWTjf/C5OfNpVKL9Pf9Yx5Bn5zBP0yasQXKz2/PYjz2+xIcQV5L15qMYG1j2d70YqJwa4tiLrTzTbC1APg5GXe06s3EHpclp+LXEEWr1mkqyITxdhMsIJ5WOJPGTo/yCCX8Ji0Yvg7M/ESqWmncY/QVTePH3Iz+ySAOsTItADAFrW776ANLYKSOaHPwPbZkpR2g5N+JMddaqD1r2fdatnNxOigG8ZRP2n9mLVK0dyJFnbSD g5X4mgQh zTD5/fA6yg7mRhTbI0aWFTIJlfpG+jPQdTarFzkidj1HWKiM8eFxUezeSzR+ylcQS9orxgDSnfJ3M5SctBBB+aTM3bDraBrFiwafSwXf66ukKBIk06KWYVId9CUlj2pwSLNiGtOiAdBT11lK2uDABcZYlcV4Ept2kfbdZS1eLKK2sfC7R+Ko7ybDwYDgeYjKUDpGN3KWafbHYRnrYeq+YPW2liQcvCPMARvyfKsK8VlGQ5XFT6T028weq/0jhkPOf1gneo7D0xwyB5zWe9jPyVmo/UOJ7eWWLSNOYHlwZ4xYjS1tDGyxB9FeFDq7H2coZk0Xv0ouMc/4+Fs3on2d9vlRyUIYAU//vSaLHlPwcXn5LBOgFyhaP2FMUPW+RBBi0MjcyiLx9DkQ7BtbenvPFryusiBo4dXsDRAKFKemKpxvwwrklJo9t6uC8cZdwKExTy3+yabnyduldK+0iBquoWbY/dW2Y+9ApfjwyJLnmpWWb80XdM6tYseKJsbur1oq+8qkZ/xfl3aIc4GJ7Q4cnQOqdYg== Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 8/12/26 11:30, Baoquan He wrote: > On 08/11/26 at 07:52pm, Jan Sebastian Götte wrote: > .....snip... >> @@ -142,6 +170,7 @@ void __noclone __crash_kexec(struct pt_regs *regs) >> crash_save_vmcoreinfo(); >> machine_crash_shutdown(&fixed_regs); >> crash_cma_clear_pending_dma(); >> + crash_wipe_secrets(); > > I remember when crash_cma added this, we argued a lot about the risk, > finally it's added in with an added note to tell it's an opt-in feature > and risky. I don't know if it opens a Pandora box, I think anything > wanted being here need prove anything else has been tried, and the thing > is very very important. If we don't guard the door well, one day one guy > cold come and said I need ask Oracle database to do some transactions > before juming into kdump kernel because the actions will save billions > of dollar. I see your point. > And what does security people say about this wiping? Is it very > important information and wiping is mandotary? There's no any other way > to wipe it or pollute it, no way in kdump kernel? I'm doing both - my kdump kernel does a linear memzero of all of DRAM. However, that's too slow - it takes several hundred milliseconds, and I want these cryptographic keys gone within no more than 10 ms. Doing this in the original kernel is cleanest I think, because to do a targeted erase in the kdump kernel, that kernel would have to know all the original kernel's symbols, and it would have to forensically reconstruct it's memory content similar to the crash utility. I think that's too complex and error-prone to do in this use case. I can imagine one alternative way to approach this, tell me what you think: Instead of registering wipe handlers that memzero places on panic, I could put an optional registry of (addr, len) descriptors into crashkernel memory that the original kernel populates with the PAs of buffers to clear ahead of time. Then the kdump kernel could do the actual memzero. This would remove all code from the actual kdump path here. The registry could be made per-core to avoid locks. > I noticed it's > happening on en embedded target, is it possible you do this on your > embedded kernel tree, but not mainline tree? I could keep it in a vendor tree, but I think the functionality is useful beyond my particular use case.