From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F23AD358D27 for ; Mon, 19 Jan 2026 11:00:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768820459; cv=none; b=Wa3qmSXMUmK2qjjXv3rtVflQuKrTAvMBlNxyH+B0g1bizdhuo0aG0u7qYMi+ykmNZ+3RLNzMyi9PEcVEKW5bHlein4k6jd1VW8fa9PjcuO3srpWKItO+IS//5lDACpjVY7pJ9fW+pVUjai8JmxTJQZQvPg3XyHXU++P9G37GPy4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768820459; c=relaxed/simple; bh=lp3d84SAlaKoy9STl9UeI+l079ASo84OvcsAUNtMtgY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=A37mV5qovL2LT54lwZw4c0qEaDaqmJlaOOOk7TTZGehHCmUP4sE3mcLNEZSENS4thW7D7b1V21Oa8R5qAfHO7VJdpQA9RhDlDaCk/hUKxn92F5rU9jXNS1+gQwxhBpQK9ZRXVHb5e2RxaGWsIlwDCkzhQ87pO61rJ5AgUeihv5o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=DIOJz5X3; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=aHPZtAMM; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="DIOJz5X3"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="aHPZtAMM" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1768820456; 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=m4LazPcF/wnlQqrBB0dkwPZ2Jb2xDS0R7wte5tpEq3I=; b=DIOJz5X3RA0qoKDhFWfGU3iZct7UbvbPA6xzu+uzLFwNztQ+RUAZTfPFu0nULONPSBBa8T Q7MyTyeNtBcV6CdpDxOIDptOPbkm0gdbd9LBVJCoN2qdKb8qnAAUrJGqfp323NC79V3F+V 5XUp7Q+CIsRuzkE0s4Jgyb8/r7eAsTg= Received: from mail-pf1-f199.google.com (mail-pf1-f199.google.com [209.85.210.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-433-rQZz__19OXSa0DO1RnB4zQ-1; Mon, 19 Jan 2026 06:00:55 -0500 X-MC-Unique: rQZz__19OXSa0DO1RnB4zQ-1 X-Mimecast-MFC-AGG-ID: rQZz__19OXSa0DO1RnB4zQ_1768820455 Received: by mail-pf1-f199.google.com with SMTP id d2e1a72fcca58-81f73452300so7861566b3a.1 for ; Mon, 19 Jan 2026 03:00:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1768820454; x=1769425254; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=m4LazPcF/wnlQqrBB0dkwPZ2Jb2xDS0R7wte5tpEq3I=; b=aHPZtAMMyfHfZrMBE1b52SnZzhofF2cSJYFniPffohYe3mBm7e1/B5AmVAR/629SMt eXU8EsVwobRdAyw5M+DerLlCIRg3IJ03dwcNFoVAHGQe8w+HffLVQnFaF2E10MZtmus/ wokYp6POAAU34t0zd9HaEZqZtOuZaonnLEoBW7DwlXGKUV93VDbX/HM86r6GQT+yapVf wNtQ+5EWiubPfSrkW1fxty9FlmO1ObOQRNIsBIiultL0EHIHJh8bYppRYaRpr7/I+qau cJZWZYkDolVEME0YMagKQY44mp/ldRysmVthQtFW5xb/b7sip4rWZWfz1c1ZYcTkAFLq b8GQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768820454; x=1769425254; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=m4LazPcF/wnlQqrBB0dkwPZ2Jb2xDS0R7wte5tpEq3I=; b=csEDaJwcF5sv4ILoIxeZzrtbZlwhVsQ22OVBfhWClFlctOiCGG9oxPmx3WfdWxQssm 9RNubUC42f+6QioJEYjBfLopfkCRT15a00YgWlMBxPnOZChI52+GT6q4zQx8/vKxJWnN oX1MGdrT2yRZcW2L4vAVZ1keGHFl0b5RAg1Q+w0xUnSX3HasTCs1xXDF/W24d6pq/4Nz 3BM7UW7zjtHExmnEYAGOeS7RtG+FoFCPABYkSWR1/IynMS+cWqsPiZ/Ro5l7jWkmz2Oz IpamXf67d8wKsk7O2sSQZeYGCm08c92UDuNqSOQxxfH4ECVj0znAQcH3opYNZ35+By5V v8jg== X-Forwarded-Encrypted: i=1; AJvYcCWB/vvtjdXHvQz5SGl3fCkYbsxgSld6xI+k/gJdb89yFA/plMmSYrj57O/+3ovY5x874nXgoKNQgpa3DtI=@vger.kernel.org X-Gm-Message-State: AOJu0YxL4dzY+D6L/qlHkofMYxIz89BksFOPw2eDSbnEkeECtXsxxnyv Tw0rY0Fc2OmJsCb6UV0vKueeGtak6DbkbtvUe3k93cBwu+h83nIp6K+r7jqYwWcs6RM9IsR4Ui7 S6QNUDkUqF7Vgo0zM/iqY+oYO+s4pY7LTW0o6ZUxZTXMV/9933U/tFx27HRIvs4052w== X-Gm-Gg: AY/fxX5BuOIHXH9waO61rw52tl6EgN8EhIbLtV0NPTK4DlGxb1Icjdier/dx4d3RU+z Iunr2iEzi/oOSpn9DQQYYeErmW0UTtl4NmGS/T8e944iE9dXgdtUalmoewDYc6oDT3NqNXGUeVi 9hOvY6HXXcdd2u/70jvcbrbXrFs/uOijGY+HzjJzeQShcAxVXzYPi4QDlxgba6m/i6MBadbIOo4 cFmrtRw+dCEqeZGeGAUfIHicBkAxLpCSh5VBoRcGurFKbpFi0+g50l4iE2j8XoDRn1d+gG47M9d YvVkJ+tWEnmqJNT730HFOXM6iwXSeGKe0he6AEb9weOR7pU6tcTcxwQ/vsvVIXs3lfxGbgGwcQT / X-Received: by 2002:a05:6a00:368d:b0:81f:3b6e:21be with SMTP id d2e1a72fcca58-81f9f6850b8mr9116342b3a.11.1768820454510; Mon, 19 Jan 2026 03:00:54 -0800 (PST) X-Received: by 2002:a05:6a00:368d:b0:81f:3b6e:21be with SMTP id d2e1a72fcca58-81f9f6850b8mr9116305b3a.11.1768820453951; Mon, 19 Jan 2026 03:00:53 -0800 (PST) Received: from localhost ([209.132.188.88]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-81fa10c03e1sm8433770b3a.22.2026.01.19.03.00.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Jan 2026 03:00:53 -0800 (PST) Date: Mon, 19 Jan 2026 18:57:23 +0800 From: Coiby Xu To: Rob Herring Cc: kexec@lists.infradead.org, linux-arm-kernel@lists.infradead.org, Arnaud Lefebvre , Baoquan he , Dave Young , Kairui Song , Pingfan Liu , Andrew Morton , Catalin Marinas , Will Deacon , Saravana Kannan , open list , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE" Subject: Re: [PATCH] arm64/kdump: pass dm-crypt keys to kdump kernel Message-ID: References: <20251226141116.1379601-1-coxu@redhat.com> <20260114210859.GA3197242-robh@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20260114210859.GA3197242-robh@kernel.org> On Wed, Jan 14, 2026 at 03:08:59PM -0600, Rob Herring wrote: >On Wed, Jan 07, 2026 at 07:39:24PM +0800, Coiby Xu wrote: >> On Tue, Jan 06, 2026 at 09:44:37AM -0600, Rob Herring wrote: >> > On Fri, Dec 26, 2025 at 8:11 AM Coiby Xu wrote: >> > > >> > > Based on the CONFIG_CRASH_DM_CRYPT feature, this patch adds >> > > LUKS-encrypted device dump target support to ARM64 by addressing two >> > > challenges [1], >> > > - Kdump kernel may not be able to decrypt the LUKS partition. For some >> > > machines, a system administrator may not have a chance to enter the >> > > password to decrypt the device in kdump initramfs after the 1st kernel >> > > crashes >> > > >> > > - LUKS2 by default use the memory-hard Argon2 key derivation function >> > > which is quite memory-consuming compared to the limited memory reserved >> > > for kdump. >> > > >> > > 1st kernel will add device tree property dmcryptkeys as similar to >> > > elfcorehdr to pass the memory address of the stored info of dm-crypt >> > > keys to the kdump kernel. >> > >> > Is there not any security issue with putting the key into the DT? The >> > DT is provided to userspace. There's provisions already to not expose >> > "security-*" properties to userspace (see __of_add_property_sysfs). >> > Though I think that has a hole in that the FDT is also provided as-is. >> > However, I don't even know who or what uses these properties. >> > >> > Rob >> >> Hi Rob, >> >> Thanks for raising the concern! If I understand DT correctly, this >> property is only accessible to the kexec'ed kdump kernel. A new DT is >> allocated and set up by of_kexec_alloc_and_setup_fdt. Btw, to be >> precise, it's putting the memory address where the key is stored but >> not the key itself into DT. The key is stored in the memory exclusively >> reserved for kdump. For more info on by who and how this property will >> used, I've created a dt-schema pull request as suggested by Krzysztof, >> https://github.com/devicetree-org/dt-schema/pull/181 > >Okay, that's a bit less sensitive. That still could expose a memory >address to user space which has generally been locked down in recent >years. Though I'm not sure we'd consider addresses of blobs passed by >kexec sensitive or secure. > >> >> And yes, there is no need for even userspace of the kdump kernel to >> access it. So this idea of "security-*" properties/__of_add_property_sysfs >> seems desirable. Thanks for bringing it up! I'll give it a try. > >Since it is just the memory address, kdump just moving the key would be >sufficient. Or the property can be removed early on. I think we do that >with kaslr seed IIRC. A security-* property is still exposed to user space. I think simply removing the property is an elegant solution! It's also much simpler than moving the key. I did a test and somehow wiping the old memory in read_from_oldmem_iter made it fail to read the keys. So I'll apply your suggestion of removing the property to next version. Thanks! > >Rob > -- Best regards, Coiby