I just installed the cpuid package. Here is a portion of the output for my
processor. As you can see: RDRAND reported "= false" which means
my processor does not suppoprt the hardware random number generator feature.
feature information (1/ecx):
PNI/SSE3: Prescott New Instructions = true
PCLMULDQ instruction = true
DTES64: 64-bit debug store = false
MONITOR/MWAIT = true
CPL-qualified debug store = false
VMX: virtual machine extensions = false
SMX: safer mode extensions = false
Enhanced Intel SpeedStep Technology = false
TM2: thermal monitor 2 = false
SSSE3 extensions = true
context ID: adaptive or shared L1 data = false
SDBG: IA32_DEBUG_INTERFACE = false
FMA instruction = true
CMPXCHG16B instruction = true
xTPR disable = false
PDCM: perfmon and debug = false
PCID: process context identifiers = false
DCA: direct cache access = false
SSE4.1 extensions = true
SSE4.2 extensions = true
x2APIC: extended xAPIC support = false
MOVBE instruction = false
POPCNT instruction = true
time stamp counter deadline = false
AES instruction = true
XSAVE/XSTOR states = true
OS-enabled XSAVE/XSTOR = true
AVX: advanced vector extensions = true
F16C half-precision convert instruction = true
RDRAND instruction = false
hypervisor guest status = false
On Thu, Jun 21, 2018 at 11:00 AM, Gerald B. Cox <[email protected]> wrote:
>
>
> On Thu, Jun 21, 2018 at 10:27 AM, Lennart Poettering <[email protected]
> > wrote:
>
>>
>> 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...)
>>
>> Here are a couple of links I found:
> https://www.certdepot.net/rhel7-get-started-random-number-generator/
> https://volumeintegration.com/best-entropy-generation-software-for-linux/
>
> 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]
> <https://en.wikipedia.org/wiki/RdRand#cite_note-1>) is an instruction
> <https://en.wikipedia.org/wiki/Instruction_(computer_science)> for
> returning random numbers from an Intel
> <https://en.wikipedia.org/wiki/Intel> on-chip hardware random number
> generator <https://en.wikipedia.org/wiki/Hardware_random_number_generator>
> which has been seeded by an on-chip entropy source.[2]
> <https://en.wikipedia.org/wiki/RdRand#cite_note-SIG-2> RDRAND is
> available in Ivy Bridge
> <https://en.wikipedia.org/wiki/Ivy_Bridge_(microarchitecture)> processors
> [a] <https://en.wikipedia.org/wiki/RdRand#cite_note-4> and is part of the
> Intel
> 64 <https://en.wikipedia.org/wiki/Intel_64> and IA-32
> <https://en.wikipedia.org/wiki/IA-32> instruction set architectures
> <https://en.wikipedia.org/wiki/Instruction_set>. AMD added support for
> the instruction in June 2015."
>
> Also apparently: "
>
> The CPUID <https://en.wikipedia.org/wiki/CPUID> instruction can be used
> to check whether the central processing unit
> <https://en.wikipedia.org/wiki/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]
> <https://en.wikipedia.org/wiki/RdRand#cite_note-10> AMD processors are
> checked for the feature using the same test.[10]
> <https://en.wikipedia.org/wiki/RdRand#cite_note-11> 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] <https://en.wikipedia.org/wiki/RdRand#cite_note-12>
>
> 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]"
> <https://en.wikipedia.org/wiki/RdRand#cite_note-13>
>
>
> 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 -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]/message/KYIJKPEOWM4G4Y6HRCQLWUSPKB2OS6DF/
