[Cc: Roberto Sassu, linux-integrity]
On Tue, 2025-12-02 at 08:16 +0100, Ard Biesheuvel wrote:
On Mon, 1 Dec 2025 at 22:43, Mimi Zohar zohar@linux.ibm.com wrote:
On Mon, 2025-12-01 at 15:03 +0530, Harshit Mogalapalli wrote:
Hi all,
On 13/11/25 01:00, Harshit Mogalapalli wrote:
When the second-stage kernel is booted via kexec with a limiting command line such as "mem=<size>", the physical range that contains the carried over IMA measurement list may fall outside the truncated RAM leading to a kernel panic.
BUG: unable to handle page fault for address: ffff97793ff47000 RIP: ima_restore_measurement_list+0xdc/0x45a #PF: error_code(0x0000) – not-present pageOther architectures already validate the range with page_is_ram(), as done in commit: cbf9c4b9617b ("of: check previous kernel's ima-kexec-buffer against memory bounds") do a similar check on x86.
It should be obvious that without carrying the measurement list across kexec, that attestation will fail. Please mention it here in the patch description.
Couldn't we just use memremap() and be done with it? That will use the direct map if the memory is mapped, or vmap() it otherwise.
No, the IMA measurement list is not a continuous buffer, but a linked list of records with varying types of fields and field sizes. The call to ima_dump_measurement_list() marshals the measurement list into a buffer, while ima_restore_measurement_list() unmarshals it.