* The RNG is not really strong. Help in this area would be greatly
appreciated.
This is tricky mostly because once you start probing for hardware
devices or even CPU features, you're going to find yourself wanting
more and more of the support you'd get from the "real kernel".
For example, to probe for RDRAND support on the CPU, you need a
whole pile of CPU feature decoding. To probe for environmental
sensors or an audio device you may need to know a whole pile about
ACPI and/or PCI. And so forth.
EFI has a RNG API, but I think it's usually just stubbed out and
besides, you can't rely on having EFI...
I think I'd suggest some combination of:
* Just enough CPU-feature support to find/use RDRAND
(Intel's sample code is not that big and I think it's
suitably-licensed)
* Hash the contents of the "CMOS RAM" and/or EFI boot variables
* Maybe poke around for an IPMI BMC (has environmental sensors),
or a TPM (has a RNG) on the LPC bus
* Maybe poke around for on-die temperature/voltage sensors
(will again require some CPU identification support).
* Rather than just using rdtsc once, consider using rdtsc to
"time" multiple hardware oscillators against one another;
at the very least, you've always got the hardware clock.
* Also, you can use rdtsc to time memory accesses.
For quick and dirty "entropy extraction", you can crunch as much of this
data as you're able to connect together using SHA512.