Re: newfs silently fails if random is not ready (?)
Nice catch! Thanks :-)
M
> On 5 Sep 2018, at 04:13, Conrad Meyer wrote:
>
> Hi Lev,
>
> I took a first attempt at reproducing this problem on a fast
> desktop-class system. First steps, give us a way to revert back to
> unseeded status:
>
> --- a/sys/dev/random/fortuna.c
> +++ b/sys/dev/random/fortuna.c
> @@ -39,6 +39,7 @@ __FBSDID("$FreeBSD$");
>
> #ifdef _KERNEL
> #include
> +#include
> #include
> #include
> #include
> @@ -384,6 +385,17 @@ random_fortuna_pre_read(void)
>return;
>}
>
> + /*
> +* When set, pretend we do not have enough entropy to reseed yet.
> +*/
> + KFAIL_POINT_CODE(DEBUG_FP, random_fortuna_pre_read, {
> + if (RETURN_VALUE != 0) {
> + RANDOM_RESEED_UNLOCK();
> + return;
> + }
> + });
> +
> +
> #ifdef _KERNEL
>fortuna_state.fs_lasttime = now;
> #endif
> @@ -442,5 +454,11 @@ bool
> random_fortuna_seeded(void)
> {
>
> + /* When set, act as if we are not seeded. */
> + KFAIL_POINT_CODE(DEBUG_FP, random_fortuna_seeded, {
> + if (RETURN_VALUE != 0)
> + fortuna_state.fs_counter = UINT128_ZERO;
> + });
> +
>return (!uint128_is_zero(fortuna_state.fs_counter));
> }
>
>
> Second step, enable the failpoints and launch repro program:
>
> $ sudo sysctl debug.fail_point.random_fortuna_pre_read='return(1)'
> debug.fail_point.random_fortuna_pre_read: off -> return(1)
> $ sudo sysctl debug.fail_point.random_fortuna_seeded='return(1)'
> debug.fail_point.random_fortuna_seeded: off -> return(1)
>
> $ cat ./blocked_random_poc.c
> #include
> #include
> #include
>
> int
> main(int argc, char **argv)
> {
>printf("%x\n", arc4random());
>return (0);
> }
>
>
> $ ./blocked_random_poc
> ...
>
>
> Third step, I looked at what that process was doing:
>
> Curiously, it is not in getrandom() at all, but instead the ARND
> sysctl fallback. I probably need to rebuild world (libc) to test this
> (new libc arc4random based on Chacha).
>
> $ procstat -kk 1196
> PIDTID COMMTDNAME KSTACK
> 1196 100435 blocked_random_poc - read_random+0x3d
> sysctl_kern_arnd+0x3a sysctl_root_handler_locked+0x89
> sysctl_root.isra.8+0x167 userland_sysctl+0x126 sys___sysctl+0x7b
> amd64_syscall+0x940 fast_syscall_common+0x101
>
>
> When I unblocked the failpoints, it completed successfully:
>
> $ sudo sysctl debug.fail_point.random_fortuna_pre_read='off'
> debug.fail_point.random_fortuna_pre_read: return(1) -> off
> $ sudo sysctl debug.fail_point.random_fortuna_seeded=off
> debug.fail_point.random_fortuna_seeded: return(1) -> off
>
> ...
> 9e5eb30f
>
>
> Best,
> Conrad
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
--
Mark R V Murray
signature.asc
Description: Message signed with OpenPGP
Re: em broken on current amd64
> On 13 Sep 2015, at 16:45, Sean Bruno <sbr...@freebsd.org> wrote: > Any chance you can turn TSO off if its on and see what your results are? Only TSO4 was on. I turned it off; no difference. M -- Mark R V Murray ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: em broken on current amd64
> On 8 Sep 2015, at 19:02, Mark R V Murray <ma...@freebsd.org> wrote: > > >> On 8 Sep 2015, at 17:22, Sean Bruno <sbr...@freebsd.org> wrote: >> >> >>>>> >>>>> I’m also seeing breakage with the em0 device; this isn’t a kernel >>>>> hang, it is a failure to move data after about 10-15 minutes. The >>>>> symptom is that my WAN ethernet no longer moves traffic, no pings, >>>>> nothing. Booting looks normal: >>>>> >>>>> em0: <Intel(R) PRO/1000 Network Connection 7.4.2> port >>>>> 0x30c0-0x30df mem 0x5030-0x5031,0x50324000-0x50324fff irq >>>>> 20 at device 25.0 on pci0 em0: Using an MSI interrupt em0: Ethernet >>>>> address: 00:16:76:d3:e1:5b em0: netmap queues/slots: TX 1/1024, RX >>>>> 1/1024 >>>>> >>>>> Fixing it is as easy as … >>>>> >>>>> # ifconfig em0 down ; service ipfw restart ; ifconfig em0 up >>>>> >>>>> :-) >>>>> >>>>> I’m running CURRENT, r287538. This last worked of me a month or so >>>>> ago at my previous build. >>>>> >>>>> M >>>>> >>>> >>>> >>>> Just so I'm clear, the original problem reported was a failure to >>>> attach (you were among several folks reporting breakage). Is that fixed >>>> ? >>> >>> I did not report the failure to attach, and I am not seeing it as I don’t >>> think I built a kernel that had that particular failure. I am having the >>> “failure after 10-15 minutes” problem; this is on an em0 device. >>> >>> M >>> >> >> >> Hrm, that's odd. That sounds like a hole where interrupts aren't being >> reset for "reasons" that I cannot fathom. >> >> What hardware (pciconf -lv) does your system actually have? The em(4) >> driver doesn't identify components which is frustrating. > > pciconf -lv output below: > > hostb0@pci0:0:0:0:class=0x06 card=0x514d8086 chip=0x29a08086 rev=0x02 > hdr=0x00 >vendor = 'Intel Corporation' >device = '82P965/G965 Memory Controller Hub' >class = bridge >subclass = HOST-PCI I just caught this, on today’s build: em0: Watchdog timeout Queue[0]-- resetting Interface is RUNNING and ACTIVE em0: TX Queue 0 -- em0: hw tdh = 127, hw tdt = 139 em0: Tx Queue Status = -2147483648 em0: TX descriptors avail = 1012 em0: Tx Descriptors avail failure = 0 em0: RX Queue 0 -- em0: hw rdh = 0, hw rdt = 1023 em0: RX discarded packets = 0 em0: RX Next to Check = 0 em0: RX Next to Refresh = 1023 [graveyard] /usr/ports 09:42 pm # uname -a FreeBSD graveyard.grondar.org 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r287705: Sat Sep 12 15:07:54 BST 2015 r...@graveyard.grondar.org:/b/obj/usr/src/sys/G_AMD64_GATE amd64 M -- Mark R V Murray ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: em broken on current amd64
> On 8 Sep 2015, at 00:44, Sean Bruno <sbr...@freebsd.org> wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > > > On 09/07/15 14:10, Mark R V Murray wrote: >> >>> On 5 Sep 2015, at 17:11, Garrett Cooper <yaneurab...@gmail.com> >>> wrote: >>> >>> >>>> On Sep 5, 2015, at 08:50, Manfred Antar <n...@pozo.com> wrote: >>>> >>>> Recent changes to em have broken current on amd64. Booting >>>> kernel will hang when trying to load em0, then will continue >>>> booting without the driver loading (No Network) This is on a HP >>>> SFF 8000 with em0 embedded on the motherboard. >>>> >>>> boot messages: >>>> >>>> em0: <Intel(R) PRO/1000 Network Connection 7.5.2> port >>>> 0x3100-0x311f mem 0xf310-0xf311,0xf3125000-0xf3125fff >>>> irq 19 at device 25.0 on pci0 em0: attempting to allocate 1 MSI >>>> vectors (1 supported) em0: using IRQ 265 for MSI em0: Using an >>>> MSI interrupt em0: The EEPROM Checksum Is Not Valid >>>> device_attach: em0 attach returned 5 >>> >>> Tijl said the same. The offending commit's r287467. Cheers, >> >> I’m also seeing breakage with the em0 device; this isn’t a kernel >> hang, it is a failure to move data after about 10-15 minutes. The >> symptom is that my WAN ethernet no longer moves traffic, no pings, >> nothing. Booting looks normal: >> >> em0: <Intel(R) PRO/1000 Network Connection 7.4.2> port >> 0x30c0-0x30df mem 0x5030-0x5031,0x50324000-0x50324fff irq >> 20 at device 25.0 on pci0 em0: Using an MSI interrupt em0: Ethernet >> address: 00:16:76:d3:e1:5b em0: netmap queues/slots: TX 1/1024, RX >> 1/1024 >> >> Fixing it is as easy as … >> >> # ifconfig em0 down ; service ipfw restart ; ifconfig em0 up >> >> :-) >> >> I’m running CURRENT, r287538. This last worked of me a month or so >> ago at my previous build. >> >> M >> > > > Just so I'm clear, the original problem reported was a failure to > attach (you were among several folks reporting breakage). Is that fixed > ? I did not report the failure to attach, and I am not seeing it as I don’t think I built a kernel that had that particular failure. I am having the “failure after 10-15 minutes” problem; this is on an em0 device. M -- Mark R V Murray ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: em broken on current amd64
-PCI uhci2@pci0:0:29:0: class=0x0c0300 card=0x514d8086 chip=0x28308086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) USB UHCI Controller' class = serial bus subclass = USB uhci3@pci0:0:29:1: class=0x0c0300 card=0x514d8086 chip=0x28318086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) USB UHCI Controller' class = serial bus subclass = USB uhci4@pci0:0:29:2: class=0x0c0300 card=0x514d8086 chip=0x28328086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) USB UHCI Controller' class = serial bus subclass = USB ehci1@pci0:0:29:7: class=0x0c0320 card=0x514d8086 chip=0x28368086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) USB2 EHCI Controller' class = serial bus subclass = USB pcib6@pci0:0:30:0: class=0x060401 card=0x514d8086 chip=0x244e8086 rev=0xf2 hdr=0x01 vendor = 'Intel Corporation' device = '82801 PCI Bridge' class = bridge subclass = PCI-PCI isab0@pci0:0:31:0: class=0x060100 card=0x514d8086 chip=0x28108086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801HB/HR (ICH8/R) LPC Interface Controller' class = bridge subclass = PCI-ISA atapci1@pci0:0:31:2:class=0x01018f card=0x514d8086 chip=0x28208086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) 4 port SATA Controller [IDE mode]' class = mass storage subclass = ATA ichsmb0@pci0:0:31:3:class=0x0c0500 card=0x514d8086 chip=0x283e8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801H (ICH8 Family) SMBus Controller' class = serial bus subclass = SMBus atapci2@pci0:0:31:5:class=0x010185 card=0x514d8086 chip=0x28258086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801HR/HO/HH (ICH8R/DO/DH) 2 port SATA Controller [IDE mode]' class = mass storage subclass = ATA atapci0@pci0:2:0:0: class=0x01018f card=0x610111ab chip=0x610111ab rev=0xb1 hdr=0x00 vendor = 'Marvell Technology Group Ltd.' device = '88SE6101/6102 single-port PATA133 interface' class = mass storage subclass = ATA dc0@pci0:6:0:0: class=0x02 card=0xf0041385 chip=0x000211ad rev=0x20 hdr=0x00 vendor = 'Lite-On Communications Inc' device = 'LNE100TX' class = network subclass = ethernet sym0@pci0:6:1:0:class=0x01 card=0x80001092 chip=0x008f1000 rev=0x04 hdr=0x00 vendor = 'LSI Logic / Symbios Logic' device = '53c875J' class = mass storage subclass = SCSI none1@pci0:6:3:0: class=0x0c0010 card=0x514d8086 chip=0x8023104c rev=0x00 hdr=0x00 vendor = 'Texas Instruments' device = 'TSB43AB22A IEEE-1394a-2000 Controller (PHY/Link) [iOHCI-Lynx]' class = serial bus subclass = FireWire M -- Mark R V Murray ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: em broken on current amd64
> On 5 Sep 2015, at 17:11, Garrett Cooper <yaneurab...@gmail.com> wrote: > > >> On Sep 5, 2015, at 08:50, Manfred Antar <n...@pozo.com> wrote: >> >> Recent changes to em have broken current on amd64. >> Booting kernel will hang when trying to load em0, then will continue booting >> without the driver loading (No Network) >> This is on a HP SFF 8000 with em0 embedded on the motherboard. >> >> boot messages: >> >> em0: <Intel(R) PRO/1000 Network Connection 7.5.2> port 0x3100-0x311f mem >> 0xf310-0xf311,0xf3125000-0xf3125fff irq 19 at device 25.0 on pci0 >> em0: attempting to allocate 1 MSI vectors (1 supported) >> em0: using IRQ 265 for MSI >> em0: Using an MSI interrupt >> em0: The EEPROM Checksum Is Not Valid >> device_attach: em0 attach returned 5 > > Tijl said the same. The offending commit's r287467. > Cheers, I’m also seeing breakage with the em0 device; this isn’t a kernel hang, it is a failure to move data after about 10-15 minutes. The symptom is that my WAN ethernet no longer moves traffic, no pings, nothing. Booting looks normal: em0: <Intel(R) PRO/1000 Network Connection 7.4.2> port 0x30c0-0x30df mem 0x5030-0x5031,0x50324000-0x50324fff irq 20 at device 25.0 on pci0 em0: Using an MSI interrupt em0: Ethernet address: 00:16:76:d3:e1:5b em0: netmap queues/slots: TX 1/1024, RX 1/1024 Fixing it is as easy as … # ifconfig em0 down ; service ipfw restart ; ifconfig em0 up :-) I’m running CURRENT, r287538. This last worked of me a month or so ago at my previous build. M -- Mark R V Murray ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Device random seems broken.
On 22 Aug 2015, at 06:03, Steve Kargl s...@troutmask.apl.washington.edu wrote: Please fix. On its way. M -- Mark R V Murray ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Device random seems broken.
On 22 Aug 2015, at 13:49, Mark R V Murray m...@grondar.org wrote: On 22 Aug 2015, at 06:03, Steve Kargl s...@troutmask.apl.washington.edu wrote: Please fix. On its way. Fixed. A git commit was in the wrong review (D3197 instead of D3354). This is now committed as svn commit r287023. M -- Mark R V Murray ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB locks up system -- WAS Re: shutdown or acpi problem
On 16 Nov 2014, at 17:51, Steve Kargl s...@troutmask.apl.washington.edu wrote: Is there a 'random: device_detach():' missing between the 'umass0' and 'da0' messages in the last 4 lines. No. At attach time, the RNG grabs some probe entropy. At detach time it does nothing. M -- Mark R V Murray ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB locks up system -- WAS Re: shutdown or acpi problem
On 16 Nov 2014, at 18:21, Ian Lepore i...@freebsd.org wrote: On Sun, 2014-11-16 at 18:17 +, Mark R V Murray wrote: On 16 Nov 2014, at 17:51, Steve Kargl s...@troutmask.apl.washington.edu wrote: Is there a 'random: device_detach():' missing between the 'umass0' and 'da0' messages in the last 4 lines. No. At attach time, the RNG grabs some probe entropy. At detach time it does nothing. M And yet... Steve has gathered evidence that the system bricks when a device is detached with the new entropy-gathering code and doesn't do so prior to that code. What else is the new code doing around detach time? Nothing, except possibly harvesting interrupt entropy. I’ll promise to be astonished if this is other-than-harmless. I’d be more suspicious of the harvester thread, but I still can’t see how its hurting :-( M -- Mark R V Murray ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB locks up system -- WAS Re: shutdown or acpi problem
On 16 Nov 2014, at 18:31, Ian Lepore i...@freebsd.org wrote: The point I'm trying to make here is that you trimmed away the important part of the prior messages and replied only to the part where Steve's debugging efforts were somewhat speculating. The non-speculative part was where he bisected the failure to an exact commit: The problem is caused by r273872. This is the recent random device patch. I have no idea why removing a usb device would cause the system to lock up other than random is probably trying to harvest some entropy. I’m sorry my commit caused the problem. I’m also trying to find out why, but I don’t know enough about USB or mass-storage devices to know why, so this may take me a while. In the meanwhile, I’ll try to help by pointing out things I do know. M -- Mark R V Murray ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB locks up system -- WAS Re: shutdown or acpi problem
On 16 Nov 2014, at 18:51, Steve Kargl s...@troutmask.apl.washington.edu wrote: I?m sorry my commit caused the problem. Nothing to be sorry about. This is -current after all. Thanks :-) I?m also trying to find out why, but I don?t know enough about USB or mass-storage devices to know why, so this may take me a while. In the meanwhile, I?ll try to help by pointing out things I do know. Yes, I did the bisection to find that r273872 exposes the problem. What I don't know is if this is hardware specific to a Dell Latitude D530 laptop, USB specific, or some weird interaction between the random and USB. What I also find odd is that I seem to be the only person seeing this behavior when it is trivial for me to reproduce: boot laptop, plug in usb device, wait usb recognizes the device, then unplug the device. Strange for me too. I’m not exactly being bombarded with bug reports. If you have not read the entire thread, once the laptop keyboard and video output lock up, I can ssh into the laptop. If I run usbconfig, it hangs, ^T tells me it is stuck in SX Lock, and the /dev/da0* devices have not been destroyed. Weirder and weirder :-(. Something with SX locks? Hmm. I do use those for attach and detach for RNG sources. Could it be that that stick of yours is somehow getting involved in the RNG source locks? M -- Mark R V Murray ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Fwd: New /dev/random code for review please.
Hi Folks, Please could the wisdom-of-crowds apply its collective attention to this? Thanks! M Begin forwarded message: From: Mark R V Murray m...@grondar.org Subject: New /dev/random code for review please. Date: 4 May 2014 18:28:43 BST To: sect...@freebsd.org Team sect...@freebsd.org Content-Type: multipart/signed; boundary=Apple-Mail=_E0FAF9BA-F43A-41EC-ADF7-C7F66942DC33; protocol=application/pgp-signature; micalg=pgp-sha512 X-Smtp-Server: gromit.grondar.org:grondar X-Universally-Unique-Identifier: 57DA4E05-F926-490F-811D-27C027A43800 Message-Id: 64478e8f-ed98-43c2-99bc-167356d3e...@grondar.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Hi guys I’m now about ready to start the job of merging the revamped /dev/random gubbins over to CURRENT from a project branch. The project branch is svn://svn.freebsd.org/base/projects/random_number_generator Not all of the above branch is to be merged right now; the UMA_ALLOC harvester bit will NOT be merged. In follow-up discussions, I will work out how to do this properly. Right now, that code works, but will no doubt piss off RWatson and company for messing up the carefully optimised slab allocator! :-) In the first merge, very little change should be observed. ‘sysctl kern.random’ will look different as the harvesting has been slightly generalised. Yarrow will still be used, but Fortuna will be available as an alternative. Automatic startup due to probing entropy is tested and more-or-less trusted (analysis of numbers to form part of a more academic study). The code is much simplified, and use of overly complex data structures has been rewritten. I request review and comments please, with a view to merging this to CURRENT. Thanks! M -- Mark R V Murray -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [PATCH RFC] Disable save-entropy in jails
On 25 Dec 2013, at 02:04, Xin Li delp...@delphij.net wrote: No, we are not talking about removing /var/db/entropy. What I am proposing to do is to disable entropy savings from jails. Here is why: The way a PRNG works is that it uses one or many entropy sources to feed its internal state, and generate a series of pseudo-random numbers from the internal state via a PRF. FreeBSD collects entropy from several sources: Ethernet, interrupts, software interrupts, etc., as well as hardware RNG that is available to the system, and use all these entropy to derive the internal state of its PRNG. When reading from /dev/random, one essentially consumes entropy that is fed into the random device, and eventually it would cause a reseed. In an ideal world, we would want this to be less predicable and controllable from a potential attacker. So far so good. :-) Normal applications tends to read /dev/random in small bites, and do so in a discrete and nearly random manner, assuming we have a lot of processes running. Saving entropy, on the other hand, happen in larger chunks at a determined time. With multiple jails running, one would have a lot of big chunk reads from the /dev/random device, making its behavior more deterministic, which could have bad consequences. I doubt it goes as far as “bad”, but it certainly does no good. I would support the notion of not caching entropy in jails IFF this didn’t leak out and prevent harvesting in the jail’s host AND this gave a noticeable simplification of script code. M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: HW fed /dev/random
On 10 Sep 2013, at 19:13, Harald Schmalzbauer h.schmalzba...@omnilan.de wrote: Hello, some time ago, before random(4) was rewritten for FreeBSD 5 by Mark Murray, we had rng, the i815 hardware random number generator. At this time, there were rumors about the quality of the randomness. Now we have rdrand (BullMountain hardware random generator in IvyBridge) and Dual_EC_DRBG (NSA's NIST contribution) makes me wonder if quality is again something to worry about - although kib's commit message states: „From the Intel whitepapers and articles about Bull Mountain, it seems that we do not need to perform post-processing of RDRAND results, like AES-encryption of the data with random IV and keys, which was done for Padlock. Intel claims that sanitization is performed in hardware.“ When we use the software random device, one has great control over /dev/random with sysctk kern.random. Are there considerations to extend the HW-rng-implementation by optional post processing? Yes. This was discussed in Cambridge recently, and will no doubt be brought up again in Malta. There are indeed plans to post-process the output of rdrand. M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: random(4) update causes mips compile fail | mips boot fail
On 8 Sep 2013, at 01:36, Glen Barber g...@freebsd.org wrote: Either way, I think this commit needs to be reverted until properly fixed and tested. The hyperbole is getting a little thick. How about sysctl kern.random.sys.seeded=1 ?? M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: random(4) update causes mips compile fail | mips boot fail
On 8 Sep 2013, at 01:31, Glen Barber g...@freebsd.org wrote: On Sat, Sep 07, 2013 at 05:27:19PM -0700, Adrian Chadd wrote: ok. So I can work around this for these MIPS AP images by echoing something into /dev/random ? The correct workaround (which now I see I should have done before locking head/) is to revert this commit so it can be properly fixed. Calling echo '' /dev/random the KNOB is insulting. Using a write to /dev/random as a reseed was there from day one (check random(4)), and while it is not the clearest thing on the planet that a reseed unblocks the device, that has always been there by intent. That is how etc/rc.d/initrandom is supposed to work. In checking the man page I've released that connection needs to be clarified. I've (re)set the seeded bit, so behaviour is as it was. I'll look for a way to set this bit from the kernel config file. M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: random(4) update causes mips compile fail | mips boot fail
On 8 Sep 2013, at 18:31, Glen Barber g...@freebsd.org wrote: On Sun, Sep 08, 2013 at 11:00:24AM +0200, Dag-Erling Smørgrav wrote: Glen Barber g...@freebsd.org writes: The correct workaround (which now I see I should have done before locking head/) is to revert this commit so it can be properly fixed. Glen, to be fair, the mips boot fails because they're trying to use a device before it's ready. To be clear, when I sent my last emails, tinderbox was complaining about build failures (which it did not catch up to the recent head/ revisions), so at the time I thought head/ was still broken for arm and mips architectures. Sorry for the misunderstanding on my part. delphij corrected me on this. No worries, thanks! Keep up the good work! M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: random(4) update causes mips compile fail | mips boot fail
On 7 Sep 2013, at 17:43, Sean Bruno sean_br...@yahoo.com wrote: with nodevice random I can no longer compile for MIPS --- kernel.debug --- pseudo_rng.o:(.data+0x3c): undefined reference to `random_null_func' pseudo_rng.o:(.data+0x44): undefined reference to `random_null_func' pseudo_rng.o:(.data+0x74): undefined reference to `random_null_func' pseudo_rng.o:(.data+0x78): undefined reference to `random_null_func' pseudo_rng.o:(.data+0x84): undefined reference to `random_null_func' pseudo_rng.o:(.data+0x8c): more undefined references to `random_null_func' follow random_adaptors.o: In function `random_sysctl_active_adaptor_handler': /home/sbruno/bsd/head/sys/dev/random/random_adaptors.c:(.text+0x40): undefined reference to `random_get_active_adaptor' /home/sbruno/bsd/head/sys/dev/random/random_adaptors.c:(.text+0x40): relocation truncated to fit: R_MIPS_26 against `random_get_active_adaptor' This is easy enough to fix. Doing a build now. trying to enable random on my DIR-825 kernconf I get this on boot: Configuration file: /etc/cfg/hostapd.wlan0.conf Using interface wlan0 with hwaddr 00:00:88:88:22:22 and ssid TESTBRUNO Entropy device is blocking. Can you please see if you can get the output of sysctl -a | grep random at that point? M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: random(4) update causes mips compile fail | mips boot fail
On 7 Sep 2013, at 17:43, Sean Bruno sean_br...@yahoo.com wrote: trying to enable random on my DIR-825 kernconf I get this on boot: Configuration file: /etc/cfg/hostapd.wlan0.conf Using interface wlan0 with hwaddr 00:00:88:88:22:22 and ssid TESTBRUNO Entropy device is blocking Please make a change to sys/dev/random/randomdev_soft.c; Around line 82, please change from .seeded = 0 to .seeded = 1. If that works, then your report above with the Entropy device is blocking. is trying to read random numbers before /dev/random is secure; this is a BAD security problem. M -- Mark R V Murray Entropy device is blocking signature.asc Description: Message signed with OpenPGP using GPGMail
Re: random(4) update causes mips compile fail | mips boot fail
On 7 Sep 2013, at 19:36, Sean Bruno sean_br...@yahoo.com wrote: On Sat, 2013-09-07 at 18:39 +0100, Mark R V Murray wrote: On 7 Sep 2013, at 17:43, Sean Bruno sean_br...@yahoo.com wrote: trying to enable random on my DIR-825 kernconf I get this on boot: Configuration file: /etc/cfg/hostapd.wlan0.conf Using interface wlan0 with hwaddr 00:00:88:88:22:22 and ssid TESTBRUNO Entropy device is blocking Please make a change to sys/dev/random/randomdev_soft.c; Around line 82, please change from .seeded = 0 to .seeded = 1. If that works, then your report above with the Entropy device is blocking. is trying to read random numbers before /dev/random is secure; this is a BAD security problem. M Looks like it does indeed work if that is set to 1. This DIR-825 config, should be loading random as a module, not built into the kernel due to size limitations of the kernel on this board. Hmm. I'll set it back to 1, but this is technically a security issue. Thanks for the report back, and sorry for the hassles! M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: random(4) update causes mips compile fail | mips boot fail
On 7 Sep 2013, at 19:49, Sean Bruno sean_br...@yahoo.com wrote: On Sat, 2013-09-07 at 19:40 +0100, Mark R V Murray wrote: Looks like it does indeed work if that is set to 1. This DIR-825 config, should be loading random as a module, not built into the kernel due to size limitations of the kernel on this board. Hmm. I'll set it back to 1, but this is technically a security issue. Thanks for the report back, and sorry for the hassles! M -- Mark R V Murray Ok. Right now, the mips kernel doesn't build unless I have random built in, we were using it as a module previously. I'm testing a fix, but if you want to help out, please move the random_null_func() from randomdev.c to pseudo_rng.c in sys/dev/random. Patch enclosed. Thanks! M -- Mark R V Murray rng_fix.patch Description: Binary data signature.asc Description: Message signed with OpenPGP using GPGMail
Re: random(4) update causes mips compile fail | mips boot fail
On 7 Sep 2013, at 20:12, Sean Bruno sean_br...@yahoo.com wrote: On Sat, 2013-09-07 at 19:56 +0100, Mark R V Murray wrote: Ok. Right now, the mips kernel doesn't build unless I have random built in, we were using it as a module previously. I'm testing a fix, but if you want to help out, please move the random_null_func() from randomdev.c to pseudo_rng.c in sys/dev/random. Patch enclosed. Thanks! M Closer: --- kernel.debug --- linking kernel.debug random_adaptors.o: In function `random_sysctl_active_adaptor_handler': /home/sbruno/bsd/head/sys/dev/random/random_adaptors.c:(.text+0x2dc): undefined reference to `random_get_active_adaptor' /home/sbruno/bsd/head/sys/dev/random/random_adaptors.c:(.text+0x2dc): relocation truncated to fit: R_MIPS_26 against `random_get_active_adaptor' *** [kernel.debug] Error code 1 Nearly there - I saw that too. Proposed fix enclosed. M -- Mark R V Murray rng_fix.patch Description: Binary data signature.asc Description: Message signed with OpenPGP using GPGMail
Re: random(4) update causes mips compile fail | mips boot fail
On 7 Sep 2013, at 21:42, Adrian Chadd adr...@freebsd.org wrote: We discussed this at the dev summit. Mark asked what we'd like to do. Mark - would you mind terribly adding a kernel compile option that controls that blocking default, so we can flip it on for the ARM/MIPS boards that don't have a hardware PRNG to start seeding things with? This has some merit; but I need to thing about how to do it. Per-architecture block/no-block defaults are going to get messy unless done properly. M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: random(4) update causes mips compile fail | mips boot fail
On 7 Sep 2013, at 21:38, Ian Lepore i...@freebsd.org wrote: I keep trying to say this, and I keep getting the feeling that it just doesn't register with anyone I say it to, like I'm speaking some language from another planet or something... Sorry. I haven't forgotten this. Right now, for 10.0, the intent is Fix the bugs first. The all-singing variant is going to follow. There may be NO entropy of any sort available on an embedded system, and you cannot block the ability to boot and run such a system just because you think it's a bad idea to run without sufficient randomness. It's not your call to make -- it's a decision for the person using or administering the system. True. But the current fix for this (AKA the status quo) means that things are broken for everyone, and I'm trying to get things fixed by default with some kind of workaround for the folks that need it, rather than the other way round. You must provide a mechanism that disables the blocking behavior. The mechanism must be either a kernel compile-time config knob (not all platforms use loader(8) or anything else that can set a tunable var), or something in the rc system that can unblock /dev/random before anything else needs it. The latter implies that the kernel itself must not block before getting to that point in rc processing, even if it needs random numbers for something (like cooking up a temporary MAC address). Any kind of write to /dev/random (Yarrow) will unblock it. This may be a matter of scripting in /etc/rc.d/something. Like echo '' /dev/random, and it just needs to happen early enough, i.e. before you do a blocking read. It's okay to make it hard to do the wrong thing by accident. It's not okay to make it impossible to do that thing on purpose. Again, true, but please bear in mind that things are suboptimal right now. M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: random(4) update causes mips compile fail | mips boot fail
On 7 Sep 2013, at 22:31, Ian Lepore i...@freebsd.org wrote: Those of us who have to cope with limited systems will fix our config for those systems; that part of it shouldn't be your problem beyond providing us with a knob. If there is NO random number generator, then /dev/random blocks. Period. If you don't want to block, don't read /dev/random. If you have an RNG loaded (like Yarrow), the intent is that it will block-until-secure, but you can insta-unblock it by writing to it. The intent is that early in the boot, while running all the /etc/rc.d/* stuff, you write anything you like (hopefully random crud) to the device and it seeds itself with what it gets. At file close after the write, it unblocks. So at the minimum, you can unblock Yarrow by doing $ echo '' /dev/random ... as soon as the device is active. There is your knob. M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
