On Wed, Mar 14, 2018 at 07:19:25AM -0700, James Bottomley wrote: > On Wed, 2018-03-14 at 14:08 +0800, joeyli wrote: > > On Tue, Mar 13, 2018 at 10:18:35AM -0700, James Bottomley wrote: > > > > > > On Tue, 2018-03-13 at 18:38 +0800, Lee, Chun-Yi wrote: > > > > > > > > This patch adds the logic for checking the kernel module's hash > > > > base on blacklist. The hash must be generated by sha256 and > > > > enrolled > > > > to dbx/mokx. > > > > > > > > For example: > > > > sha256sum sample.ko > > > > mokutil --mokx --import-hash $HASH_RESULT > > > > > > > > Whether the signature on ko file is stripped or not, the hash can > > > > be > > > > compared by kernel. > > > > > > What's the use case for this? We're already in trouble from the > > > ODMs for the size of dbx and its consumption of the extremely > > > limited variable space, so do we really have a use case for adding > > > module blacklist hashes to the UEFI variables given the space > > > constraints (as in one we can't do any other way)? > > > > > > > The dbx is a authenticated variable that it can only be updated by > > manufacturer. The mokx gives a flexible way for distro to revoke a > > key or a signed module. Then we don't need to touch shim or bother > > manufacturer to deliver new db. Currently it doesn't have real use > > case yet. > > > > I knew that the NVRAM has limited space. But distro needs a backup > > solution for emergency. > > I wasn't asking why the variable, I was asking why the mechanism. > > OK, let me try to ask the question in a different way: > > Why would the distribution need to blacklist a module in this way? For This way is a new option for user to blacklist a module but not the only way. MOK has this ability because shim implements the mokx by signature database format (EFI_SIGNATURE_DATA in UEFI spec). This format supports both hash signature and x.509 certificate. > the distro to execute the script to add this blacklist, means the > system is getting automated or manual updates ... can't those updates > just remove the module? > Yes, we can just remove or update the module in kernel rpm or kmp. But user may re-install distro with old kernel or install a old kmp. If the blacklist hash was stored in variable, then kernel can prevent to load the module. On the other hand, for enrolling mokx, user must reboots system and deals with shim-mokmanager UI. It's more secure because user should really know what he does. And user can choice not to enroll the hash if they still want to use the module. > The point is that module sha sums are pretty ephemeral in our model > (they change with every kernel), so it seems to be a mismatch to place > them in a permanent blacklist, particularly when we have very limited > space for that list. > Normally we run a serious process for signing a kernel module before shipping it to customer. The SUSE's "Partner Linux Driver Program” (PLDP) is an example. So the module sha sums are not too ephemeral. I agree with you for the space is limit. But the mokx gives a option to distro or user to blacklist kernel module. They can choice to use this mechanism or not. Thanks a lot! Joey Lee -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
