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.133.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 2CF1C328631 for ; Wed, 7 Jan 2026 11:40:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767786016; cv=none; b=Q7fmAMSpDirC2y0xk995uJyKCDaLzAvNaaxlduuoZfz3Eji3UV/RDiU8WNNbawtQgDvaJz9BGlR3AY0CEn+AeSUq9FwuZ4QaN8paMeBA4epqoY283fObnNH9COXzKCU9VXv3eC2A9aKgtjHHPl8y8ZWf8SKR6d3/HOxsbFDnPLE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767786016; c=relaxed/simple; bh=GUZ4Wx6kNbC4KqlRAQsAUWRwHERRG4ZUa5WYxp23ABc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=C4bQXnr/I1cnOfTsECXrlgM5Wu0475gsjbIZ4QkvIRv+DIJj1Sv6aKEWcxReDbjclZ9GoMipL6Op9IcXKnfZVUz4cXVPORTI0pglfOhgggSpXDiunxEp5T4oVaZ85+lX91Y8ZHHpX/AbleyRo+saXNM+sSUl5HnRWeg7+CNBg1U= 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=fl4TJ9c8; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=XFzFNzze; arc=none smtp.client-ip=170.10.133.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="fl4TJ9c8"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="XFzFNzze" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1767786014; 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=+eDzB+NxPTMSfU1QkUTyVqhC+G+UiTkNvq2nlq1j3r4=; b=fl4TJ9c88cVfIbj1z+RhJWdisHHY/qnM78jMvPF4IcGiUQTNS4xOs5aZRwwOEbORkSu+0G 9rrdvzU4qeUKg+PsE9SBuhw0LYAeakFsYMcNsE8TgnSuVA9vd/LLEBrCzvwx9AGsreq0vt airY3mFK2cZ2xhmWzAJlyCLI2Xt5FeQ= Received: from mail-pf1-f200.google.com (mail-pf1-f200.google.com [209.85.210.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-336-DfFKprG6MFqoqhb37WR3rg-1; Wed, 07 Jan 2026 06:40:13 -0500 X-MC-Unique: DfFKprG6MFqoqhb37WR3rg-1 X-Mimecast-MFC-AGG-ID: DfFKprG6MFqoqhb37WR3rg_1767786012 Received: by mail-pf1-f200.google.com with SMTP id d2e1a72fcca58-7b9321b9312so4102715b3a.1 for ; Wed, 07 Jan 2026 03:40:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1767786012; x=1768390812; 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=+eDzB+NxPTMSfU1QkUTyVqhC+G+UiTkNvq2nlq1j3r4=; b=XFzFNzzeNfXZZTOKpttSnlTmHJK44fcGjIDuYbBISI0jwy4l7meCpQcwjUHsA0dB7R 5uJlRcI9VZlKUPLmvBqnUSr8FMCUZ/rmwkmFEMYPFRwzLTCx64HlDMi+j/T+eNWfgVhe BPm2aaPgTaA2g9LNTpyfmE9+nKcKVfupZO3xoHuA+kelzLVbCftFmCvFh6Nnanwpr5rK mStZOD84Lf5iWeCXXzI56pMREMpDI53CyDCMp51KdhiLxV3yupzDZfY1pmVIAnMzzh34 euneEsbXtzsk6JD3yQe8IA3fFruFIBu1gHIuGEAl5DsAxtWRva4jOPvvemRN9szEsw/t SekA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767786012; x=1768390812; 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=+eDzB+NxPTMSfU1QkUTyVqhC+G+UiTkNvq2nlq1j3r4=; b=NWWdKQVi7bUeFS5iaYbiCWSt+q15myNaV9c7QZSX6E415yQh/26McUVn8AiQDDlwl/ 8g+ktgflDX4cvltbr/tUot0e+ENPLf8NwNFPGUmLsj0YxcXLQpsGLcHNPsou0Dg1Clgr 4QCVGh/lwLPMJcZdx/3UA2YJNCSXf31vZ4rh1VJbIGvqMXo+5nPAE6yybdio3iEzfKgj Y/my6Jagvm3whFXpyEZe2dUepZfLhnLsFOqEnfRJQq0vrnaC2IZeHIS0bTjdXhByBpse bRDmOUbGOWovo1+uG15cKWtL+cfu+FUd7UvEADKMsiAvBnzebL25YY9S2+eY0Cs/awQF f2AA== X-Forwarded-Encrypted: i=1; AJvYcCULjZjvTg8RY5pNWW7QMub6kq9yzr4B0dA7B3EVF2SQcwehuzQW6TQyoXSnAsxfOsFVMRxad0ToeL896+E=@vger.kernel.org X-Gm-Message-State: AOJu0YwAgL0mwTSretzGzdcnQR2lkT8LhA8iHXN3aP/kkVrpv/C2lz6Y N/gL0chrdNlMNT8pzMSdBUQIYCF1OnXOFdbFtLl4vQ4mVs8akt/wGcopIqo1Ctjaa2shUNbh8dB GOt+Y9ppIxFlOKwMj1AKBsdiaO2JelqwLYQ+uLHHzxk/bE+NnM6A2rVZ/1h4rWG54gA== X-Gm-Gg: AY/fxX6RsYoCYxR/0VsE/U/s7fu1ubt8SsFmpN3qofIbWlM4eUnpjyok7GfA3Uukt3e DZ91uVLkiRJz6VdfxfVg9UE48xoeI9NTvfJVnWMRGc84yp1sK0VICqLE+8L8XtIQHeEojm7CKcp LvF7i0aCHKnFIK9sxq6jGjsdV4D5KbNQjy4Yp4St48nWJTw4Eao1O2NL8bIoHlEVdyxNTPDwE+a w59sfrla1Cvytli0calqStTZO82lW2bfPI9+uquzHqCIhWbOR2icAeFCq5glQ2I0YlnA7YBxn20 33fZszUj5d7m/vcmlbiDZMb7YPWxeHK8R/YMJFPk1tv/U5a+Kx9enx+4+UaqdxbQJmDlKyF/XWk H X-Received: by 2002:a05:6a00:1d20:b0:7aa:3642:2173 with SMTP id d2e1a72fcca58-81b7de5a491mr2214385b3a.31.1767786011730; Wed, 07 Jan 2026 03:40:11 -0800 (PST) X-Google-Smtp-Source: AGHT+IEGXM4qkZ9fSQv6m8Rd/JdXyBCGgbb2bJvKNCFco+IWIxgyQ+1wvGxJ3YwuXhQ9Ytpo9HhqWA== X-Received: by 2002:a05:6a00:1d20:b0:7aa:3642:2173 with SMTP id d2e1a72fcca58-81b7de5a491mr2214356b3a.31.1767786011263; Wed, 07 Jan 2026 03:40:11 -0800 (PST) Received: from localhost ([209.132.188.88]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-819c59df961sm4792767b3a.47.2026.01.07.03.40.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Jan 2026 03:40:10 -0800 (PST) Date: Wed, 7 Jan 2026 19:39:24 +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> 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: 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 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. -- Best regards, Coiby