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

Reply via email to