| Message ID | 20200717174309.1164575-1-keescook@chromium.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | Introduce partial kernel_read_file() support | expand |
Hi Kees, Thanks for sending out. This looks different than your other patch series. We should get the first 5 patches accepted now though as they are simple cleanups and fixes. That will reduce the number of outstanding patches in the series. At first glance the issue with the changes after that is the existing API assumes it has read the whole file and failed if it did not. Now, if the file is larger than the amount requested there is no indication? On 2020-07-17 10:42 a.m., Kees Cook wrote: > Hi, > > Here's my attempt at clearing the path to partial read support in > kernel_read_file(), which fixes a number of issues along the way. I'm > still fighting with the firmware test suite (it doesn't seem to pass > for me even in stock v5.7... ?) But I don't want to block Scott's work[1] > any this week, so here's the series as it is currently. > > The primary difference to Scott's approach is to avoid adding a new set of > functions and just adapt the existing APIs to deal with "offset". Also, > the fixes for the enum are first in the series so they can be backported > without the header file relocation. > > I'll keep poking at the firmware tests... > > -Kees > > [1] https://lore.kernel.org/lkml/202007161415.10D015477@keescook/ > > Kees Cook (12): > firmware_loader: EFI firmware loader must handle pre-allocated buffer > fs/kernel_read_file: Remove FIRMWARE_PREALLOC_BUFFER enum > fs/kernel_read_file: Remove FIRMWARE_EFI_EMBEDDED enum > fs/kernel_read_file: Split into separate source file > fs/kernel_read_file: Remove redundant size argument > fs/kernel_read_file: Switch buffer size arg to size_t > fs/kernel_read_file: Add file_size output argument > LSM: Introduce kernel_post_load_data() hook > firmware_loader: Use security_post_load_data() > module: Call security_kernel_post_load_data() > LSM: Add "contents" flag to kernel_read_file hook > fs/kernel_file_read: Add "offset" arg for partial reads > > Scott Branden (1): > fs/kernel_read_file: Split into separate include file > > drivers/base/firmware_loader/fallback.c | 8 +- > .../base/firmware_loader/fallback_platform.c | 12 +- > drivers/base/firmware_loader/main.c | 13 +- > fs/Makefile | 3 +- > fs/exec.c | 132 +----------- > fs/kernel_read_file.c | 189 ++++++++++++++++++ > include/linux/fs.h | 39 ---- > include/linux/ima.h | 19 +- > include/linux/kernel_read_file.h | 55 +++++ > include/linux/lsm_hook_defs.h | 6 +- > include/linux/lsm_hooks.h | 12 ++ > include/linux/security.h | 19 +- > kernel/kexec.c | 2 +- > kernel/kexec_file.c | 18 +- > kernel/module.c | 24 ++- > security/integrity/digsig.c | 8 +- > security/integrity/ima/ima_fs.c | 9 +- > security/integrity/ima/ima_main.c | 58 ++++-- > security/integrity/ima/ima_policy.c | 1 + > security/loadpin/loadpin.c | 17 +- > security/security.c | 26 ++- > security/selinux/hooks.c | 8 +- > 22 files changed, 432 insertions(+), 246 deletions(-) > create mode 100644 fs/kernel_read_file.c > create mode 100644 include/linux/kernel_read_file.h >
On Fri, Jul 17, 2020 at 12:17:02PM -0700, Scott Branden wrote: > Thanks for sending out. This looks different than your other patch series. Yes, it mutated in my head as I considered how all of this should hang together, which is why I wanted to get it sent before the weekend. I'm still trying to figure out why the fireware testsuite fails for me, etc. > We should get the first 5 patches accepted now though as they are > simple cleanups and fixes. That will reduce the number of outstanding > patches in the series. Agreed. I'd like to get some more eyes on it, but I can get it ready for -next. > At first glance the issue with the changes after that is the existing > API assumes it has read the whole file and failed if it did not. > Now, if the file is larger than the amount requested there is no indication? The intention is to have old API users unchanged and new users can use a pre-allocated buf (with buf_size) along with file_size to examine their partial read progress. If I broke the old API, that's a bug and I need to fix it, but that's why I wanted to start with the firmware test suite (basic things like module loading work fine after this series, but I wanted to really exercise the corners that the firmware suite pokes at).