Have CRNG avail early on boot and maximize ligcrypt entropy sources/efficiency #1478
Conversation
|
No. Won't fly without rngd. Kernel doesn't aggregate multiple sources. Hopefully, rngd that depends on libgrypt we already use for gpg2 can be used and found resources stipulate that it could be as small as 18k when compiled with -Os. Let's see. |
|
rngd-tools have dependencies on libcap which hardcodes cross compilation assumptions under Makefile and Make.Rules... Not successful as of now. Can we remove libcap dependencies? Seems like another subproject. As in current state
We could probably trust libgcrypt + cpu extension here as a start. |
tlaurion
force-pushed
the
stenghten_entropy_sources_with_jitter_and_TPM
branch
from
ba265a1 to
94370b6
Compare
|
Ok so after having looked into this deeper:
I added sysctl fs in kernel for all boards. Enabled CPU HW for all boards. Qemu uses virtio of host. I have not digged into libgcrypt entropy sourcing, but I also think that it will be better then before. Would need testing here, but I think the PR is an improvement prior of before with next commits. Will clean after review. @JonathonHall-Purism Haven't touched librems outside of putting librem_l1um2 to oldconfig (linux.save_in_old_config would require a lot of review, you are activating a bunch of unneeded stuff right now). Let me know if you want me to enable comparative configs for librems in this PR. This is needed prior of in-memory key gen PR to be testable. |
|
By disabling
As on master otherwise with --disable-asm: |
|
Todo
|
tlaurion
changed the title
|
@saper @JonathonHall-Purism @daringer On second thoughts, i'm not even convinced that I mean as shown at #1478 (comment), with or without asm code to detect CPU enabled acceleration for different CPUs extensions (which speedups in memory keygen) I want to bring your attention there on the important fact: what we really wanted here, which is So my reasoning here is that by trusting the CPU for crng init (early boot entropy pool made ready for use), calling gnupg already takes advantage of jitter to not only use flimsy entropy as in master (the poolk was not ready) or now trusted HW provided RDRAND cpu extension enforced entropy (and also virtio under QEMU/KVM to simulate tests, which rely on host's entropy availability, AMD emulated CPU not recent enough to enable and use AMD HW CPU RDRAND there anyway). Note that we have the space to enable all of that. Question is if Thoughts? I think that in current state, this PR is a massive improvement where next steps would be to attack rng-tools inclusion (meaning libcap-ng inclusion) if we want to enable jitter in kernel + tpm hw entropy backend and have rng-tool feed /dev/random and /dev/urandom with proper entropy, mixing all of the above. But in my opinion, this is not needed here and now and can be enabled later on in future PR. This PR in current state fits the bill and improves current master's situation. Putting PR as ready for review. Will clean commits/squash prior of merging, I think those are important to see what was tested where and how for willing reviewers in its current state. |
|
Ok, after some challenging discussions with @JonathonHall-Purism : New facts:
Get homes messages:
So next commits will
|
|
Thanks for summing that up @tlaurion. For context, I did some quick checks on my 15v4 and it appeared that crng was already initialized before it was needed on that device from kernel sources, so there is no issue there. I suspect this is only an issue on qemu, but we need to confirm on other devices as well. We observed as you noted that cryptsetup uses the kernel random number generator; we need this to be a good source of entropy. While our sources of entropy at this point are limited, I would prefer not to trust RDRAND if we do not have to. It appears to me from initial tests that we are getting enough entropy from existing sources outside of qemu, so if there are some devices where we aren't getting that entropy soon enough, maybe there is another solution. For qemu I am totally fine with adding the necessary bits to get initial entropy from the host, including trust_cpu if needed.
Nitpick, --use-random does not affect cryptsetup's trust of kernel RNG, it trusts it either way. The difference is only that /dev/random will block before crng is ready, while /dev/urandom just returns low-entropy numbers immediately. It looks like cryptsetup in Heads is configured to use urandom by default (from cryptsetup --help). |
tlaurion
force-pushed
the
stenghten_entropy_sources_with_jitter_and_TPM
branch
from
d4134dc to
94dc35e
Compare
|
@JonathonHall-Purism forced push to only change qemu linux config. crng is ready within 5s and before entropy is expected to be ready and sued. No more error on qemu side. libgrcypt now enforces asm code and platforms specific cpu extensions are used where available, see commit log (same output as above for libgcrypt). Please review, this will be smaller steps and will extensively test this as base for forthcoming PRs. |
|
Bad news here. TRUST CPU was enabled for a while which is why crng was not complaining on crng for a lot of platforms on which that change was reverted under f59a63a @JonathonHall-Purism can you verify that builds for that commit (without trust on CPU) has a crng ready before tpm and shred calls? on x230 without TRUST CPU: We can see TPM and shred calls happening on empty pool prior of crng being ready. So I guess I will revert this for xx20/xx30 so that TRUST CPU is on and state it clearly on board configs? |
|
Letting the build finish prior of pushing more commit. The following needs to be added to fix mounting devpts over /dev/pts: |
|
Freezing this PR for the moment, continuing tests under https://github.com/tlaurion/heads/tree/stenghten_entropy_sources_with_jitter_and_TPM-withTrustCPU which trustcpu is enabled as in master because of 00e7156#diff-a890ddf36ae7dca110b70df101c97525a4d8265212ebed3f92562d47162af3a2R1472 but when disabled, sandy/ivy and probably other older architectures read entropy through an empty crng pool.... |
tlaurion
force-pushed
the
stenghten_entropy_sources_with_jitter_and_TPM
branch
from
a64ad39 to
0ad2b72
Compare
|
@tlaurion and I both researched this and discussed. In practice, TRUST_CPU essentially only controls whether the warning about the pool not being fully initialized is printed. Linux uses RDRAND/RDSEED either way, the only difference is whether it credits any entropy. With TRUST_CPU=n it uses them but credits no entropy, the assumption being that a bad entropy source could not be worse than not using it at all. Currently in Heads I feel that this warning has little value. It's currently caused by shred most of the time, and since we are operating on tmpfs, overwriting the data with any value is sufficient. Key generation occurs after plenty of I/O and user input and there appears to be sufficient entropy at that point regardless of TRUST_CPU. There is room for debate and improvement, but I think the status quo is improved just by enabling TRUST_CPU to remove a warning that isn't useful in this context. Some thoughts for future work (will open issues):
|
|
Ok. Further testing shows a big difference in CNRG readiness on booy, depending of if the board is HOTP/TOTP only. Testings shows that even on TOTP boards (non-HOTP), doing factory-reset or manual gpg operations on command line will have crng ready prior of important operations. It is also to be noted that errors given by shred call is benign, since those calls are wiping files in ramfs which blocks would be rewritten with not so random bytes, still overwiting secret intended to be wiped. The only warning i'm still worry-ish about is tpm calls when crng is not ready (staying in recovery shell without any IO or anything USB related): When going from menus to recovery shell and then doing factory-reset and grepping for random after ctrl-c after the output of provisioned secrets: |
|
@JonathonHall-Purism that was harder then I thought. Some notes:
As of now, this PR is a bit messy, adds cttyhack to call BOOTSCRIPT otherwise, dual console setups (qemu) was reporting to not have proper tty when tty is called. Thoughs on that welcome. Last changes add preoper DEBUG/TRACING output under dmesg and in console. Reason why those were intertwined by default under qemu is because coreboot config's kernel command line was passing "debug". To have this enabled to have Heads DEBUG/TRACE/die/warn messages intertwined under console output, dmesg -n 8 is needed. But detection of if CONSIF_DEBUT_OUTPUT is setuped either on board config or through config.user on-demand config requires changes under init and proper different output under init. All of this to permit to detect tpm call on qemu setup, which is the changes coming next if VIRTIO HW source is not enabled in kernel and have all rand calls from unready pool. To accomplish the same on real hw, the board config needs to enable DEBUG_CONSOLE_OUTPUT in board config otherwise early debug messages are not intertwined since the checks for DEBUG_CONSOLE_OUTPUT are not positive until combine_configs happens. All unneeded commits will be squashed, of course.... |
|
This is output of dmesg from dabdc58 for non-HOTP dmesg_no_hw_trust.txt |
tlaurion
force-pushed
the
stenghten_entropy_sources_with_jitter_and_TPM
branch
from
dabdc58 to
7a08474
Compare
|
@JonathonHall-Purism This is the output of 7a08474 for HOTP without HW entropy nor CPU trust |
|
This is the output of f50c296 with hw entropy, no CPU trust resealing TOTP/HOTP @JonathonHall-Purism The sealing still happens without pool being ready: |
|
@JonathonHall-Purism with adb5808 we add CPU trust to intel HW entropy source which gives this at totp+hotp sealing Of course this changes the output since really early simply because: |
|
@JonathonHall-Purism 9cdf085 adds libgcrypt benchmark app which is ~50k uncompressed but not really useful. I have not found an easy way of testing different libcrypt supported cpu optimizations as of now, which might be subject to further issues and PR. Let's remember that ofiginal issue is at #1476. From above comments, i'm not convinced still now of state of pool when tpm does stuff, but removing warning is best we can do as of now. @JonathonHall-Purism Can you review changes of librem configs? |
|
Basically, I think I will stage this pr and only keep in here
Opinion on cttyhack needed in init, can also be separated from here. And move the rest to other PRs.
|
tlaurion
force-pushed
the
stenghten_entropy_sources_with_jitter_and_TPM
branch
from
894c7da to
53ade6b
Compare
|
Squashing |
…CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER is not set, CONFIG_RANDOM_TRUST_CPU=y, CONFIG_PROC_SYSCTL is not set
As on master otherwise with --disable-asm:
config.status: executing gcrypt-conf commands
Libgcrypt v1.10.1 has been configured as follows:
Platform: GNU/Linux (x86_64-pc-linux-musl)
Hardware detection module: none
Enabled cipher algorithms: arcfour blowfish cast5 des aes twofish
serpent rfc2268 seed camellia idea salsa20
gost28147 chacha20 sm4
Enabled digest algorithms: crc gostr3411-94 md4 md5 rmd160 sha1
sha256 sha512 sha3 tiger whirlpool stribog
blake2 sm3
Enabled kdf algorithms: s2k pkdf2 scrypt
Enabled pubkey algorithms: dsa elgamal rsa ecc
Random number generator: default
Try using jitter entropy: yes
Using linux capabilities: no
FIPS module version:
Try using Padlock crypto: n/a
Try using AES-NI crypto: n/a
Try using Intel SHAEXT: n/a
Try using Intel PCLMUL: n/a
Try using Intel SSE4.1: n/a
Try using DRNG (RDRAND): n/a
Try using Intel AVX: n/a
Try using Intel AVX2: n/a
Try using ARM NEON: n/a
Try using ARMv8 crypto: n/a
Try using PPC crypto: n/a
By disabling --disable-asm in libgcrypt 1.10.1:
config.status: executing gcrypt-conf commands
Libgcrypt v1.10.1 has been configured as follows:
Platform: GNU/Linux (x86_64-pc-linux-musl)
Hardware detection module: libgcrypt_la-hwf-x86
Enabled cipher algorithms: arcfour blowfish cast5 des aes twofish
serpent rfc2268 seed camellia idea salsa20
gost28147 chacha20 sm4
Enabled digest algorithms: crc gostr3411-94 md4 md5 rmd160 sha1
sha256 sha512 sha3 tiger whirlpool stribog
blake2 sm3
Enabled kdf algorithms: s2k pkdf2 scrypt
Enabled pubkey algorithms: dsa elgamal rsa ecc
Random number generator: default
Enabled digest algorithms: crc gostr3411-94 md4 md5 rmd160 sha1
sha256 sha512 sha3 tiger whirlpool stribog
blake2 sm3
Enabled kdf algorithms: s2k pkdf2 scrypt
Enabled pubkey algorithms: dsa elgamal rsa ecc
Random number generator: default
Try using jitter entropy: yes
Using linux capabilities: no
FIPS module version:
Try using Padlock crypto: yes
Try using AES-NI crypto: yes
Try using Intel SHAEXT: yes
Try using Intel PCLMUL: yes
Try using Intel SSE4.1: yes
Try using DRNG (RDRAND): yes
Try using Intel AVX: yes
Try using Intel AVX2: yes
Try using ARM NEON: n/a
Try using ARMv8 crypto: n/a
Try using PPC crypto: n/a
To support PPC crypto, it seems we will need yasm.
To support linux capabilities, libcap would be required as well later on. :/ another point for rng-tools (which also depends on libcap-ng)
Enabling DEBUG/TRACE options from board config vs from configuration menu is different. When enabled in board config, /etc/config is from ROM, and sourced early and make TRACE/DEBUG calls appear early. If added through configuration menu, those are /etc/config.user overrides extracted from CBFS and then sourced after combine_configs call If for whatever reason early DEBUG is needed on a platform, enabling in board config is needed. For runtime debugging, enabling Debug output from configuration menu is enough
…sg when DEBUG is enabled
…d terminal. DEBUG/TRACE now output on /dev/kmsg and console.
tlaurion
force-pushed
the
stenghten_entropy_sources_with_jitter_and_TPM
branch
from
53ade6b to
9addb3b
Compare
| die() { | ||
| echo >&2 " !!! ERROR: $* !!!"; | ||
| if [ "$CONFIG_DEBUG_OUTPUT" = "y" ];then | ||
| echo " !!! ERROR: $* !!!" | tee -a /tmp/debug.log /dev/kmsg > /dev/null; | ||
| else | ||
| echo >&2 "!!! ERROR: $* !!!"; | ||
| fi | ||
| sleep 2; | ||
| exit 1; | ||
| } | ||
|
|
||
| warn() { | ||
| echo >&2 " *** WARNING: $* ***"; | ||
| if [ "$CONFIG_DEBUG_OUTPUT" = "y" ];then | ||
| echo " *** WARNING: $* ***" | tee -a /tmp/debug.log /dev/kmsg > /dev/null; | ||
| else | ||
| echo >&2 " *** WARNING: $* ***"; | ||
| fi | ||
| sleep 1; | ||
| } |
There was a problem hiding this comment.
I don't think it makes sense for die/warn to disappear from stderr when enabling CONFIG_DEBUG_OUTPUT. I wouldn't expect CONFIG_DEBUG_OUTPUT=y to produce less output in any context.
I think these are pretty reasonable to keep on stderr; I don't think they're too noisy. If they occur in the field I think these are better than nothing (and rarely a false warning). Based on that, I'd say continue printing to stderr regardless of CONFIG_DEBUG_OUTPUT, but I'm willing to consider any alternative 😁
There was a problem hiding this comment.
Nevermind, @tlaurion clarified to me that this is due to the interaction with enabling kernel messages to console (dmesg -n 8). If we do both, then these messages show up on the console twice, which is pointless.
| @@ -14,7 +14,6 @@ libgcrypt_configure := \ | |||
| --prefix "/" \ | |||
| --disable-static \ | |||
| --with-gpg-error-prefix="$(INSTALL)" \ | |||
| --disable-asm \ | |||
There was a problem hiding this comment.
Summarizing a discussion via DM - I'm good with this change.
And odd thing sticking out to me was that libgcrypt has code to use RDRAND directly for up to 25% of its entropy, which would have been prevented in the past with --disable-asm. That doesn't make much sense with the kernel already including RDSEED in its CRNG, and it doesn't even know about things like the broken Ryzen microcode, etc. But this code is no longer active by default, that code is for USE_RNDOLDLINUX, default is now USE_RNDGETENTROPY.
So no issues here, let's keep this change.
|
@tlaurion Thanks for clarifying both of those last discussions with me, let's merge 👍 🚢 |
This PR at time of merging:
Older traces of history:
So basically, next steps for future work are:
But as of now, simply trusting CPU is good enough and if not, shred and tpm calls made prior of crng being ready are also good, while not easthetic.
Note: 00e7156#diff-a890ddf36ae7dca110b70df101c97525a4d8265212ebed3f92562d47162af3a2 enabled trustcpu on most older boards.
Consequence as this PR goes through is that
Older:
This is PoC to fix #1476
Does rely on trust CPU. CPU RAND is first source to fill entropy pool early on boot. coreboot's linux command line turns it "on" explicitlyedit: not needed on qemu with virtio supported in kernel and qemu/kvm existing command line options reusing host's available entropy as source.Jitter is added into kernel configs, and coreboot's linux command line option sets basic values to configure jitterTpm is now turned off since not aggregated by kernel aloneTPM was already configured to be a source of randomness in kernel config, but weight was not adjusted in coreboot's kernel config to ponder properly. This is done nowJitter and TPM hardware source of entropy are now turned off since not aggregated by kernel alone.Tested in QEMU (TCG, not KVM, sloooooooow)
crng init=0 to readiness takes less then a second.with virtio, crng on qemu is ready under 6s, prior of first entropy pool access.Sandy bridge- (xx20: x20/t420/others) will continue to be slow to have crng ready at boot: RDRAND was added to ivy, not sandy: so xx20 Lenovo will rely on jitter from libgcrypt here even more. Thanks to libgcrypt 1.10+ this is on by default.TODO:
Adapt linux config to make sure CPU features are exposed (AMD/Qemu)Edit: virtio only here, amd cpu is older family and needed RDSEED nor RDRAND is available on q35.