Message-ID: <YshObzBwiUoyJ3oP@noodles-fedora.dhcp.thefacebook.com>
Date:   Fri, 8 Jul 2022 15:34:12 +0000
From:   Jonathan McDowell <noodles@...com>
To:     Mimi Zohar <zohar@...ux.ibm.com>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        "linux-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>,
        "linux-security-module@...r.kernel.org" 
        <linux-security-module@...r.kernel.org>,
        "kexec@...ts.infradead.org" <kexec@...ts.infradead.org>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Dmitry Kasatkin <dmitry.kasatkin@...il.com>,
        James Morris <jmorris@...ei.org>,
        "Serge E. Hallyn" <serge@...lyn.com>,
        Matthew Garrett <mjg59@...f.ucam.org>,
        Dmitrii Potoskuev <dpotoskuev@...com>,
        Roberto Sassu <roberto.sassu@...wei.com>,
        Eugeniu Rosca <erosca@...adit-jv.com>
Subject: Re: [RFC PATCH 0/7] ima: Support measurement of kexec initramfs
 components

On Fri, Jul 08, 2022 at 07:49:58AM -0400, Mimi Zohar wrote:
> 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.

Yes, I'm aware of the FIRMWARE_CHECK hooks. This is more accurately
early stage firmware e.g. CPU microcode and it's not that we're
expecting this to load over a kexec but instead that the kernel /
initramfs loaded via kexec are what is also used for a traditional disk
boot, the kexec is just being used to shorten restart time. So although
the firmware isn't actually loaded it's part of the image and we'd like
to be able to keep the measurements for the parts separate.

> - 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@...wei.com>

That looks interesting, and obviously has some overlap in the areas I'm
touching, but I don't think it gives me the information I want from a
measurement perspective. The desire is that we can build a suitable
initramfs from a set of component building blocks, rather than a custom
image for each machine, and that we can measure the blocks rather than
the final result so that we just store the hash for each building block.
I think xattrs start to be more interesting when we extend to use some
sort of signing or fs-verity approach (which is in progress), but we'll
still want the measurement piece so we understand exactly what it is we
used to get to the current point in time.

J.

Powered by blists - more mailing lists