On Tue, Feb 27, 2018 at 5:28 PM, Luis R. Rodriguez <mcgrof@xxxxxxxxxx> wrote: > On Tue, Feb 27, 2018 at 03:14:53PM -0800, Kees Cook wrote: >> On Fri, Feb 23, 2018 at 6:46 PM, Luis R. Rodriguez <mcgrof@xxxxxxxxxx> wrote: >> > The firmware fallback code is optional. Split that code out to help >> > distinguish the fallback functionlity from othere core firmware loader >> > features. This should make it easier to maintain and review code >> > changes. >> > >> > The reason for keeping the configuration onto a table which is built-in >> > if you enable firmware loading is so that we can later enable the kernel >> > after subsequent patches to tweak this configuration, even if the >> > firmware loader is modular. >> > >> > This introduces no functional changes. >> > >> > Signed-off-by: Luis R. Rodriguez <mcgrof@xxxxxxxxxx> >> > --- >> > drivers/base/Makefile | 4 +- >> > drivers/base/firmware_fallback.c | 661 +++++++++++++++++++++++++++ >> > drivers/base/firmware_fallback.h | 61 +++ >> > drivers/base/firmware_fallback_table.c | 29 ++ >> > drivers/base/firmware_loader.c | 803 +-------------------------------- >> > drivers/base/firmware_loader.h | 115 +++++ >> > 6 files changed, 874 insertions(+), 799 deletions(-) >> > create mode 100644 drivers/base/firmware_fallback.c >> > create mode 100644 drivers/base/firmware_fallback.h >> > create mode 100644 drivers/base/firmware_fallback_table.c >> > create mode 100644 drivers/base/firmware_loader.h >> >> Does it make sense to have a separate subdirectory for firmware >> instead? I did this _ stuff with lkdtm and have regretted it. (I'm >> likely going to make a subdirectory for it this cycle...) > > Sure, the only eyesore is that drivers/base/firmware.c what is that for? > > drivers/base/firmware_loader/ ok? Yeah? Seems fine to me. Greg, do you have thoughts on this? -Kees -- Kees Cook Pixel Security
