The syntax "disable X instead of doing Y" seems confusing to me.

Also, why would we not want to just read both sources of entropy by default?

Because random_harvestq_prime currently looks for just one loaded file and I don't really want to modify that code.

I don't think this should be enabled by default if it replaces the other, more trustworthy source. Early seeding is sensitive and nothing I've seen about EFI or BIOSes suggests that we should trust some implementation of the EFI RNG protocol as entropy.

I took a look at the EDK2 implementation, and for x86 it uses RDRAND, while for aarch64 it uses the machine specific functionality, such as TRNG on Marvell Aramada devices.

I agree with cem and delphij -- EFI implementations do not have enough of a reputation for correctness that I would want to trust our security to their ability to implement an RNG. It would not be the first time that a RNG produced non-random numbers.

Is there a reason why we can't just fix this and support multiple entropy files?

I agree with cem and delphij -- EFI implementations do not have enough of a reputation for correctness that I would want to trust our security to their ability to implement an RNG. It would not be the first time that a RNG produced non-random numbers.

Agreed, but this "just" means we shouldn't rely on EFI entropy alone. It's OK to use it *in addition*.

No reason, in my opinion. Just A Small Matter of Coding™.

Linux now unconditionally uses this interface on x86 (been using it on arm64 for a while):

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0d95981438c3bdb53cc99b0fb656d24d7a80e1f3

They seem to have a build time flag CONFIG_RANDOM_TRUST_BOOTLOADER that decides whether to *count* this towards their entropy count (but it's *used* either way)

oh, actually it is small. I thought it was hard at first, but looking more closely, there's 2 possible solutions:

• turn random_prime_loader_file into random_prime_loader_files, looping over all modules (found an example of that in the codebase already) — funnily enough would make its comment more true, as it already says "loader-loaded files" plural
• add another type next to RANDOM_CACHED_BOOT_ENTROPY_MODULE ("boot_entropy_cache"), call it "platform" instead of "cache" I guess, and just random_prime_loader_file again with that type
  • this would allow more accurate bootverbose messages (not "read %zu bytes from preloaded cache" anymore)
  • and potentially treating it as a different RANDOM_ kind than CACHED in the future if there's ever a reason to

I think I'll go with the second one, as it is more semantically correct in some ways.

This file needs a copyright / license at the top.

Which copyright should it be? Most of these interface definitions seem to have Intel…

hm, can I call core.isUEFIBoot() here? just requiring core in config.lua should be fine, right?

I believe so for the first part, and definitely for the second part.

No, we can't do circular dependencies like that. IMO we should probably split some core stuff out into a system.lua (e.g. isI386, isUEFIBoot) with no dependencies.

Which copyright should it be? Most of these interface definitions seem to have Intel…

BSD 2-clause here, maybe. Assign to BSD Foundation if you don't want it for yourself?

IIRC, there is a problem with copyright-less files, as lawyers get touchy about this in large corporations.

If it falls through to the top-level copyright, then I guess it's OK.

I think we want both of these to be called only in the same block just above with loadelf(); if the kernel is loaded already, we specifically avoid trying to load anything else in case the user deliberately avoided it. e.g., disaster scenario and for some reason kernel-side of processing this entropy is hosing us, we give the user an easy path out.