Petr Štetiar <yn...@true.cz> [2019-03-15 15:09:23]:
> I see it more as a problem of the implementation of getrandom syscall in
> Linux kernel
I've just found following interesting upstream commits in v4.18:
commit 39a8883a2b989d1d21bd8dd99f5557f0c5e89694
Author: Theodore Ts'o <ty...@mit.edu>
Date: Tue Jul 17 18:24:27 2018 -0400
random: add a config option to trust the CPU's hwrng
This gives the user building their own kernel (or a Linux
distribution) the option of deciding whether or not to trust the CPU's
hardware random number generator (e.g., RDRAND for x86 CPU's) as being
correctly implemented and not having a back door introduced (perhaps
courtesy of a Nation State's law enforcement or intelligence
agencies).
This will prevent getrandom(2) from blocking, if there is a
willingness to trust the CPU manufacturer.
commit 9b25436662d5fb4c66eb527ead53cab15f596ee0
Author: Kees Cook <keesc...@chromium.org>
Date: Mon Aug 27 14:51:54 2018 -0700
random: make CPU trust a boot parameter
Instead of forcing a distro or other system builder to choose
at build time whether the CPU is trusted for CRNG seeding via
CONFIG_RANDOM_TRUST_CPU, provide a boot-time parameter for end users to
control the choice. The CONFIG will set the default state instead.
So this actually might be a better direction for exploration.
-- ynezz
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
