[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