Re: [PATCH V4 0/2] Add support for arm64 to carry ima measurement

On Fri, 2019-10-25 at 18:07 +0100, James Morse wrote:

Hi Mimi,

On 16/10/2019 02:44, Mimi Zohar wrote:

quoted

On Tue, 2019-10-15 at 18:39 +0100, James Morse wrote:

quoted

If SecureBoot isn't relevant, I'm confused as to why kexec_file_load() is.

I thought kexec_file_load() only existed because SecureBoot systems need to validate the
new OS images's signature before loading it, and we can't trust user-space calling Kexec
to do this.

If there is no secure boot, why does this thing only work with kexec_file_load()?
(good news! With the UEFI memreseve table, it should work transparently with regular kexec
too)

quoted

I'm so sorry for the confusion.  IMA was originally limited to
extending trusted boot concepts to the OS.  As of Linux 3.10, IMA
added support for extending secure boot concepts and auditing file
hashes (commit e7c568e0fd0cf).

True, kexec_file_load is required for verifying the kexec kernel
image, but it is also required for measuring the kexec kernel image as
well.

After reading the kernel image into memory (kernel_read_file_from_fd),
the hash is calculated and then added to the IMA measurement list and
used to extend the TPM.  All of this is based on the IMA policy,
including the TPM PCR.

Don't we get a set of segments with the regular kexec syscall? These could equally be
hashed and measured, and logged via IMA and/or extending the TPMs measurements.

IMA works at the file level.  I'm not sure what it would mean to
measure "segments".

Originally, kexec_file_load read the KEXEC kernel image twice, once to
calculate the file hash, and again to verify the signature.  Now
kexec_file_load calls kernel_read_file_from_fd, which reads the file
into memory, before IMA calculates the file buffer hash.

(obviously this would include the command-line and maybe purgatory, which makes it less
predictable, but these are still the binary blobs that were given privileged access to the
system).

quoted

quoted

quoted

I am not sure if i addressed all your concerns, please let me know
if i missed anything. To me most concerns look to be towards the kexec case and dependency
on hardware(ACPI/TPM) during boot and early boot services, where as carrying the logs is
only during the kexec_file_load sys call and does not interfere with that code path.
IMA documentation: https://sourceforge.net/p/linux-ima/wiki/Home/

Supporting ACPI in the same way is something we need to do from day one. kexec_file_load()
already does this. I'm not sure "only kexec_file_load()" is a justifiable restriction...

quoted

The TPM PCRs are not reset on a soft reboot.  As a result, in order to
validate the IMA measurement list against the TPM PCRs, the IMA
measurement list is saved on kexec load, restored on boot, and then
the memory allocated for carrying the measurement list across kexec is
freed.

Hmm, this is why the reserved memory gets freed.

Yes

What happens to stuff that happens between kexec-load and boot?
There is a comment:
| /* segment size can't change between kexec load and execute */

Right, the original version addressed this, but was nixed by Eric,
saying it was unnecessary.  The current version allocates more memory
than needed to hopefully compensate. 

But I can't see anywhere that enforces that. I guess those measurements will go missing,
and the TPM value will not match after kexec.

No, the kexec load will succeed, but if there isn't enough memory to
store the measurement list, the exec should fail.

Mimi


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel