Message-ID: <cover.1659003817.git.noodles@fb.com>
Date:   Thu, 28 Jul 2022 14:08:53 +0000
From:   Jonathan McDowell <noodles@...com>
To:     "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>
CC:     Alexander Viro <viro@...iv.linux.org.uk>,
        Mimi Zohar <zohar@...ux.ibm.com>,
        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>
Subject: [RFC PATCH v2 0/7] ima: Support measurement of kexec initramfs
 components

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. I've not had a lot of feedback from v1 but the
kernel test robot threw up a couple of compile failures and a boot
failure so this is a revised patch set with those fixed.

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.

v2:

Fix printf format string in populate_initrd_image (kernel test robot, i386 build)
Include <linux/limits.h> in cpio.h (kernel test robot, uml build)
Fix EEXIST checking for device nodes (kernel test robot, boot attempt)


Jonathan McDowell (7):
  initramfs: Move cpio handling routines into lib/
  lib/cpio: Improve error handling
  lib/cpio: use non __init filesystem related functions
  lib/cpio: Allow use outside of initramfs creation
  lib/cpio: Add a parse-only option that doesn't extract any files
  HACK: Allow the use of generic decompress with gzip outside __init
  ima: Support measurement of kexec initramfs components

 fs/init.c                         | 101 -----
 fs/internal.h                     |   4 -
 include/linux/cpio.h              |  92 +++++
 include/linux/fs.h                |   4 +
 include/linux/init_syscalls.h     |   6 -
 init/initramfs.c                  | 524 +++----------------------
 lib/Kconfig                       |   3 +
 lib/Makefile                      |   2 +-
 lib/cpio.c                        | 609 ++++++++++++++++++++++++++++++
 lib/decompress.c                  |   4 +-
 lib/decompress_inflate.c          |   4 +
 security/integrity/ima/Kconfig    |  16 +
 security/integrity/ima/ima_main.c | 191 +++++++++-
 13 files changed, 965 insertions(+), 595 deletions(-)
 create mode 100644 include/linux/cpio.h
 create mode 100644 lib/cpio.c

-- 
2.30.2

Powered by blists - more mailing lists