On Thu, Jun 21, 2018 at 10:27 AM, Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote:
Here are a couple of links I found:
Just out of curiosity: when precisely is rngd supposed to be used? As
soon as there's a hardware RNG device /dev/hwrng? That should be
easy enough: ConditionFileExists=/dev/hwrng... Or are there other
cases when this is supposed to be start?
(Also, why is there a userspace component for this stuff in the first
place? I mean streaming data from one corner of the kernel to another
corner of the kernel is something probably better done inside of the
kernel instead of involving userspace at all with this...)
My understanding from the above is that "Rngd-tools and the rngd command is not a tool to generate entropy.
It is
a program that takes randomness from a true random hardware device and
puts it into /dev/random."
So, if you don't have the hardware device, it isn't to be used. There are usb type devices such as
OneRNG, TrueRNG, Chaoskey, NeuG that you can purchase that can provide this functionality.
This link from Wikipedia: https://en.wikipedia.org/wiki/RdRand
says that "
RDRAND (previously known as Bull Mountain[1]) is an instruction for returning random numbers from an Intel on-chip hardware random number generator which has been seeded by an on-chip entropy source.[2] RDRAND is available in Ivy Bridge processors[a] and is part of the Intel 64 and IA-32 instruction set architectures. AMD added support for the instruction in June 2015."Also apparently: "
The CPUID instruction can be used to check whether the central processing unit (CPU) supports the RDRAND instruction on both AMD and Intel CPUs. If supported, bit 30 of the ECX register is set after calling CPUID standard function 01H.[9] AMD processors are checked for the feature using the same test.[10] RDSEED availability can be checked on Intel CPUs in a similar manner. If RDSEED is supported, the bit 18 of the EBX register is set after calling CPUID standard function 07H.[11]
The opcode for RDRAND is 0x0F 0xC7, followed by a ModRM byte that specifies the destination register and optionally combined with a REX prefix in 64 bit mode.[12]"
So, apparently, the CPUID instruction holds the key and should be checked to see if the CPU supports it. In the case of the external USB devices, I don't believe you need to worry about those. If someone purchases
them, they would know they would need to take action to get it to work.
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/FRROROPY7UX2A7VBSKRQMESNKFJ5PGP4/
