Sorry but I think that relying on Intel RNG is a _Terrible_ idea regarding the security and not sure you should be pursuing it. If you really want a hardware RNG that is also secure, why not take a look at some USB dongles like FST-01 or Librem key? Here is a ( sadly deleted recently! ) Wikipedia comparison page - https://web.archive.org/web/20180812092012/https://en.wikipedia.org/wiki/Com... - You can check it to find the best price/performance USB TRNG dongle which is also open hardware
Best regards, Ivan Ivanov вт, 27 нояб. 2018 г. в 22:50, Grant Grundler grantgrundler@gmail.com:
On Tue, Nov 27, 2018 at 4:10 AM Nico Huber nico.huber@secunet.com wrote:
Hi Grant,
I don't know how it is supposed to work on Haswell, but can give you some pointers anyway.
tl;dr I don't think you are looking for a PCI device.
If intel-rng support is required, a PCI device will be advertised because of how the linux kernel binds PCI devices to drivers. See "alias" field of "modinfo intel-rng" as an example.
One of the search results pointed at a response that said "load intel-rng driver" as the solution to this problem... that's the only reason I'm exploring this path.
Am 27.11.18 um 08:11 schrieb Grant Grundler:
Asus Chromebox (Panther) with Celeron 2995U processor is supposed to have a HW Random Number Generator: https://ark.intel.com/products/75608/Intel-Celeron-Processor-2955U-2M-Cache-...
(Intel calls it Secure Key)
But "modprobe intel-rng" is failing with "No such device" (Debian 4.18.0-2-amd64 kernel).
This driver is for very old Firmware Hub (FWH) hardware which would be controlled through the LPC PCI device. You have such a PCI device (00:1f.0) but there's no FWH to be expect with Haswell.
Hrm. OK. But that would explain why intel-rng driver only binds with PCI devices.
What you are probably looking for is the RDRAND instruction. I don't know if it can be controlled by the firmware, but would check first if your OS is prepared to make use of it.
Linux kernel has supported RDRAND for a long time. There is even a public debate about *excluding* RDRAND use since some people were hypothesizing that RDRAND was "compromised" by Intel so "goverment agencies" could break encrypted traffic which used RDRAND exclusively to generate encryption keys. Linux kernel does NOT exclusively use RDRAND and Ted Tyso made compelling arguments that RDRAND would still add "entropy" to key generation.
What I don't know is how linux figures out it can or should use RDRAND. RDRAND appears to be a "CPU feature":
arch/x86/include/asm/cpufeatures.h:#define X86_FEATURE_RDRAND ( 4*32+30) /* RDRAND instruction */
And as notedin original email, Intel says this CPU (Celeron 2995U) supports "Secure Key" which is the new marketing name for HW RNG support (could be only via RDRAND now).
Why do I care about HW RNG? Because of this: ... [ 8.560270] r8169 0000:01:00.0 enp1s0: link up [ 8.560287] IPv6: ADDRCONF(NETDEV_CHANGE): enp1s0: link becomes ready [19039.712644] random: crng init done [19039.712649] random: 7 urandom warning(s) missed due to ratelimiting [19044.485625] wlp2s0: authenticate with ... ...
Yes, several *hours* until the crng was initialized and then wpa_supplicant could start talking on WIFI. :(
The length of the delay varies...shortest was 7 minutes.
Well, even without a hardware rng, I wouldn't expect that.
Exactly. I didn't either. My NUC5 completes typically in 3 second from the time the kernel is loaded. But this is a different CPU (Intel Core i5 6260) and completely different firmware (If Coreboot was available for this, I'd prefer Coreboot).
With antennas available, I would say after 10s for the paranoid there should be enough entropy available. But that's probably just how I'd do OS development (and depends on what the wifi driver can do).
I don't know if the kernel has access to any radios (or antennas) until the 80211 link is brought up... which in turn won't happen until wpa_supplicant is running. So something else is wrong here. My suspicion is still on Coreboot not providing something that tells the linux kernel a quick method to generate random numbers.
I saw Matt DeVillier's response as well and I'll follow up once I've updated the SeaBIOS firmware, installed rng-tools5, and determined which CPU features are advertised by both Panther and NUC CPUs. For some reason my "phone home" (SSH) is getting rejected right now. :(
cheers, grant
Nico
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Hi Grant,
I don't know how it is supposed to work on Haswell, but can give you some pointers anyway.
tl;dr I don't think you are looking for a PCI device.
Am 27.11.18 um 08:11 schrieb Grant Grundler:
Asus Chromebox (Panther) with Celeron 2995U processor is supposed to have a HW Random Number Generator: https://ark.intel.com/products/75608/Intel-Celeron-Processor-2955U-2M-Cache-...
(Intel calls it Secure Key)
But "modprobe intel-rng" is failing with "No such device" (Debian 4.18.0-2-amd64 kernel).
This driver is for very old Firmware Hub (FWH) hardware which would be controlled through the LPC PCI device. You have such a PCI device (00:1f.0) but there's no FWH to be expect with Haswell.
What you are probably looking for is the RDRAND instruction. I don't know if it can be controlled by the firmware, but would check first if your OS is prepared to make use of it.
Why do I care about HW RNG? Because of this: ... [ 8.560270] r8169 0000:01:00.0 enp1s0: link up [ 8.560287] IPv6: ADDRCONF(NETDEV_CHANGE): enp1s0: link becomes ready [19039.712644] random: crng init done [19039.712649] random: 7 urandom warning(s) missed due to ratelimiting [19044.485625] wlp2s0: authenticate with ... ...
Yes, several *hours* until the crng was initialized and then wpa_supplicant could start talking on WIFI. :(
The length of the delay varies...shortest was 7 minutes.
Well, even without a hardware rng, I wouldn't expect that. With antennas available, I would say after 10s for the paranoid there should be enough entropy available. But that's probably just how I'd do OS development (and depends on what the wifi driver can do).
Nico
Hi! Asus Chromebox (Panther) with Celeron 2995U processor is supposed to have a HW Random Number Generator: https://ark.intel.com/products/75608/Intel-Celeron-Processor-2955U-2M-Cache-...
(Intel calls it Secure Key)
But "modprobe intel-rng" is failing with "No such device" (Debian 4.18.0-2-amd64 kernel).
That's because there isn't one listed in "lspci" output: root@stoke:~# lspci -n 00:00.0 0600: 8086:0a04 (rev 09) 00:02.0 0300: 8086:0a06 (rev 09) 00:03.0 0403: 8086:0a0c (rev 09) 00:14.0 0c03: 8086:9c31 (rev 04) 00:16.0 0780: 8086:9c3a (rev 04) 00:1b.0 0403: 8086:9c20 (rev 04) 00:1c.0 0604: 8086:9c14 (rev e4) 00:1c.1 0604: 8086:9c16 (rev e4) 00:1c.2 0604: 8086:9c18 (rev e4) 00:1f.0 0601: 8086:9c45 (rev 04) 00:1f.2 0106: 8086:9c03 (rev 04) 00:1f.3 0c05: 8086:9c22 (rev 04) 00:1f.6 1180: 8086:9c24 (rev 04) 01:00.0 0200: 10ec:8168 (rev 0c) 02:00.0 0280: 168c:0034 (rev 01)
Could Firmware add the HW RNG so intel-rng is happy?
(I'll append human readable below)
Current firmware is: [ 0.000000] DMI: Google Panther/Panther, BIOS MattDevo 04/18/2016
And if this is fixed in a newer firmware update, please hand me the paper bag I can hide under. :) I've downloaded a newer version of the SeaBIOS but haven't (yet) found the instructions to install it.
Why do I care about HW RNG? Because of this: ... [ 8.560270] r8169 0000:01:00.0 enp1s0: link up [ 8.560287] IPv6: ADDRCONF(NETDEV_CHANGE): enp1s0: link becomes ready [19039.712644] random: crng init done [19039.712649] random: 7 urandom warning(s) missed due to ratelimiting [19044.485625] wlp2s0: authenticate with ... ...
Yes, several *hours* until the crng was initialized and then wpa_supplicant could start talking on WIFI. :(
The length of the delay varies...shortest was 7 minutes.
thanks for any help, grant
# lspci 00:00.0 Host bridge: Intel Corporation Haswell-ULT DRAM Controller (rev 09) 00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 09) 00:03.0 Audio device: Intel Corporation Haswell-ULT HD Audio Controller (rev 09) 00:14.0 USB controller: Intel Corporation 8 Series USB xHCI HC (rev 04) 00:16.0 Communication controller: Intel Corporation 8 Series HECI #0 (rev 04) 00:1b.0 Audio device: Intel Corporation 8 Series HD Audio Controller (rev 04) 00:1c.0 PCI bridge: Intel Corporation 8 Series PCI Express Root Port 3 (rev e4) 00:1c.1 PCI bridge: Intel Corporation 8 Series PCI Express Root Port 4 (rev e4) 00:1c.2 PCI bridge: Intel Corporation 8 Series PCI Express Root Port 5 (rev e4) 00:1f.0 ISA bridge: Intel Corporation 8 Series LPC Controller (rev 04) 00:1f.2 SATA controller: Intel Corporation 8 Series SATA Controller 1 [AHCI mode] (rev 04) 00:1f.3 SMBus: Intel Corporation 8 Series SMBus Controller (rev 04) 00:1f.6 Signal processing controller: Intel Corporation 8 Series Thermal (rev 04) 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c) 02:00.0 Network controller: Qualcomm Atheros AR9462 Wireless Network Adapter (rev 01)
On Sat, Dec 22, 2018 at 12:05 AM Angel Pons th3fanbus@gmail.com wrote:
Hello,
On Sat, Dec 22, 2018, 08:50 Grant Grundler <grantgrundler@gmail.com wrote:
On Wed, Nov 28, 2018 at 1:51 AM Ivan Ivanov qmastery16@gmail.com wrote:
Sorry but I think that relying on Intel RNG is a _Terrible_ idea regarding the security and not sure you should be pursuing it.
What I'm pursueing is a reasonable initialization time so wpa_supplicant can start. 555 seconds is not reasonable: [ 555.496678] random: crng init done [ 555.496678] random: crng init done [ 555.496684] random: 7 urandom warning(s) missed due to ratelimiting [ 560.265385] wlp2s0: authenticate with xx:xx:xx:xx:xx:xx [ 560.279395] wlp2s0: send auth to xx:xx:xx:xx:xx:xx (try 1/3) [ 560.281981] wlp2s0: authenticated
intel-crng was proposed elsewhere as one solution to this problem but it's clear to me now that this is not an option with the panther chromebox.
I don't recall seeing this with older kernels (have been running debian on this HW since early 4.x releases) and will look at the driver git logs.
And I found one commit which I believe is likely the issue (need to confirm this still): commit dc12baacb95f205948f64dc936a47d89ee110117 Author: Theodore Ts'o tytso@mit.edu Date: Wed Apr 11 14:58:27 2018 -0400
random: use a different mixing algorithm for add_device_randomness()
This change _could_ cause devices that don't have input or have wireless networking (which doesn't get initialized until wpa_supplicants gets a value back from /dev/random) to take a very long time for crng_init to increment and finally determine "random: crng init done" (in crng_reseed()).
But I need to compare v4.17 behavior (where I think this was introduced) with v4.16 or just revert this with my own 4.18 kernel build.
I'm using the following git commands to compare differences in releases: git diff v4.16..v4.17 -- drivers/char/random.c git diff v4.17..v4.18 -- drivers/char/random.c
(same parameters with "log" instead of "diff" to see the corresponding commit messages)
...
I experimented with attaching just an optical mouse and that didn't seem to help. Attaching a keyboard and just hitting <shift> key did seem to help ("crng init done" in about 10 seconds). I'm assuming the /dev/random driver is not seeing enough actiivity otherwise.
I have observed the same behavior on Debian Sid, I would have to smash my keyboard a few times to generate enough entropy. I don't see anything similar with Arch Linux. Maybe it has to do with distro-specific packaging? I haven't checked.
Does Arch-Linux kernel include the CL above? ie Is Arch linux offering a 4.17 (or later) kernel?
cheers, grant
ps. I realize this is the wrong forum to discuss a fix ... just want to wrap up the conversation here to confirm my theory that this might be a coreboot issue is wrong.
On Tue, Nov 27, 2018 at 4:10 AM Nico Huber nico.huber@secunet.com wrote:
Hi Grant,
I don't know how it is supposed to work on Haswell, but can give you some pointers anyway.
tl;dr I don't think you are looking for a PCI device.
If intel-rng support is required, a PCI device will be advertised because of how the linux kernel binds PCI devices to drivers. See "alias" field of "modinfo intel-rng" as an example.
One of the search results pointed at a response that said "load intel-rng driver" as the solution to this problem... that's the only reason I'm exploring this path.
Am 27.11.18 um 08:11 schrieb Grant Grundler:
Asus Chromebox (Panther) with Celeron 2995U processor is supposed to have a HW Random Number Generator: https://ark.intel.com/products/75608/Intel-Celeron-Processor-2955U-2M-Cache-...
(Intel calls it Secure Key)
But "modprobe intel-rng" is failing with "No such device" (Debian 4.18.0-2-amd64 kernel).
This driver is for very old Firmware Hub (FWH) hardware which would be controlled through the LPC PCI device. You have such a PCI device (00:1f.0) but there's no FWH to be expect with Haswell.
Hrm. OK. But that would explain why intel-rng driver only binds with PCI devices.
What you are probably looking for is the RDRAND instruction. I don't know if it can be controlled by the firmware, but would check first if your OS is prepared to make use of it.
Linux kernel has supported RDRAND for a long time. There is even a public debate about *excluding* RDRAND use since some people were hypothesizing that RDRAND was "compromised" by Intel so "goverment agencies" could break encrypted traffic which used RDRAND exclusively to generate encryption keys. Linux kernel does NOT exclusively use RDRAND and Ted Tyso made compelling arguments that RDRAND would still add "entropy" to key generation.
What I don't know is how linux figures out it can or should use RDRAND. RDRAND appears to be a "CPU feature":
arch/x86/include/asm/cpufeatures.h:#define X86_FEATURE_RDRAND ( 4*32+30) /* RDRAND instruction */
And as notedin original email, Intel says this CPU (Celeron 2995U) supports "Secure Key" which is the new marketing name for HW RNG support (could be only via RDRAND now).
Why do I care about HW RNG? Because of this: ... [ 8.560270] r8169 0000:01:00.0 enp1s0: link up [ 8.560287] IPv6: ADDRCONF(NETDEV_CHANGE): enp1s0: link becomes ready [19039.712644] random: crng init done [19039.712649] random: 7 urandom warning(s) missed due to ratelimiting [19044.485625] wlp2s0: authenticate with ... ...
Yes, several *hours* until the crng was initialized and then wpa_supplicant could start talking on WIFI. :(
The length of the delay varies...shortest was 7 minutes.
Well, even without a hardware rng, I wouldn't expect that.
Exactly. I didn't either. My NUC5 completes typically in 3 second from the time the kernel is loaded. But this is a different CPU (Intel Core i5 6260) and completely different firmware (If Coreboot was available for this, I'd prefer Coreboot).
With antennas available, I would say after 10s for the paranoid there should be enough entropy available. But that's probably just how I'd do OS development (and depends on what the wifi driver can do).
I don't know if the kernel has access to any radios (or antennas) until the 80211 link is brought up... which in turn won't happen until wpa_supplicant is running. So something else is wrong here. My suspicion is still on Coreboot not providing something that tells the linux kernel a quick method to generate random numbers.
I saw Matt DeVillier's response as well and I'll follow up once I've updated the SeaBIOS firmware, installed rng-tools5, and determined which CPU features are advertised by both Panther and NUC CPUs. For some reason my "phone home" (SSH) is getting rejected right now. :(
cheers, grant
Nico
-
Grant Grundler -
Ivan Ivanov -
Nico Huber