On Thu, 2018-03-15 at 14:16 +0800, joeyli wrote: > 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. So this is for the *user* not the distribution? > 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. OK, so now the use case is the user needs to roll back but doesn't want a module to load ... I've got to say that in that case I'd just remove it before reload. > > 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. Ephemeral isn't about the signing process it means that the sum is short lived because every time you create a module for a specific kernel its sum changes (because of the interface versioning) so your blacklist only applies to one module and specific kernel combination. Once you compile it for a different kernel you need a different blacklist sum for it. James -- 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
