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

From: Mimi Zohar
Date: Fri Oct 25 2019 - 13:39:57 EST

On Fri, 2019-10-25 at 18:07 +0100, James Morse wrote:
> Hi Mimi,
> On 16/10/2019 02:44, Mimi Zohar wrote:
> > On Tue, 2019-10-15 at 18:39 +0100, James Morse wrote:
> >> 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)
> > 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).
> >>> 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:
> >>
> >> 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...
> > 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.

> 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.