On Wed, Jan 20, 2021 at 12:57:55PM +0100, Mickaël Salaün wrote: > > On 20/01/2021 06:19, Jarkko Sakkinen wrote: > > On Thu, Jan 14, 2021 at 04:19:07PM +0100, Mickaël Salaün wrote: > >> From: Mickaël Salaün <m...@linux.microsoft.com> > >> > >> Add and use a check-blacklist-hashes.awk script to make sure that the > >> builtin blacklist hashes will be approved by the run time blacklist > >> description checks. This is useful to debug invalid hash formats, and > >> it make sure that previous hashes which could have been loaded in the > >> kernel (but ignored) are now noticed and deal with by the user. > >> > >> Cc: David Howells <dhowe...@redhat.com> > >> Cc: David Woodhouse <dw...@infradead.org> > >> Signed-off-by: Mickaël Salaün <m...@linux.microsoft.com> > >> Acked-by: Jarkko Sakkinen <jar...@kernel.org> > > > > I get this with a self-signed cert: > > > > certs/Makefile:18: *** target pattern contains no '%'. Stop. > > > > CONFIG_SYSTEM_BLACKLIST_HASH_LIST="tbs:8eed1340eef37c1dc84d996406ad05c7dbb3eade19132d688408ca2f63904869" > > As said in the Kconfig documentation for > CONFIG_SYSTEM_BLACKLIST_HASH_LIST, you need to provide a file with the > list, not to set the string directly in the configuration variable. This > patch series didn't change this behavior. The same kind of macros are > used for CONFIG_MODULE_SIG_KEY.
OK, the documentation just states that: "Hashes to be preloaded into the system blacklist keyring" No mention about a file. I'd add a patch to update this documentation. > > > > > I used the script in 10/10 to test this, which is another > > reamark: the patches are in invalid order, as you need to > > apply 10/10 before you can test 8/10. > > I'll move patch 10/10 earlier but this kind of formatting was already > required (but silently ignored) for this option to be really taken into > account. Only the kernel code was available to understand how to > effectively create such hash. Great, thanks. > > > > /Jarkko > > /Jarkko