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
