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

[Sourabh Jain <sourabhjain@linux.ibm.com>]

On 06/08/26 11:50, Coiby Xu wrote:
> 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.

Thanks for the clarification. So, the kexec segment retains the deleted key
information until the kdump kernel is reloaded.

>>
>> 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;
>
> [...] 

Thanks for the pointer I will explore this.

- Sourabh Jain