Re: [RFC PATCH 0/7] ima: Support measurement of kexec initramfs components

[Mimi Zohar]

On Fri, 2022-07-08 at 10:10 +0000, Jonathan McDowell wrote:
> This patchset is not yet complete, but it's already moving around a
> bunch of stuff so I am sending it out to get either some agreement that
> it's a vaguely sane approach, or some pointers about how I should be
> doing this instead.
> 
> It aims to add an option to IMA to measure the individual components
> that make up an initramfs that is being used for kexec, rather than the
> entire initramfs blob. For example in the situation where the initramfs
> blob contains some uncompressed early firmware and then a compressed
> filesystem there will be 2 measurements folded into the TPM, and logged
> into the IMA log.
> 
> Why is this useful? Consider the situation where images have been split
> out to a set of firmware, an initial userspace image that does the usual
> piece of finding the right root device and switching into it, and an
> image that contains the necessary kernel modules.
> 
> For a given machine the firmware + userspace images are unlikely to
> change often, while the kernel modules change with each upgrade. If we
> measure the concatenated image as a single blob then it is necessary to
> calculate all the permutations of images that result, which means
> building and hashing the combinations. By measuring each piece
> individually a hash can be calculated for each component up front
> allowing for easier analysis of whether the running state is an expected
> one.
> 
> The KEXEC_FILE_LOAD syscall only allows a single initramfs image to be
> passed in; one option would be to add a new syscall that supports
> multiple initramfs fds and read each in kimage_file_prepare_segments().
> 
> Instead I've taken a more complicated approach that doesn't involve a
> new syscall or altering the kexec userspace, building on top of the way
> the boot process parses the initramfs and using that same technique
> within the IMA measurement for the READING_KEXEC_INITRAMFS path.
> 
> To that end I've pulled the cpio handling code out of init/initramfs.c
> and into lib/ and made it usable outside of __init when required. That's
> involved having to pull some of the init_syscall file handling routines
> into the cpio code (and cleaning them up when the cpio code is the only
> user). I think there's the potential for a bit more code clean up here,
> but I've tried to keep it limited to providing the functionality I need
> and making checkpatch happy for the moment.
> 
> Patch 1 pulls the code out to lib/ and moves the global static variables
> that hold the state into a single context structure.
> 
> Patch 2 does some minimal error path improvements so we're not just
> passing a string around to indicate there's been an error.
> 
> Patch 3 is where I pull the file handling routines into the cpio code.
> It didn't seem worth moving this to somewhere other code could continue
> to use them when only the cpio code was doing so, but it did involve a
> few extra exported functions from fs/
> 
> Patch 4 actually allows the use of the cpio code outside of __init when
> CONFIG_CPIO is selected.
> 
> Patch 5 is a hack so I can use the generic decompress + gzip outside of
> __init. If this overall approach is acceptable then I'll do some work to
> make this generically available in the same manner as the cpio code
> before actually submitting for inclusion.
> 
> Patch 6 is the actual piece I'm interested in; doing individual
> measurements for each component within IMA.

Hi Jonathan,

Before going down this path, just making sure you're aware:
- of the IMA hooks for measuring and appraising firmware.

- of Roberto Sassu's "initramfs: add support for xattrs in the initial
ram disk" patch set that have been lingering for lack of review and
upstreaming.[1]   There's been some recent interest in it.

[1] Message-Id: <21b3aeab20554a30b9796b82cc58e55b@xxxxxxxxxx>

thanks,

Mimi