From: Jonathan McDowell <noodles@fb.com> To: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>, "linux-integrity@vger.kernel.org" <linux-integrity@vger.kernel.org>, "linux-security-module@vger.kernel.org" <linux-security-module@vger.kernel.org>, "kexec@lists.infradead.org" <kexec@lists.infradead.org> Cc: Alexander Viro <viro@zeniv.linux.org.uk>, Mimi Zohar <zohar@linux.ibm.com>, Dmitry Kasatkin <dmitry.kasatkin@gmail.com>, James Morris <jmorris@namei.org>, "Serge E. Hallyn" <serge@hallyn.com>, Matthew Garrett <mjg59@srcf.ucam.org>, Dmitrii Potoskuev <dpotoskuev@fb.com> Subject: [RFC PATCH 0/7] ima: Support measurement of kexec initramfs components Date: Fri, 8 Jul 2022 10:10:31 +0000 [thread overview] Message-ID: <cover.1657272362.git.noodles@fb.com> (raw) 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. 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 | 91 +++++ include/linux/fs.h | 4 + include/linux/init_syscalls.h | 6 - init/initramfs.c | 522 +++---------------------- lib/Kconfig | 3 + lib/Makefile | 2 +- lib/cpio.c | 607 ++++++++++++++++++++++++++++++ lib/decompress.c | 4 +- lib/decompress_inflate.c | 4 + security/integrity/ima/Kconfig | 16 + security/integrity/ima/ima_main.c | 191 +++++++++- 13 files changed, 961 insertions(+), 594 deletions(-) create mode 100644 include/linux/cpio.h create mode 100644 lib/cpio.c -- 2.36.1
WARNING: multiple messages have this Message-ID (diff)
From: Jonathan McDowell <noodles@fb.com> To: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>, "linux-integrity@vger.kernel.org" <linux-integrity@vger.kernel.org>, "linux-security-module@vger.kernel.org" <linux-security-module@vger.kernel.org>, "kexec@lists.infradead.org" <kexec@lists.infradead.org> Cc: Alexander Viro <viro@zeniv.linux.org.uk>, Mimi Zohar <zohar@linux.ibm.com>, Dmitry Kasatkin <dmitry.kasatkin@gmail.com>, James Morris <jmorris@namei.org>, "Serge E. Hallyn" <serge@hallyn.com>, Matthew Garrett <mjg59@srcf.ucam.org>, Dmitrii Potoskuev <dpotoskuev@fb.com> Subject: [RFC PATCH 0/7] ima: Support measurement of kexec initramfs components Date: Fri, 8 Jul 2022 10:10:31 +0000 [thread overview] Message-ID: <cover.1657272362.git.noodles@fb.com> (raw) 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. 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 | 91 +++++ include/linux/fs.h | 4 + include/linux/init_syscalls.h | 6 - init/initramfs.c | 522 +++---------------------- lib/Kconfig | 3 + lib/Makefile | 2 +- lib/cpio.c | 607 ++++++++++++++++++++++++++++++ lib/decompress.c | 4 +- lib/decompress_inflate.c | 4 + security/integrity/ima/Kconfig | 16 + security/integrity/ima/ima_main.c | 191 +++++++++- 13 files changed, 961 insertions(+), 594 deletions(-) create mode 100644 include/linux/cpio.h create mode 100644 lib/cpio.c -- 2.36.1 _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
next reply other threads:[~2022-07-08 10:10 UTC|newest] Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-07-08 10:10 Jonathan McDowell [this message] 2022-07-08 10:10 ` [RFC PATCH 0/7] ima: Support measurement of kexec initramfs components Jonathan McDowell 2022-07-08 10:11 ` [RFC PATCH 1/7] initramfs: Move cpio handling routines into lib/ Jonathan McDowell 2022-07-08 10:11 ` Jonathan McDowell 2022-07-08 10:11 ` [RFC PATCH 2/7] lib/cpio: Improve error handling Jonathan McDowell 2022-07-08 10:11 ` Jonathan McDowell 2022-07-08 10:12 ` [RFC PATCH 3/7] lib/cpio: use non __init filesystem related functions Jonathan McDowell 2022-07-08 10:12 ` Jonathan McDowell 2022-07-11 8:38 ` [lib/cpio] 0e4846b4e7: Initramfs_unpacking_failed kernel test robot 2022-07-11 8:38 ` kernel test robot 2022-07-11 8:38 ` kernel test robot 2022-07-08 10:12 ` [RFC PATCH 4/7] lib/cpio: Allow use outside of initramfs creation Jonathan McDowell 2022-07-08 10:12 ` Jonathan McDowell 2022-07-08 10:12 ` [RFC PATCH 5/7] lib/cpio: Add a parse-only option that doesn't extract any files Jonathan McDowell 2022-07-08 10:12 ` Jonathan McDowell 2022-07-08 10:12 ` [RFC PATCH 6/7] HACK: Allow the use of generic decompress with gzip outside __init Jonathan McDowell 2022-07-08 10:12 ` Jonathan McDowell 2022-07-08 10:12 ` [RFC PATCH 7/7] ima: Support measurement of kexec initramfs components Jonathan McDowell 2022-07-08 10:12 ` Jonathan McDowell 2022-07-08 11:49 ` [RFC PATCH 0/7] " Mimi Zohar 2022-07-08 11:49 ` Mimi Zohar 2022-07-08 15:34 ` Jonathan McDowell 2022-07-08 15:34 ` Jonathan McDowell 2022-07-28 14:08 ` [RFC PATCH v2 " Jonathan McDowell 2022-07-28 14:09 ` [RFC PATCH v2 1/7] initramfs: Move cpio handling routines into lib/ Jonathan McDowell 2022-07-28 14:09 ` [RFC PATCH v2 2/7] lib/cpio: Improve error handling Jonathan McDowell 2022-07-28 14:09 ` [RFC PATCH v2 3/7] lib/cpio: use non __init filesystem related functions Jonathan McDowell 2022-07-28 14:09 ` [RFC PATCH v2 4/7] lib/cpio: Allow use outside of initramfs creation Jonathan McDowell 2022-07-28 14:09 ` [RFC PATCH v2 5/7] lib/cpio: Add a parse-only option that doesn't extract any files Jonathan McDowell 2022-07-28 14:09 ` [RFC PATCH v2 6/7] HACK: Allow the use of generic decompress with gzip outside __init Jonathan McDowell 2022-07-28 14:09 ` [RFC PATCH v2 7/7] ima: Support measurement of kexec initramfs components Jonathan McDowell
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=cover.1657272362.git.noodles@fb.com \ --to=noodles@fb.com \ --cc=dmitry.kasatkin@gmail.com \ --cc=dpotoskuev@fb.com \ --cc=jmorris@namei.org \ --cc=kexec@lists.infradead.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-integrity@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=mjg59@srcf.ucam.org \ --cc=serge@hallyn.com \ --cc=viro@zeniv.linux.org.uk \ --cc=zohar@linux.ibm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.