Page MenuHomeFreeBSD

stand: Don't verify entropy cache file.
AbandonedPublic

Authored by mindal_semihalf.com on Apr 19 2019, 9:40 AM.

Details

Summary

When loader is build with secure boot every kernel module loaded during boot has to be signed.
We can't really verify the integrity of /boot/entropy, since it changes every time we boot.
Disable verification if the module we are about to load has "boot_entropy_cache", or "/boot/entropy" type.

Diff Detail

Repository
rS FreeBSD src repository
Lint
Lint Skipped
Unit
Unit Tests Skipped

Event Timeline

imp added a comment.Apr 19 2019, 8:33 PM

one minor style nit and we're good to go.

stand/common/module.c
475

I'd prefer we use the != 0 on strcmp here rather than have it implicit.

sjg added a comment.Apr 20 2019, 7:17 PM

Would it be worth adding a means of explicitly marking a file in manifest as not to be verified?

imp added a comment.Apr 20 2019, 10:29 PM
In D19962#429625, @sjg wrote:

Would it be worth adding a means of explicitly marking a file in manifest as not to be verified?

I'm torn.

On the one hand, I'd prefer the manifest control things, including "don't check this file". This meets the security design mantra of always be explicit.

On the other hand, I like the simplicity of this implementation because there's not many files like this and so far this is the only known exemplar. This meets the KISS principle when doing security design.

sjg added a comment.Apr 20 2019, 11:25 PM

I sent mindal a diff earlier, in our manifest source files we have a no_hash token to indicate files which should not be verified.
The change I'm thinking of simply exposes that to loader
sbin/veriexec which feeds hashes to kernel skips files which have no hash/fingerprint,
this is fine for the kernel since if it doesn't verify something the kernel itself doesn't care.
The loader implementation is quite different though, and explicit indication of "do not verify" is potentially useful.
Of course most of the files that might apply to are *.conf and *.hints files which I dealt with implicitly.

In my opinion @sjg approach is better as it is more versatile. If no one opposes I'll abandon this review in a day or two.

Abandoned in favor of D20018.