On Wed, May 06, 2020 at 10:50:04PM -0700, Prakhar Srivastava wrote:Thankyou for clarifying my misunderstanding, i am modelling this keeping to the TPM log implementation that uses a reserved memory. I will rev up the version with chosen-node support.
Hi Mark,
Please don't top post.
This patch set currently only address the Pure DT implementation.
EFI and ACPI implementations will be posted in subsequent patchsets.
The logs are intended to be carried over the kexec and once read the
logs are no longer needed and in prior conversation with James(
https://lore.kernel.org/linux-arm-kernel/0053eb68-0905-4679-c97a-00c5cb6f1abb@xxxxxxx/)
the apporach of using a chosen node doesn't
support the case.
The DT entries make the reservation permanent and thus doesnt need kernel
segments to be used for this, however using a chosen-node with
reserved memory only changes the node information but memory still is
reserved via reserved-memory section.
I think Mark's point was whether it needs to be permanent. We don't
hardcode the initrd address for example.
maliciously altered, both remotely and locally, it can also be usedOn 5/5/20 2:59 AM, Mark Rutland wrote:
Hi Prakhar,
On Mon, May 04, 2020 at 01:38:27PM -0700, Prakhar Srivastava wrote:
IMA during kexec(kexec file load) verifies the kernel signature and measures
What's IMAIMA is a LSM attempting to detect if files have been accidentally or
the signature of the kernel. The signature in the logs can be used to verfiy the
authenticity of the kernel. The logs don not get carried over kexec and thus
remote attesation cannot verify the signature of the running kernel.
Introduce an ABI to carry forward the ima logs over kexec.
Memory reserved via device tree reservation can be used to store and read
via the of_* functions.
This flow needs to work for:
1) Pure DT
2) DT + EFI memory map
3) ACPI + EFI memory map
... and if this is just for transiently passing the log, I don't think
that a reserved memory region is the right thing to use, since they're
supposed to be more permanent.
This sounds analogous to passing the initrd, and should probably use
properties under the chosen node (which can be used for all three boot
flows above).
For reference, how big is the IMA log likely to be? Does it need
physically contiguous space?
It purely depends on the policy used and the modules/files that are accessed
for my local testing over a kexec session the log in
about 30KB.
Current implementation expects enough contiguous memory to allocated to
carry forward the logs. If the log size exceeds the reserved memory the
call will fail.
Thanks,
Prakhar Srivastava
Thanks,
Mark.
Reserved memory stores the size(sizeof(size_t)) of the buffer in the starting
address, followed by the IMA log contents.
Tested on:
arm64 with Uboot
Prakhar Srivastava (2):
Add a layer of abstraction to use the memory reserved by device tree
for ima buffer pass.
Add support for ima buffer pass using reserved memory for arm64 kexec.
Update the arch sepcific code path in kexec file load to store the
ima buffer in the reserved memory. The same reserved memory is read
on kexec or cold boot.
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/ima.h | 22 ++++
arch/arm64/include/asm/kexec.h | 5 +
arch/arm64/kernel/Makefile | 1 +
arch/arm64/kernel/ima_kexec.c | 64 ++++++++++
arch/arm64/kernel/machine_kexec_file.c | 1 +
arch/powerpc/include/asm/ima.h | 3 +-
arch/powerpc/kexec/ima.c | 14 ++-
drivers/of/Kconfig | 6 +
drivers/of/Makefile | 1 +
drivers/of/of_ima.c | 165 +++++++++++++++++++++++++
include/linux/of.h | 34 +++++
security/integrity/ima/ima_kexec.c | 15 ++-
13 files changed, 325 insertions(+), 7 deletions(-)
create mode 100644 arch/arm64/include/asm/ima.h
create mode 100644 arch/arm64/kernel/ima_kexec.c
create mode 100644 drivers/of/of_ima.c
--
2.25.1