Re: [PATCH v3 04/10] crash_dump: Read the number of dm-crypt keys from reserved memory

[Coiby Xu]

On Wed, Aug 05, 2026 at 04:35:50PM +0530, Sourabh Jain wrote:
> Hi Coiby,

Hi Sourabh,

> On 29/07/26 09:06, Coiby Xu wrote:
> > In case user adds/deletes the keys by mistake, it's safer to read the
> > number of keys from reserved memory.
>
> I am not sure how we differentiate between a key being deleted 
> accidentally and a user
> intentionally deleting it. However, I have a question about how the 
> kernel handles key
> addition and removal.
>
> How does the kernel handle key add/remove operations to keep the kexec 
> segment
> corresponding to the key header up to date?
>
> The reason I am asking is to understand what happens when a user 
> deletes a key. Does the
> kexec segment corresponding to that key header still retain 
> information about the deleted key?
>
> If it does, could you explain why? If it does not, could you explain 
> how the kexec segment gets updated?

Thanks for the questions! When a user delete a key by removing a
configfs item, the kexec segment still retain information about the
deleted key. The kexec segment will only be updated when the user tries
to reload the kdump kernel. Because I think introducing a sync mechanism to
automatically update the kexec segment when there is a change to
configfs is unnecessary. 

> Also, for my understanding, could you please point me to what exactly 
> is stored in the key header's kexec
> segment? During restore, kernel access the old kernel memory using the 
> information stored in that kexec
> segment, so I would like to better understand what data it contains.

What is stored can be known from struct keys_header and dm_crypt_key,

struct dm_crypt_key {
	unsigned int key_size;
	char key_desc[KEY_DESC_MAX_LEN];
	u8 data[KEY_SIZE_MAX];
};

struct keys_header {
	unsigned int total_keys;
	struct dm_crypt_key keys[] __counted_by(total_keys);
} *keys_header;

[...]


--
Best regards,
Coiby