[PATCH v3 04/10] crash_dump: Read the number of dm-crypt keys from reserved memory
Sourabh Jain
sourabhjain at linux.ibm.com
Sun Aug 9 05:26:11 PDT 2026
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
More information about the kexec
mailing list