Re: [PATCH RFC 006/104] KEYS: trusted: eat -ENOENT from the crypto API

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 4 Sept 2025 at 13:05, Vegard Nossum <vegard.nossum@xxxxxxxxxx> wrote:
>
> However, since commit 9d50a25eeb05c ("crypto: testmgr - desupport SHA-1
> for FIPS 140") when booting with fips=1, the SHA-1 algorithm (or anything
> that uses it, like HMAC-SHA-1) will be unavailable.
>
> security/keys/trusted-keys/trusted_tpm1.c is hard-coded to use SHA-1 and
> will fail with -ENOENT when attempting to initialize the hash instance
> using the crypto API _if_ the hardware is available. This in turn causes
> the entire trusted.ko to fail to load.

Oh Christ.

Can we please just make that trusted_tpm1.c code use the sha1 library
code directly instead of going through the crypto layer to get it?
That would presumably neatly avoid the whole issue.

Eric - I haven't looked at how painful it is to just do conversions
like that - I assume it's a boilerplate thing and trivial to do if
you've one one. Please?

             Linus




[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux