Re: svn commit: r339492 - head/sys/dev/random
> On 20 Oct 2018, at 22:09, Conrad Meyer wrote: > > Author: cem > Date: Sat Oct 20 21:09:12 2018 > New Revision: 339492 > URL: https://svnweb.freebsd.org/changeset/base/339492 > > Log: > Fortuna: ... ... and a few others. Thanks, Conrad, for picking these up! Having code reviewed well is a good feeling :-) M -- ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r317015 - in head/sys: boot/forth conf crypto/chacha20 dev/random libkern sys
> On 16 Apr 2017, at 20:26, Dag-Erling Smørgrav <d...@des.no> wrote: > > Mark Murray <ma...@freebsd.org> writes: >> Added: >> head/sys/crypto/chacha20/chacha.c (contents, props changed) >> head/sys/crypto/chacha20/chacha.h (contents, props changed) > > Really? You committed this code despite having been informed of its > dubious legal status, and despite knowing full well that another > implementation was already available? "Dubious legal status"? Please go and look at the chacha that OpenSSH uses. You will find it strangely familiar. You informed me *that* you had written another implementation. You didn't inform me *when* you were going to pull the trigger. The time between warning me and committing was a shade over 2 hours. The fact that 1) yours is optional (arc4random needs standard) 2) your API is incompatible and 3) both code-sets can co-exist without conflict means that there is no technical problem, except for the time taken adapt to your API and bikeshed out the module "standard" vs "optional" status. Oh, and the time to retest everything. In the past you have made me wait *months* to make changes to my own code. Your commit took 2 *hours* between first warning of commit and it hitting the tree. You can't say you didn't know my commit was imminent. I had just gotten a green light from the SO a day or so before. Here's the timeline: 18th March: I open D10048 - a change that replaces RC4 with ChaCha as underlying algorithm for arc4random(9). I choose the OpenSSH copy of chacha.c. 21st March: A brief exchange of emails where DES' Chacha is announced as existing. No timeline for its committal is discussed. Fri 14th April, 2:58: SO Green-lights my commit after a few rounds of changes and discussion. Sat 14th April, 17:45: DES Adds himself to the reviewer list of D10048 for the first time and makes this comment "Please allow me some time to commit my Chacha20 implementation first so we can use that instead of the legally dubious version which is included in this patch. I hit a snag that I haven't had time to debug, but I'm hoping to have it done by Tuesday." Sat 14th April, 19:54: DES make this comment: "Turns out the snag was that I was loading the wrong version of the module. I have committed it now (r316982). If anyone is interested, I have a version that includes test vectors and runs self-tests when loaded, but I removed them from the final version as they are about six times larger than the actual code." DES - are you kidding me??! 2 hours 9 minutes warning? I already had a green light; I wan't watching Phabricator, I was prepping my commit! "Please allow me some time", then you drop your warning from 3 days to 2 hours! M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r317015 - in head/sys: boot/forth conf crypto/chacha20 dev/random libkern sys
> On 16 Apr 2017, at 15:26, Conrad Meyer <c...@freebsd.org> wrote: > * I believe you've taken the right approach. But somehow your import > of chacha should be reconciled with DES' import (i.e., keep only one > copy in the tree). > * I don't believe the chacha code being standard is an undue burden. > Especially balanced by kicking out RC4. This is the way I'd like to see things go. > Thanks for doing this work. You are most welcome! M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r317015 - in head/sys: boot/forth conf crypto/chacha20 dev/random libkern sys
> On 16 Apr 2017, at 17:04, Rodney W. Grimes <free...@pdx.rh.cn85.dnsmgr.net> > wrote: > So you can understand me being started when any of this arrived? I am > on several of the mailling list, and I think -security is probably one > of them. I was thoroughly ignored last time I tried to use -security. It was, however, a while back. I'll try again. > What watch list is this? And do we have a watch list that is just "New > Phabricator > created" so we can make just that incident go to some mailling list so people > stop > getting caught off guard by commits that have been reviews that they wish > they had > even known there was a review? We just need a way for being allerted there > is a > new review that we *might* be interested, or care to participate in without > being > on all the watch lists. There is 'secteam' on Phabricator. > And to add my hidden Blue Paint, we need to stop fearing the bike shed, the > project > seems to have stifled the communications process to the point it is becoming a > closed door shop with everyone working in secret then dumping a commit in > once they > are done. Yes, bike sheds are a bit time consuming, but so is duplicate work > cause > you had no idea someone else was working in the same area (your LKM suprize is > an excellent example). > We must stop working in vacuums and start to communicate, and if that means we > have a few bike sheds... well.. paints on me (though I reserve the blue for > personal use!) Can't please everybody, but I'll add -security to the list next time. There is a fair bit of history that predates your return to the project; me getting attention to folks prepared to do reviews is a sore point. I use Phabricator because it works for me (I get reviews). I was largely ignored on the mailing lists last time I had a big commit. M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r317015 - in head/sys: boot/forth conf crypto/chacha20 dev/random libkern sys
> On 16 Apr 2017, at 15:21, Rodney W. Grimes <free...@pdx.rh.cn85.dnsmgr.net> > wrote: >>>> RC4 has been standard for many years. >>> Probably another rapid mode of design rather than a thoughful mode, we >>> have a chance to correct this here, and imho, should. >> >> Fix it, sure. What's wrong with doing that as a next step? Why does this >> change need to be held to ransom? > > Thats a fair point, let me counter, why do I want this change at all? RC4 is broken cryptographically. FreeBSD was lagging behind in still using it. > Is it just the new kid on the block and everyone wants to play with the > new toy, or does it bring the users some wonderful star bright feature > that they just can not live without? Is arc4random(9) some how fundementaly > broken without chacha? Most folks won't notice a darn thing. Crap random numbers are very often hard to tell apart from good ones, and if you are not depending on them in a relevant way you won't notice anything. The big deal is that the attack vector for folks counting on (broken) RC4 is now gone. For most FreeBSD users this is theoretical interest only. > Your code in and working now? Yes. > We just have 2 implementations of chacha, correct? Correct. > One in your static compiled in kernel section, and one as an LKM? Correct. The latter startled me when it arrived. >>>> Up until now, arc4random worked with unconditional RC4. >>> >>> And your wanting to just replace unconditional RC4 for unconditional chacha? >>> Or actuall, aleady did? >> >> Correct. Both counts. It was up on Phabricator for weeks, BTW. > > We are having what I believe is a very serious disjoint in project > communications > caused by phabricator. How are the developers notified of new things going > up in phabricator? I get bugzilla reports, but I get zip from phabriactor > unless > I go ask it for stuff. I get #network stuff cause I saw that in a commit > that > I would of liked to been aware of early and added into that project, but > overall > I think we need to work on this communcations too. True. I promised SO@ that I would get all my CSPRNG stuff reviewed in Phabricator before committing it. All the folks who in the past have cared about my work now are on the relevant watch-list. Apart from spamming everyone, what do you suggest? M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r317015 - in head/sys: boot/forth conf crypto/chacha20 dev/random libkern sys
> On 16 Apr 2017, at 13:30, Rodney W. Grimes <free...@pdx.rh.cn85.dnsmgr.net> > wrote: > >> The RC4 algorithm is standard. Making the alogorithm pluggable means more >> code, more testing and more time (time which I am rather short of). > > I would rather see a proper implementation later, than a poor design > decision today. I would love to see a perfect solution too. As I don't have the time for it, I took the time to get a working solution reviewed and pretty heavily tested. Reviewed by SO@, that is. >>> Also you can always compile in a module, you can not compile out >>> a 'standard' file. >>> >>> For now could you just add >>> options chacha #Required by arc4random, do not remove >>> to your kernel and move on? For me this would be an acceptable >>> developement, even releasable, way to proceed while the more >>> complex issue of how to make the kernel RNG use plagable lkm >>> lower layers. >> >> It would have to be unconditionally added to *all* kernels. Could be >> done, I guess. > > We dont have that many in base kernel configs do we? No. But what about folks' own configs that break all-of-a-sudden? I've been pretty angry n a few occasions when I'm trying to fix my own problems and I had to waste time sorting out tangential, avoidable problems. What's the difference between making this 'standard' in sys/files/conf and adding a compulsory change to ALL kernel files (apart from the fact that we miss the users' kernel configs)? We can even keep the module stubs in the code. Later, when/if arc4random(9) becomes a loadable module (I'd *LOVE* to see how we get that right without compromising the RNG early start), we can make it optional. That is a one line change to sys/conf/files. >> RC4 has been standard for many years. > Probably another rapid mode of design rather than a thoughful mode, we > have a chance to correct this here, and imho, should. Fix it, sure. What's wrong with doing that as a next step? Why does this change need to be held to ransom? >> Up until now, arc4random worked with unconditional RC4. > > And your wanting to just replace unconditional RC4 for unconditional chacha? > Or actuall, aleady did? Correct. Both counts. It was up on Phabricator for weeks, BTW. M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r317015 - in head/sys: boot/forth conf crypto/chacha20 dev/random libkern sys
> On 16 Apr 2017, at 13:07, Rodney W. Grimes <free...@pdx.rh.cn85.dnsmgr.net> > wrote: > >>> From replacing the rc4 algorithm with chacha20, this chalice has now >> become poisoned with the job of redesigning the entire structure of >> kernel random-number generation. >> >> This may take a while, and I'm already behind on RNG jobs. > > I do not see how this is a complete redesign of RNG, and if it is > such a heart ache to change algorithms in this code then it probably > should be redesigned? The RC4 algorithm is standard. Making the alogorithm pluggable means more code, more testing and more time (time which I am rather short of). > Also you can always compile in a module, you can not compile out > a 'standard' file. > > For now could you just add > options chacha #Required by arc4random, do not remove > to your kernel and move on? For me this would be an acceptable > developement, even releasable, way to proceed while the more > complex issue of how to make the kernel RNG use plagable lkm > lower layers. It would have to be unconditionally added to *all* kernels. Could be done, I guess. RC4 has been standard for many years. >>> I am sure with careful though we can find a way to allow arc4random >>> to use a pointer that knows if the chacha code is avaliable, and use >>> it if so, and if not fall back to something else, or punt with an >>> error return. >> >> Error return is out of the question; arc4random() is pretty fundamental. >> The alternative is to return no or fake random numbers, which rather >> misses the point of what this is for. But it can be done. > > Arc4random works today without chacha, why would adding support for chache > as an optional loadable function break that? *truely confused* Up until now, arc4random worked with unconditional RC4. M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r317015 - in head/sys: boot/forth conf crypto/chacha20 dev/random libkern sys
> On 16 Apr 2017, at 12:50, Rodney W. Grimes <free...@pdx.rh.cn85.dnsmgr.net> > wrote: > >> This does not use DES' Chacha20 commit, as I had already completed the >> testing for it, and received SO@ approval. >> >> DES's commit made Chaha20 a module. This is of no use to arc4random(9), >> which needs the code to be standard. Also his API is different. >> >> I have no objection to reworking the arc4random/Chacha below to use DES' >> version of Chacha, but his code needs to be standard library code, >> not an optional module. >> >> Any objections to me doing this? > > Yes > > We need to move towards more modules, not less. Having this standard > does not even allow one to compile a kernel without it. I should be > able to compile a kernel without arc4random(9) and without chacha if > I so desire. And I should be able to load and unload these if I so > desire. This later feature is VERY usefull for developement and > debug cycles. >From replacing the rc4 algorithm with chacha20, this chalice has now become poisoned with the job of redesigning the entire structure of kernel random-number generation. This may take a while, and I'm already behind on RNG jobs. > I am sure with careful though we can find a way to allow arc4random > to use a pointer that knows if the chacha code is avaliable, and use > it if so, and if not fall back to something else, or punt with an > error return. Error return is out of the question; arc4random() is pretty fundamental. The alternative is to return no or fake random numbers, which rather misses the point of what this is for. But it can be done. M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r317015 - in head/sys: boot/forth conf crypto/chacha20 dev/random libkern sys
U8TO32_LITTLE(m + 4));
> +x2 = XOR(x2,U8TO32_LITTLE(m + 8));
> +x3 = XOR(x3,U8TO32_LITTLE(m + 12));
> +x4 = XOR(x4,U8TO32_LITTLE(m + 16));
> +x5 = XOR(x5,U8TO32_LITTLE(m + 20));
> +x6 = XOR(x6,U8TO32_LITTLE(m + 24));
> +x7 = XOR(x7,U8TO32_LITTLE(m + 28));
> +x8 = XOR(x8,U8TO32_LITTLE(m + 32));
> +x9 = XOR(x9,U8TO32_LITTLE(m + 36));
> +x10 = XOR(x10,U8TO32_LITTLE(m + 40));
> +x11 = XOR(x11,U8TO32_LITTLE(m + 44));
> +x12 = XOR(x12,U8TO32_LITTLE(m + 48));
> +x13 = XOR(x13,U8TO32_LITTLE(m + 52));
> +x14 = XOR(x14,U8TO32_LITTLE(m + 56));
> +x15 = XOR(x15,U8TO32_LITTLE(m + 60));
> +
> +j12 = PLUSONE(j12);
> +if (!j12) {
> + j13 = PLUSONE(j13);
> + /* stopping at 2^70 bytes per nonce is user's responsibility */
> +}
> +
> +U32TO8_LITTLE(c + 0,x0);
> +U32TO8_LITTLE(c + 4,x1);
> +U32TO8_LITTLE(c + 8,x2);
> +U32TO8_LITTLE(c + 12,x3);
> +U32TO8_LITTLE(c + 16,x4);
> +U32TO8_LITTLE(c + 20,x5);
> +U32TO8_LITTLE(c + 24,x6);
> +U32TO8_LITTLE(c + 28,x7);
> +U32TO8_LITTLE(c + 32,x8);
> +U32TO8_LITTLE(c + 36,x9);
> +U32TO8_LITTLE(c + 40,x10);
> +U32TO8_LITTLE(c + 44,x11);
> +U32TO8_LITTLE(c + 48,x12);
> +U32TO8_LITTLE(c + 52,x13);
> +U32TO8_LITTLE(c + 56,x14);
> +U32TO8_LITTLE(c + 60,x15);
> +
> +if (bytes <= 64) {
> + if (bytes < 64) {
> +for (i = 0;i < bytes;++i) ctarget[i] = c[i];
> + }
> + x->input[12] = j12;
> + x->input[13] = j13;
> + return;
> +}
> +bytes -= 64;
> +c += 64;
> +m += 64;
> + }
> +}
>
> Added: head/sys/crypto/chacha20/chacha.h
> ==
> --- /dev/null 00:00:00 1970 (empty, because file is newly added)
> +++ head/sys/crypto/chacha20/chacha.h Sun Apr 16 09:11:02 2017
> (r317015)
> @@ -0,0 +1,32 @@
> +/* $OpenBSD: chacha.h,v 1.4 2016/08/27 04:04:56 guenther Exp $ */
> +
> +/*
> +chacha-merged.c version 20080118
> +D. J. Bernstein
> +Public domain.
> +
> + $FreeBSD$
> +*/
> +
> +#ifndef CHACHA_H
> +#define CHACHA_H
> +
> +#include
> +
> +struct chacha_ctx {
> + u_int input[16];
> +};
> +
> +#define CHACHA_MINKEYLEN 16
> +#define CHACHA_NONCELEN 8
> +#define CHACHA_CTRLEN8
> +#define CHACHA_STATELEN (CHACHA_NONCELEN+CHACHA_CTRLEN)
> +#define CHACHA_BLOCKLEN 64
> +
> +void chacha_keysetup(struct chacha_ctx *x, const u_char *k, u_int kbits);
> +void chacha_ivsetup(struct chacha_ctx *x, const u_char *iv, const u_char
> *ctr);
> +void chacha_encrypt_bytes(struct chacha_ctx *x, const u_char *m,
> +u_char *c, u_int bytes);
> +
> +#endif /* CHACHA_H */
> +
>
> Modified: head/sys/dev/random/random_harvestq.c
> ==
> --- head/sys/dev/random/random_harvestq.c Sun Apr 16 09:00:10 2017
> (r317014)
> +++ head/sys/dev/random/random_harvestq.c Sun Apr 16 09:11:02 2017
> (r317015)
> @@ -352,10 +352,19 @@ random_harvestq_prime(void *unused __unu
>* Get entropy that may have been preloaded by loader(8)
> * and use it to pre-charge the entropy harvest queue.
>*/
> - keyfile = preload_search_by_type(RANDOM_HARVESTQ_BOOT_ENTROPY_FILE);
> + keyfile = preload_search_by_type(RANDOM_CACHED_BOOT_ENTROPY_MODULE);
> +#ifndef NO_BACKWARD_COMPATIBILITY
> + if (keyfile == NULL)
> + keyfile = preload_search_by_type(RANDOM_LEGACY_BOOT_ENTROPY_MODULE);
> +#endif
> if (keyfile != NULL) {
> data = preload_fetch_addr(keyfile);
> size = preload_fetch_size(keyfile);
> + /* skip the first bit of the stash so others like arc4 can also
> have some. */
> + if (size > RANDOM_CACHED_SKIP_START) {
> + data += RANDOM_CACHED_SKIP_START;
> + size -= RANDOM_CACHED_SKIP_START;
> + }
> /* Trim the size. If the admin has a file with a funny size, we
> lose some. Tough. */
> size -= (size % sizeof(event.he_entropy));
> if (data != NULL && size != 0) {
>
> Modified: head/sys/dev/random/random_harvestq.h
> ==
> --- head/sys/dev/random/random_harvestq.h Sun Apr 16 09:00:10 2017
> (r317014)
> +++ head/sys/dev/random/random_harvestq.h Sun Apr 16 09:11:02 2017
> (r317015)
> @@ -1,5 +1,5 @@
> /*-
> - * Copyright (c) 20
Re: svn commit: r316982 - in head/sys: conf crypto/chacha20 modules modules/chacha20
> On 15 Apr 2017, at 21:51, Dag-Erling Smørgrav <d...@freebsd.org> wrote: > > Author: des > Date: Sat Apr 15 20:51:53 2017 > New Revision: 316982 > URL: https://svnweb.freebsd.org/changeset/base/316982 > > Log: > 3BSD-licensed implementation of the chacha20 stream cipher, intended for > use by the upcoming arc4random replacement. > > Added: > head/sys/crypto/chacha20/ > head/sys/crypto/chacha20/chacha20.c (contents, props changed) > head/sys/crypto/chacha20/chacha20.h (contents, props changed) > head/sys/modules/chacha20/ > head/sys/modules/chacha20/Makefile (contents, props changed) > Modified: > head/sys/conf/files > head/sys/modules/Makefile This is a loadable module, unlike the RC4 code which it needs to replace, and which is standard. Making it loadable makes no sense in the context of arc4random(9). Do you mind if I strip out the module bits in order to get my arc4random(9) commit completed? M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r303035 - in head/sys: arm/broadcom/bcm2835 boot/fdt/dts/arm sys
stall");
> +#ifdef BCM2835_RNG_DEBUG_REGISTERS
> + SYSCTL_ADD_PROC(sysctl_ctx, SYSCTL_CHILDREN(sysctl_tree), OID_AUTO,
> + "dumpregs", CTLTYPE_STRING | CTLFLAG_RD, sc, 0,
> + sysctl_bcm2835_rng_dump, "S", "Dump RNG registers");
> +#endif
> +
> +#if defined(BCM2835_RNG_USE_CALLOUT)
> + /* Reset callout */
> + if (hz >= 100)
> + sc->sc_rnghz = hz / 100;
> + else
> + sc->sc_rnghz = 1;
> + callout_reset(>sc_rngto, sc->sc_rnghz, bcm2835_rng_harvest, sc);
> +#endif
> +
> + return (0);
> +}
> +
> +static int
> +bcm2835_rng_detach(device_t dev)
> +{
> + struct bcm2835_rng_softc *sc;
> +#if defined(BCM2835_RNG_USE_INTERRUPT)
> + int error;
> +#endif
> +
> + sc = device_get_softc(dev);
> +
> + /* Stop the RNG */
> + bcm2835_rng_stop(sc);
> +
> + /* Drain the callout it */
> +#if defined(BCM2835_RNG_USE_CALLOUT)
> + callout_drain(>sc_rngto);
> +#endif
> +
> +#if defined(BCM2835_RNG_USE_INTERRUPT)
> + /* Tear down the interrupt */
> + if (sc->sc_irq_res && sc->sc_intr_hdl) {
> + error = bus_teardown_intr(dev, sc->sc_irq_res, sc->sc_intr_hdl);
> + if (error != 0) {
> + device_printf(dev, "could not tear down IRQ\n");
> + return (error);
> + }
> + sc->sc_intr_hdl = NULL;
> + }
> +
> + /* Release interrupt resource */
> + if (sc->sc_irq_res) {
> + bus_release_resource(dev, SYS_RES_IRQ, 0, sc->sc_irq_res);
> + sc->sc_irq_res = NULL;
> + }
> +#endif
> +
> + /* Release memory resource */
> + if (sc->sc_mem_res != NULL)
> + bus_release_resource(dev, SYS_RES_MEMORY, 0, sc->sc_mem_res);
> +
> + return (0);
> +}
> +
> +static device_method_t bcm2835_rng_methods[] = {
> + /* Device interface */
> + DEVMETHOD(device_probe, bcm2835_rng_probe),
> + DEVMETHOD(device_attach,bcm2835_rng_attach),
> + DEVMETHOD(device_detach,bcm2835_rng_detach),
> +
> + DEVMETHOD_END
> +};
> +
> +static driver_t bcm2835_rng_driver = {
> + "bcmrng",
> + bcm2835_rng_methods,
> + sizeof(struct bcm2835_rng_softc)
> +};
> +static devclass_t bcm2835_rng_devclass;
> +
> +DRIVER_MODULE(bcm2835_rng, simplebus, bcm2835_rng_driver,
> +bcm2835_rng_devclass, 0, 0);
> +DRIVER_MODULE(bcm2835_rng, ofwbus, bcm2835_rng_driver, bcm2835_rng_devclass,
> 0,
> +0);
> +MODULE_VERSION(bcm2835_rng, 1);
> +MODULE_DEPEND(bcm2835_rng, randomdev, 1, 1, 1);
>
> Modified: head/sys/arm/broadcom/bcm2835/files.bcm283x
> ==
> --- head/sys/arm/broadcom/bcm2835/files.bcm283x Tue Jul 19 18:05:25
> 2016(r303034)
> +++ head/sys/arm/broadcom/bcm2835/files.bcm283x Tue Jul 19 18:07:47
> 2016(r303035)
> @@ -10,6 +10,7 @@ arm/broadcom/bcm2835/bcm2835_gpio.c opt
> arm/broadcom/bcm2835/bcm2835_intr.c standard
> arm/broadcom/bcm2835/bcm2835_machdep.cstandard
> arm/broadcom/bcm2835/bcm2835_mbox.c standard
> +arm/broadcom/bcm2835/bcm2835_rng.c optional random
> arm/broadcom/bcm2835/bcm2835_sdhci.c optional sdhci
> arm/broadcom/bcm2835/bcm2835_spi.coptional bcm2835_spi
> arm/broadcom/bcm2835/bcm2835_vcio.c standard
>
> Modified: head/sys/boot/fdt/dts/arm/bcm2835.dtsi
> ==
> --- head/sys/boot/fdt/dts/arm/bcm2835.dtsiTue Jul 19 18:05:25 2016
> (r303034)
> +++ head/sys/boot/fdt/dts/arm/bcm2835.dtsiTue Jul 19 18:07:47 2016
> (r303035)
> @@ -396,6 +396,14 @@
> };
> };
>
> + rng {
> + compatible = "broadcom,bcm2835-rng",
> + "broadcom,bcm2708-rng";
> + reg = <0x104000 0x20>;
> + interrupts = <69>;
> + interrupt-parent = <>;
> + };
> +
> bsc0 {
> #address-cells = <1>;
> #size-cells = <0>;
>
> Modified: head/sys/boot/fdt/dts/arm/bcm2836.dtsi
> ==
> --- head/sys/boot/fdt/dts/arm/bcm2836.dtsiTue Jul 19 18:05:25 2016
> (r303034)
> +++ head/sys/boot/fdt/dts/arm/bcm2836.dtsiTue Jul 19 18:07:47 2016
> (r303035)
> @@ -389,6 +389,14 @@
> };
> };
>
> + rng {
> + compatible = "broadcom,bcm2835-rng",
> + "broadcom,bcm2708-rng";
> + reg = <0x104000 0x20>;
> + interrupts = <69>;
> + interrupt-parent = <>;
> + };
> +
> bsc0 {
> #address-cells = <1>;
> #size-cells = <0>;
>
> Modified: head/sys/sys/random.h
> ==
> --- head/sys/sys/random.h Tue Jul 19 18:05:25 2016(r303034)
> +++ head/sys/sys/random.h Tue Jul 19 18:07:47 2016(r303035)
> @@ -90,6 +90,7 @@ enum random_entropy_source {
> RANDOM_PURE_NEHEMIAH,
> RANDOM_PURE_RNDTEST,
> RANDOM_PURE_VIRTIO,
> + RANDOM_PURE_BROADCOM,
> ENTROPYSOURCE
> };
>
>
--
Mark R V Murray
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: svn commit: r286984 - head/sys/modules/zfs
On 21 Aug 2015, at 09:20, Andriy Gapon a...@freebsd.org wrote: Precisely because it's the standalone build (cd sys/modules/zfs make ...) that was affected. Building the module as a part of the kernel build worked just fine. That makes sense. Now I need a regression test to ensure at this problem is not elsewhere and doesn’t return. Where do folks put these? I don’t mind writing one. M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r286984 - head/sys/modules/zfs
Thanks!
I’ve been running “make universe” here as a build-test. I wonder why this was
not picked up?
M
On 21 Aug 2015, at 09:06, Andriy Gapon a...@freebsd.org wrote:
Author: avg
Date: Fri Aug 21 08:06:18 2015
New Revision: 286984
URL: https://svnweb.freebsd.org/changeset/base/286984
Log:
fix standalone build of zfs module
Not sure if this is a proper fix, but it does the job.
Modified:
head/sys/modules/zfs/Makefile
Modified: head/sys/modules/zfs/Makefile
==
--- head/sys/modules/zfs/Makefile Fri Aug 21 08:04:56 2015
(r286983)
+++ head/sys/modules/zfs/Makefile Fri Aug 21 08:06:18 2015
(r286984)
@@ -4,7 +4,7 @@ SYSDIR?=${.CURDIR}/../..
KMOD= zfs
-SRCS=bus_if.h device_if.h vnode_if.h opt_kstack_pages.h
+SRCS=bus_if.h device_if.h vnode_if.h opt_kstack_pages.h opt_random.h
SUNW= ${SYSDIR}/cddl/contrib/opensolaris
--
Mark R V Murray
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r284959 - in head: . share/man/man4 share/man/man9 sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe sys/dev/syscons sys/dev/ubsec sys/dev/virtio/random s
On 2 Jul 2015, at 00:07, Simon J. Gerraty s...@juniper.net wrote: Mark Murray ma...@freebsd.org wrote: * src/sys/dev/random/random_adaptors.c src/sys/dev/random/random_adaptors.h - Remove; plugability is no longer used. Compile-time algorithm selection is the way to go. Errr we use that and need it. Please put it back. Whether we agree with NIST's ideas about how randomness should be handled or not, we need to to be able to comply and we do not want to burn their desired arrangement into our kernels. I’m nearly done with this. Please be patient for a few more days. Thanks! M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r284959 - in head: . share/man/man4 share/man/man9 sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe sys/dev/syscons sys/dev/ubsec sys/dev/virtio/random s
On 25 Jul 2015, at 06:06, Scott Long scott4l...@yahoo.com wrote: I’m working on a premise of “tools, not policy”. I’d like there to be enough harvesting points for the box owner to get the warm fuzzies. If they choose to use less, fine by me. Sure, and that’s not an unreasonable goal, but the devil is in the details. Yes, indeed! It’s an unfortunate fact of modern CPU architecture that even something as simple and innocent as a run-time control that checks a variable can cause significant performance problems, thanks to the penalty of cache misses and bus contention between lots of CPU cores. Maybe these “extended” collection points should be controlled with a compile-time option? They can. I’ve coded it already, but not tested it properly, and will commit in a week or two. :-) Many of the issues that FreeBSD sees with lack of entropy at start up is more of a problem on how systems are installed and provisioned. I don't believe that we currently store any entropy from the install process, yet this is one of the best places to get it, the user is banging on keyboard selecting options, etc. If an image is designed to be cloned (vm images or appliance images) we need to have a mechanism to ensure that before we start, we get the entropy from other sources, be it a hardware RNG or the console. Getting an initial entropy bundle for first boot is high up on my TODO list. :-) Patches welcome! We need the usual /entropy (or /var/db/entropy/… or whatever) and crucially we need /boot/entropy and the correct invocation in /boot/loader.conf. I agree that bootstrap entropy is a big deal, especially with the increasing prevalence of using virtual machine containers, cloned images, and datacenter automation. Addressing that is an interesting problem, and goes well beyond the scope of in-kernel entropy collection. I wish I had a simple answer or a patch for you ;-) The hard stuff has been done. We just need to write (e.g.) 4k of good numbers to /boot/entropy and job nearly done. This could be done by sysinstall or by the cloning system, for example. The embedded folks will still need a bit more careful etc/rc.d/* design. Well, sure, but what if you don’t have microphone? I want lots of choices, in anticipation of only a subset being usable. I still think that for most use cases where you have a high likelyhood of draining /dev/random of useful bits, you’re likely already on a tight budget for CPU cycles and you’ll probably just look to a hardware accelerator rather than sacrifice even more CPU cycles. At least, that’s what the nice sale people at Cavium and Intel tell me ;-) Sure, but I don’t trust them either. This is the professional mistrust of crypto, not an assertion of incompetence or malice. ;-) They do, however, fulfil a need, but I don’t like the idea of trusting a single source unless that source has been properly vetted. M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r284959 - in head: . share/man/man4 share/man/man9 sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe sys/dev/syscons sys/dev/ubsec sys/dev/virtio/random s
On 25 Jul 2015, at 07:26, John-Mark Gurney j...@funkthat.com wrote: Once you have enough useful bits in /dev/random, you can NEVER run out of useful bits from /dev/random... [Well, not quite NEVER, but not for a few millennia.] So is your position effectively anti-harvesting, or at least to turn off all harvesting after a certain time and never turn it on again? If so, we are pretty far apart philosophically. DJB’s position is interesting, but I am far from persuaded by it. M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r284959 - in head: . share/man/man4 share/man/man9 sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe sys/dev/syscons sys/dev/ubsec sys/dev/virtio/random s
On 25 Jul 2015, at 17:05, Scott Long scott4l...@yahoo.com wrote: What you posted this morning for review is a great start. Thanks for the productive conversation on this. :-) I will do the same/similar for networking and for file ATIME mods. What else causes grief for you? M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r284959 - in head: . share/man/man4 share/man/man9 sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe sys/dev/syscons sys/dev/ubsec sys/dev/virtio/random s
On 25 Jul 2015, at 18:46, John-Mark Gurney j...@funkthat.com wrote: Mark R V Murray wrote this message on Sat, Jul 25, 2015 at 09:22 +0100: On 25 Jul 2015, at 07:26, John-Mark Gurney j...@funkthat.com wrote: Once you have enough useful bits in /dev/random, you can NEVER run out of useful bits from /dev/random... [Well, not quite NEVER, but not for a few millennia.] So is your position effectively anti-harvesting, or at least to turn off all harvesting after a certain time and never turn it on again? No, I am not, I was just stating a fact of how CSPRNGs work that people keep forgetting… I think you need to consider the attack/recovery practicalities as well as the theory. I'm totally against massive collection that has minimal benefit, but massive performance costs... I raised this issue in the review and you still haven't disabled INODE collection, plus you admitted that you hadn't done benchmarks on the uma case… Are you following my conversation with ScottL? I’ve agreed this. It's way more important to have a good seed at first boot for your rng when you generate long term ssh keys and the like than it is to continually collecting high rate randomness from the system… And that is what the current setup achieves, or achieved. What I had set up was a high-rate collection to unlock the RNG, and the faster stuff was disabled at multi-user time. Unfortunately, even those remnants were too much for UMA, so they will be disabled more permanently. No worries - back to the design board! If so, we are pretty far apart philosophically. DJB???s position is interesting, but I am far from persuaded by it. What points are you not persuaded by? Are there any questions that I could get answers for that would persuade you to change your mind? The passage of time will do it, I think. I don’t see much overt support for this (I will look out for it), but crucially I’m not aware of a great deal agains it. Its just too, erm, individual right now. :-) I'm not against continually collecting entropy, I just don't think it needs to be high speed, or that frequent.. My suggestion is for a thread to run every few seconds to grovel around collecting some entropy, and adding it... Obviously low perf impact collection points like the keyboard should remain as that continues to one of the best sources (when active/available)… The position of the Fortuna authors is that harvesting should be fast enough to thwart attack, and attack is facilitated by reading. Thus a high-speed reader should be backed by a proportionally high-speed harvesting. For ScottL the randomness requirements are low-ish. For (say) a bank, they may be a lot higher, and I see no reason to deny them this if they have no high throughput requirements. M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r284959 - in head: . share/man/man4 share/man/man9 sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe sys/dev/syscons sys/dev/ubsec sys/dev/virtio/random s
On 25 Jul 2015, at 19:31, John-Mark Gurney j...@funkthat.com wrote: virtual machines have things like virtio_random, most embedded gadgets have an ADC that could be used... Appliances a little more difficult, but trusted computers probably have a hardware RNG anyways… You need to research this more carefully. Ask Ian Lepore about the paucity of entropy on his boxes. M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r284959 - in head: . share/man/man4 share/man/man9 sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe sys/dev/syscons sys/dev/ubsec sys/dev/virtio/random s
On 24 Jul 2015, at 02:25, John-Mark Gurney j...@funkthat.com wrote: I would like to point out that the goal of collecting large amounts is starting to fall out of favor, and I happen to agree with the likes of djb[1] that we don't need an infinite amount of entropy collected by the system. If the attacker can read out our RNG state, then we are already screwed due to many other vulns. I’m working on a premise of “tools, not policy”. I’d like there to be enough harvesting points for the box owner to get the warm fuzzies. If they choose to use less, fine by me. Many of the issues that FreeBSD sees with lack of entropy at start up is more of a problem on how systems are installed and provisioned. I don't believe that we currently store any entropy from the install process, yet this is one of the best places to get it, the user is banging on keyboard selecting options, etc. If an image is designed to be cloned (vm images or appliance images) we need to have a mechanism to ensure that before we start, we get the entropy from other sources, be it a hardware RNG or the console. Getting an initial entropy bundle for first boot is high up on my TODO list. :-) Patches welcome! We need the usual /entropy (or /var/db/entropy/… or whatever) and crucially we need /boot/entropy and the correct invocation in /boot/loader.conf. I would like to see us scale back the entropy collection, and replace it with something like scan the zone once an hour or something similar. Or do something dtrace style, where we nop/jmp the collection after we feel that the system has collected enough. Most of the current entropy gathering is just about invisible anyway. I think the above goes too far, but may be a useful way of enabling/disabling (say) UMA gathering on the fly. Heck, piping in mic data to /dev/random is a good way to seed the rng on many machines. Well, sure, but what if you don’t have microphone? I want lots of choices, in anticipation of only a subset being usable. M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r284959 - in head: . share/man/man4 share/man/man9 sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe sys/dev/syscons sys/dev/ubsec sys/dev/virtio/random s
On 24 Jul 2015, at 16:25, Ian Lepore i...@freebsd.org wrote: But keep in mind that loader(8) is optional and not used at all on some non-x86 systems. Duly noted. It’s on my TODO list to talk to you embedded folks about this. M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r284959 - in head: . share/man/man4 share/man/man9 sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe sys/dev/syscons sys/dev/ubsec sys/dev/virtio/random s
On 23 Jul 2015, at 14:45, Scott Long scott4l...@yahoo.com wrote: OK - I’m sold! I’ll make a kernel option defaulting to off. :-) Hi Mark, Thanks for making this concession. I wanted to add a bit of historical perspective. When Yarrow was introduced in the previous decade, it was initially wired into nearly all interrupt sources. It turned out to be so expensive to those sources, especially for high-speed sources at the time like network and caching RAID drivers, that we then spent months disabling it from those sources. In the end, a lot of code thrash happened and the effectiveness of Yarrow was questionable. OK. OUCH. I wish I’d known this earlier, or, if I *was* told, I wish I’d paid a bit more attention. :-] In a nod towards efficiency, I have supplied graded (*_fast(), *_queue(), *_direct()) harvesting types, but it would appear that these are insufficient for your purposes. No problem, I’m glad we could come to another compromise! Fast forward to now with your recent work. If UMA becomes expensive for high-speed use, everyone will go back to developing private per-driver and per-subsystem allocators to avoid it. This will happen whether or not the UMA collector is controllable at run-time; if it’s enabled by default, benchmarks will be impacted and people will react. That’ll be a huge step backwards for FreeBSD. Understood, and thanks. If you have any suitable benchmark code that I could have, please, I’d be very grateful. I also strongly agree with Jeff’s point on the questionable nature of this kind of fast-and-monotonic entropy collection, and Warner and Kip’s point on the finite number of clock cycles available for doing 100Gb networking. If really high quality entropy is desired, won’t most serious people use a hardware source instead of a software source? Not that I think that software entropy is useless, but it’s a question of how much effort and tradeoffs are put into it for what result. An academically beautiful entropy system that hamstrings the OS from doing other essential things isn’t all that interesting, IMO. I am kinda hoping to be useful for everybody without being a nuisance. Fortuna (and Yarrow) work best with diverse sources of entropy, and we have declared our distrust in single sources (thanks Snowden!). Thus it is good to mix as much as possible. Now your requirements may not be as strong as the next fellow’s so disabling some sources would be a reasonable idea. I trust this direction will work better for more folks? M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r284959 - in head: . share/man/man4 share/man/man9 sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe sys/dev/syscons sys/dev/ubsec sys/dev/virtio/random s
On 23 Jul 2015, at 18:30, Alexey Dokuchaev da...@freebsd.org wrote: [ Guys, please teach your MUA to wrap messages over 72-76 boundary and trim excessive/irrelevant quoting, thank you. ] Oops sorry! So far it looks like this to me (having read no papers): 1) Fortuna attempts to get the most entropy from all available sources, trusting none of them. (Which is good.) Accurate. 2) Some of them might/will cause unwanted performance loss under certain circumstances, which becomes a show-stopper (finite number of clock cycles available, etc.) for some use cases. Again accurate. If Fortuna is so flexible, why can't some of its sources be conditionally disabled (kernel option/boot.conf/systct) or down-weighted through some more sophisticated, self-adjusting configuration technique during runtime? This is already present, but some if these checks, while very cheap, are still too expensive in very high-performance areas of the code. How dynamic it is? Mark, is there a (algorithmically?) reliable way to tell how many bits of good entropy is being added to the pool, and then tune the harvesting strategy accordingly? No. Not an absolute “no”, but The Yarrow algorithm required this, and it was never implemented satisfactorily by anyone due to its difficulty. Yarrow is now no longer supported by its authors due to this, amongst other problems. Is there some sort of restricted, private API to get a clue about current entropy status? Sort of. By turning on the RANDOM_DEBUG option, Fortuna will periodically print out the “message lengths” of all 32 accumulation pools. These are very vaguely indicative of the accumulated entropy. Pool[0] is used for reseeding; the rest are there for my interest and will be removed at some point. M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r284959 - in head: . share/man/man4 share/man/man9 sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe sys/dev/syscons sys/dev/ubsec sys/dev/virtio/random s
On 23 Jul 2015, at 00:53, Warner Losh i...@bsdimp.com wrote: Neither filesystem operations nor allocations are random events. They are trivially influenced by user code. A malicious attacker could create repeated patterns of allocations or filesystem activity through the syscall path to degrade your random sample source. I?m not sure I accept that - Fortuna is very careful about using non-reversible hashing in it?s accumulation, and countering such degradation is one of the algorithm?s strong points. There is perhaps risk of *no* entropy, but even the per-event timing jitter will be providing this, if nothing else. I’m not sure I’m happy about this answer. Do you have some research backing up such cavalier claims? It was not my intention to sound cavalier. Apologies. Fortuna was developed to account for many sources of entropy, good and bad alike, and Jeff’s observation is an attack on that design. I accept that the randomness of these events is poor, but they are high-rate, and this product of high-rate*low entropy is what I seek. I pulled out numbers with dtrace, and basic statistics showed that the harvesting was not useless. I completely understand that under the right circumstances these numbers might be lousy - please read the Fortuna design document to understand why this doesn’t matter. *ALL* entropy inputs to Fortuna are considered attackable, including the dedicated hardware sources. I have also read cryptanalyses of Fortuna, not all of them to be sure, and so far the design appears strong. The best attack that I have seen (very academic) suggests an improvement which I may incorporate. Perhaps more importantly to me, this is an unacceptable performance burden for the allocator. At a minimum it should compile out by default. Great care has been taken to reduce the fast path of the allocator to the minimum number of cycles and even cache misses. As currently set up in etc/rc.d/* by default, there is a simple check at each UMA harvesting opportunity, and no further action. I asked Robert Watson if this was burdensome, and he said it was not. I find this burdensome. You can easily add a macro around the calls or hide them in an inline with a default to off. Even a function call that checks a global and does nothing else is a handful of new cache misses. A microbenchmark will not realize the full cost of this. You will instead get the dozen or so instructions of overhead which I still find objectionable. Kip's observations about packet cycle budgets in high-performance applications are accurate and this is something we have put great care into over time. A certain video streaming company will be pushing the envelope to get to 100Gbps very soon. Even a few extra instructions on every packet / allocation will be a killer. Especially if one is an almost guaranteed cache miss. This most certainly will be burdensome. There absolutely must be a way to turn this off at compile time. We don’t care that much about entropy to leave performance on the table. OK - I’m sold! I’ll make a kernel option defaulting to off. :-) M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r284959 - in head: . share/man/man4 share/man/man9 sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe sys/dev/syscons sys/dev/ubsec sys/dev/virtio/random s
On 23 Jul 2015, at 08:59, Jeff Roberson jrober...@jroberson.net wrote: OK - I?m sold! I?ll make a kernel option defaulting to off. :-) There are other sources that occur less frequently than millions of times per-second that may still provide some usefull entropy while being less performance critical under normal conditions. I’m sure there are, and I’m keen to discover more! I’m not exactly the worlds best kernel hacker, so I’ll be requesting help. My own crappy benchmark is “make world” and for that, I notice very little. For Video at Ludicrous Speed(™), I’m well prepared to accept otherwise! For crypto purposes, UMA is brilliant, though (but that won’t stop me defaulting it to “compiled out”). For example, context switches, traps, etc. I could also imagine wiring up a pmc counter to something like cache misses or branch mispredicts that would be more difficult to game, especially if the counter was cycled irregularly. Help requested here, please! If you could point out suitable harvesting points, I’ll see if the numbers from them look good. Thanks! M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r284959 - in head: . share/man/man4 share/man/man9 sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe sys/dev/syscons sys/dev/ubsec sys/dev/virtio/random s
On 22 Jul 2015, at 22:42, Jeff Roberson jrober...@jroberson.net wrote: On Tue, 30 Jun 2015, Mark Murray wrote: - Add harvesting of slab allocator events. This needs to be checked for weighing down the allocator code. Neither filesystem operations nor allocations are random events. They are trivially influenced by user code. A malicious attacker could create repeated patterns of allocations or filesystem activity through the syscall path to degrade your random sample source. I’m not sure I accept that - Fortuna is very careful about using non-reversible hashing in it’s accumulation, and countering such degradation is one of the algorithm’s strong points. There is perhaps risk of *no* entropy, but even the per-event timing jitter will be providing this, if nothing else. Perhaps more importantly to me, this is an unacceptable performance burden for the allocator. At a minimum it should compile out by default. Great care has been taken to reduce the fast path of the allocator to the minimum number of cycles and even cache misses. As currently set up in etc/rc.d/* by default, there is a simple check at each UMA harvesting opportunity, and no further action. I asked Robert Watson if this was burdensome, and he said it was not. I’m willing to discuss optimising this, and have plans for some micro-benchmarks. M -- Mark R V Murray PS: Please trim mail when responding - was it necessary to send me back the whole commit message and diff? ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r284959 - in head: . share/man/man4 share/man/man9 sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe sys/dev/syscons sys/dev/ubsec sys/dev/virtio/random s
On 19 Jul 2015, at 20:40, Simon J. Gerraty s...@juniper.net wrote: Mark R V Murray ma...@freebsd.org wrote: On Thu, Jul 02, 2015 at 11:36:27AM -0700, Simon J. Gerraty wrote: Sound like you just need to be able to select a single KLD at boot time? Mark, do you have an estimate of when loadable modules will be supported again? About a week, I’d say. We've been holding off sync'ing from head - which is hardly ideal. Apologies. I will expedite. M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r285692 - head/sys/dev/random
On 19 Jul 2015, at 18:02, Konstantin Belousov kostik...@gmail.com wrote: -printf(random: %s unblock wait\n, __func__); +/* Only bother the console every 10 seconds or so */ +if (spamcount == 0) +printf(random: %s unblock wait\n, __func__); +spamcount = (spamcount + 1)%100; Is ppsratecheck() not suitable for this due to use of 1 sec period ? Oooh! Very probably, thank you. +error = tsleep(random_alg_context, PCATCH, randseed, hz/10); +if ((error == ERESTART | error == EINTR)) This is probably still valid, but I wonder if you mean || there. Then you could also remove extra (). Oh, nuts. Got the wrong patch. Thank you. All your commits are breaking all style(9) rules. It would be nice to keep the style at least for the files where you added random harvesting and which are already mostly style compliant. E.g., what about wrapping lines at position somewhere between 72 and 80 ? I’ll look, thanks! M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r284959 - in head: . share/man/man4 share/man/man9 sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe sys/dev/syscons sys/dev/ubsec sys/dev/virtio/random s
CC’ing to original lists. Kip’s problem has come to conclusion, and our final (private) email is forwarded to the lists with permission. It should be noted that Kip was importing CURRENT to a fork of FreeBSD, and there was a potential merging problem that may have caused a link failure. M On 17 Jul 2015, at 23:14, K. Macy km...@freebsd.org wrote: On Fri, Jul 17, 2015 at 3:01 PM, Mark R V Murray ma...@freebsd.org wrote: On 17 Jul 2015, at 22:39, K. Macy km...@freebsd.org wrote: Like I said, the linking issue isn't a concern. My problem is that it's not booting because it hangs in an uninterruptible sleep in dd. In addition, I strongly disagree with a change that by default could adversely impact network performance. I’ve agreed that the fact that it is uninterruptible is cause for concern, and I’ve now coded but not tested or committed a fix. Glad to hear it. The fact that RANDOM_DUMMY never unblocks is a feature not a bug. I don't recall having suggested otherwise. Returning with no entropy would be undesirable. But as you now, presumably, realize - having the reader be unkillable as a result of this wait is highly undesirable. If you say that you've tested RANDOM_DUMMY and it works for you then I guess I'm on my own. RANDOM_DUMMY is for folks who don’t want a CSPRNG. It sounds like you need one. Yes. I had already reached the obvious conclusion that enabling fortuna would have bypassed all this grief. Cheers. -K -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r284959 - in head: . share/man/man4 share/man/man9 sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe sys/dev/syscons sys/dev/ubsec sys/dev/virtio/random s
On 17 Jul 2015, at 07:47, Adrian Chadd adrian.ch...@gmail.com wrote: hi, So I'll have to update the AP images that I build, as now I have to add that sysctl to things. Well, measure the effect. It may not be as bad as it may seem! :-) It also means everyone has to update their /etc after updating or they'll end up with this particular mode not being disabled. That is usual, right? Do a mergemaster after a make world? i think we need to get this better documented so people aren't bitten when they merge code in from -HEAD or whenever you do MFC this back to stable/10. I’m not yet planning an MFC to 10.x -adrian M — Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r285550 - head/usr.bin/w
On 16 Jul 2015, at 20:46, Ed Schouten e...@nuxi.nl wrote: Hi Mark, Hi! 2015-07-14 20:53 GMT+02:00 Mark Murray ma...@freebsd.org: Log: Widen the host field so that a full IPv6 address will be seen. Quick question: does this column width adjust itself automatically? The WHAT column of w(1) is already pretty narrow. No. This column is statically sized. The “what column” prints arbitrary length lines. I’ve hardly ever seen anything long in practice though. M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r285550 - head/usr.bin/w
On 16 Jul 2015, at 18:35, Bryan Drewery bdrew...@freebsd.org wrote: On 7/14/15 11:53 AM, Mark Murray wrote: Author: markm Date: Tue Jul 14 18:53:24 2015 New Revision: 285550 URL: https://svnweb.freebsd.org/changeset/base/285550 Log: Widen the host field so that a full IPv6 address will be seen. Relnotes: yes! Damn you! ;-) I’ve just had to install the kitchen sink to do this! (The building is a bit out of date; the optional ports don’t exist, and installing textproc/fpo resulted in a tool that did not make a readable PDF). MFC: Please Er, sure! M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r284959 - in head: . share/man/man4 share/man/man9 sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe sys/dev/syscons sys/dev/ubsec sys/dev/virtio/random s
On 16 Jul 2015, at 15:08, Ian Lepore i...@freebsd.org wrote: On Thu, 2015-07-16 at 06:39 +0100, Mark Murray wrote: On 15 Jul 2015, at 23:43, Adrian Chadd adrian.ch...@gmail.com wrote: - Add harvesting of slab allocator events. This needs to be checked for weighing down the allocator code. Hi, Is this really doing it upon every one of those events? eg, for each mbuf alloc through UMA? Only if you turn it on! M In random_harvestq_init() I see harvest_context.hc_source_mask = RANDOM_HARVEST_EVERYTHING_MASK; and #define RANDOM_HARVEST_EVERYTHING_MASK ((1 (RANDOM_ENVIRONMENTAL_END + 1)) - 1) So doesn't that include the RANDOM_FAST flag that controls harvesting during every UMA alloc and free call? And that harvesting appears to be anything but fast, at least at a glance... it looks like it passes the entire struct uma_zone to the jenkins hash function... is there really useful entropy in all the data in that struct? Well spotted, but fear not. All sources are on at startup, and this is to ensure that the generator has maximal access to entropy while booting. One of the default duties of etc/rc.d/random is to turn off the UMA and ATIME sources. These may be turned on if you want them, but by default on the fully booted system they are off. See ‘sysctl kern.random.harvest.mask_symbolic’ and note that the disabled sources are in []. I have yet to do a full set of benchmarks, but I have discussed this with RWatson. A silly benchmark (make world) shows little effect, but I will be doing this properly in coming months. In answer to you final question - yes. The UMA entropy is a bit spread out, but it is good. M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r285422 - in head: share/man/man4 sys/conf sys/dev/random sys/net sys/netgraph
On 13 Jul 2015, at 08:40, Mark R V Murray ma...@freebsd.org wrote: I started getting kernel panics on boot after this commit. Can you look at this: https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests/1177/console https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests/1177/consoleI'm onto it now. Thanks and apologies. A fix is in - r285439. Apologies again. M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r285439 - head/sys/dev/random
On 13 Jul 2015, at 20:25, Peter Jeremy pe...@rulingia.com wrote: On 2015-Jul-13 08:38:21 +, Mark Murray ma...@freebsd.org wrote: +/* + * Belt-and-braces. + * Round up the read length to a crypto block size multiple, + * which is what the underlying generator is expecting. + * See the random_buf size requirements in the Yarrow/Fortuna code. + */ +read_len += RANDOM_BLOCKSIZE; +read_len -= read_len % RANDOM_BLOCKSIZE; Note that if read_len was already a multiple of RANDOM_BLOCKSIZE, this will pad it by an additional RANDOM_BLOCKSIZE. I don't think this matters but it's not what the comment implies. (The comment also goes over 80 columns). Yes - this is overly conservative ;-) I’ve done a further tightening up, but I want to let it settle and not churn the code. M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r285422 - in head: share/man/man4 sys/conf sys/dev/random sys/net sys/netgraph
Hi, On 13 Jul 2015, at 01:52, Craig Rodrigues rodr...@crodrigues.org wrote: On Jul 12, 2015 2:14 PM, Mark Murray ma...@freebsd.org mailto:ma...@freebsd.org wrote: Author: markm Date: Sun Jul 12 18:14:38 2015 New Revision: 285422 URL: https://svnweb.freebsd.org/changeset/base/285422 https://svnweb.freebsd.org/changeset/base/285422 Log: * Address review (and add a bit myself). - Tweek man page. - Remove all mention of RANDOM_FORTUNA. If the system owner wants YARROW or DUMMY, they ask for it, otherwise they get FORTUNA. I started getting kernel panics on boot after this commit. Can you look at this: https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests/1177/console https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests/1177/consoleI'm onto it now. Thanks and apologies. M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r285288 - head/etc/rc.d
Apologies! M On 8 Jul 2015, at 21:37, Andriy Gapon a...@freebsd.org wrote: On 08/07/2015 21:46, Mark Murray wrote: Author: markm Date: Wed Jul 8 18:46:44 2015 New Revision: 285288 URL: https://svnweb.freebsd.org/changeset/base/285288 Log: Address review. This commit message sucks... Differential Revision: https://reviews.freebsd.org/D2924 -- Andriy Gapon -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r284959 - in head: . share/man/man4 share/man/man9 sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe sys/dev/syscons sys/dev/ubsec sys/dev/virtio/random s
On 2 Jul 2015, at 00:07, Simon J. Gerraty s...@juniper.net wrote: Mark Murray ma...@freebsd.org wrote: * src/sys/dev/random/random_adaptors.c src/sys/dev/random/random_adaptors.h - Remove; plugability is no longer used. Compile-time algorithm selection is the way to go. Errr we use that and need it. Please put it back. Do you really need full the plugability (including run-time selection of algorithm), or do you just need to have KLD modules back? I intend to do the latter, but in a different way. The adaptor code and run-time section was a locking liability. Whether we agree with NIST's ideas about how randomness should be handled or not, we need to to be able to comply and we do not want to burn their desired arrangement into our kernels. Sound like you just need to be able to select a single KLD at boot time? M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r284959 - in head: . share/man/man4 share/man/man9 sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe sys/dev/syscons sys/dev/ubsec sys/dev/virtio/random s
On 2 Jul 2015, at 19:36, Simon J. Gerraty s...@juniper.net wrote: Mark R V Murray ma...@freebsd.org wrote: - Remove; plugability is no longer used. Compile-time algorithm selection is the way to go. Errr we use that and need it. Please put it back. Do you really need full the plugability (including run-time selection of algorithm), or do you just need to have KLD modules back? We need KLD for sure, and the ablity to leave out a mixer like yarrow/fortuna - we do not expect any of our customers (except those forced to by govt) to use that arrangement though. Excellent! :-) I intend to do the latter, but in a different way. The adaptor code and run-time section was a locking liability. Whether we agree with NIST's ideas about how randomness should be handled or not, we need to to be able to comply and we do not want to burn their desired arrangement into our kernels. Sound like you just need to be able to select a single KLD at boot time? Quite possibly. Will confirm… Great, thanks! If so, can I confirm that you may be rolling your own non-Yarrow/Fortuna mixer(s)? M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r284959 - in head: . share/man/man4 share/man/man9 sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe sys/dev/syscons sys/dev/ubsec sys/dev/virtio/random s
On 2 Jul 2015, at 19:42, Arthur Mesh am...@juniper.net wrote: On Thu, Jul 02, 2015 at 11:36:27AM -0700, Simon J. Gerraty wrote: Sound like you just need to be able to select a single KLD at boot time? Quite possibly. Will confirm... Hello, We need to be able to select a random adaptor at load time. I.e. loader is the one selecting it based on configuration. I.e., if the box is configured to boot in FIPS mode, it should use NIST SP800-90 HMAC-DRBG adaptor. Otherwise, it uses the default FreeBSD adaptor (Fortuna I guess). No problem! Could you please let me know your implementation’s API? If I have that, or at least an approximation, I can make a framework in which you can insert your code. We do not need ability to switch adaptors at run-time. Excellent. This has been causing trouble for me for ages. M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r284959 - in head: . share/man/man4 share/man/man9 sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe sys/dev/syscons sys/dev/ubsec sys/dev/virtio/random s
On 2 Jul 2015, at 19:55, Simon J. Gerraty s...@juniper.net wrote: Mark R V Murray ma...@freebsd.org wrote: If so, can I confirm that you may be rolling your own non-Yarrow/Fortuna mixer(s)? AFAIK no mixer allowed; just direct SP800-90 compliant HMAC-DRBG. You can probably guess why we don't agree that's a brilliant arrangement but its not an argument we can win. IIRC, that still requires some stochastic input? Same would apply for anyone else doing FIPS 140 evaled products. Sure. M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r284959 - in head: . share/man/man4 share/man/man9 sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe sys/dev/syscons sys/dev/ubsec sys/dev/virtio/random s
On 2 Jul 2015, at 20:28, Arthur Mesh am...@juniper.net wrote: On Thu, Jul 02, 2015 at 08:21:31PM +0100, Mark R V Murray wrote: I.e., if the box is configured to boot in FIPS mode, it should use NIST SP800-90 HMAC-DRBG adaptor. Otherwise, it uses the default FreeBSD adaptor (Fortuna I guess). No problem! Could you please let me know your implementation???s API? If I have that, or at least an approximation, I can make a framework in which you can insert your code. Sure, Here is the shim between HMAC_DRBG and struct random_adaptor (that used to plug-in before removal on 2015/6/30). Magic, thank you! M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r280955 - in head/sys: modules/notrandom dev/notrandom
On 1 Apr 2015, at 16:13, Julian Elischer jul...@freebsd.org wrote: On 4/1/15 11:11 PM, Julian Elischer wrote: On 4/1/15 10:18 PM, Ian Lepore wrote: On Wed, 2015-04-01 at 13:52 +0200, Mateusz Guzik wrote: As a side note I'm surprised with the choice of 7. I would expect 3, no more, no less. 3 would be the number returned, and the number readers receive would be 3. 5 would be right out. there is prior art for 7... I remember seeing it once.. 7, 7, 7, 7, 7 ... that's the trouble with randomness, you can't really tell.. I remember a part of a paper on the topic by Adams S, et al. I think it was towards the end of the paper. I stand corrected... the number selected in the paper was 9 Well spotted! Before someone makes a terrible mistake, I should point out that 4 is confirmed random, as cited here: https://xkcd.com/221/ M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r280955 - in head/sys: modules/notrandom dev/notrandom
On 1 Apr 2015, at 16:46, Mateusz Guzik mjgu...@gmail.com wrote: We can add an ioctl to control this. Thats a bad idea, because some fool may set up their local instance to return a random number (like 4), and that will badly break the intent of this device. And before somebody says “tools, not policy”, there is SOME level of protection that you must allow for to prevent completely idiotic admins to foul things up! Opinions? “Pah!”? M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r278907 - head/sys/dev/random
void dummy_random_read_phony(uint8_t *, u_int); /* kern.random sysctls */ #ifdef SYSCTL_DECL/* from sysctl.h */ -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: svn commit: r273872 - in head: etc/defaults etc/rc.d libexec/save-entropy share/examples/kld/random_adaptor sys/conf sys/dev/glxsb sys/dev/random sys/kern sys/modules sys/modules/padlock_rng sys/m
Hi all Apologies for my relative silence; I have been looking at this - promise! On 2 Nov 2014, at 00:12, Adrian Chadd adr...@freebsd.org wrote: So, hm. How do us embedded people just unblock it for now at boot, so we can actually _get_ enough entropy? Depending on your requirements, if switching to Fortuna[*] doesn’t solve your problem (Fortuna will be the default some time in the future anyway), then try this hack: In yarrow.c, line 156, change yarrow_state.seeded = 0; to yarrow_state.seeded = 1; M [*] In your kernel: options RANDOM_DEBUG# Expose the reseed progress options RANDOM_FORTUNA # Use the Fortuna CSPRNG -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r273957 - in head: . etc/rc.d
Nice move, thanks! :-)
M
On 2 Nov 2014, at 01:47, Dag-Erling Smørgrav d...@freebsd.org wrote:
Author: des
Date: Sun Nov 2 01:47:27 2014
New Revision: 273957
URL: https://svnweb.freebsd.org/changeset/base/273957
Log:
Get rid of the postrandom script. It was born in a time when the
random script ran before filesystems were mounted, which is no
longer the case.
In random_start(), immediately delete each file that is fed into
/dev/random, and recreate the default entropy file immediately
after reading and deleting it. The logic used in random_stop()
to determine which file to write to should probably be factored
out and used here as well.
Deleted:
head/etc/rc.d/postrandom
Modified:
head/ObsoleteFiles.inc
head/etc/rc.d/Makefile
head/etc/rc.d/adjkerntz
head/etc/rc.d/random
Modified: head/ObsoleteFiles.inc
==
--- head/ObsoleteFiles.incSun Nov 2 01:13:11 2014(r273956)
+++ head/ObsoleteFiles.incSun Nov 2 01:47:27 2014(r273957)
@@ -38,6 +38,8 @@
# xargs -n1 | sort | uniq -d;
# done
+# 20141102: postrandom obsoleted by new /dev/random code
+OLD_FILES+=etc/rc.d/postrandom
# 20141031: initrandom obsoleted by new /dev/random code
OLD_FILES+=etc/rc.d/initrandom
# 20141028: debug files accidentally installed as directory name
Modified: head/etc/rc.d/Makefile
==
--- head/etc/rc.d/MakefileSun Nov 2 01:13:11 2014(r273956)
+++ head/etc/rc.d/MakefileSun Nov 2 01:47:27 2014(r273957)
@@ -112,7 +112,6 @@ FILES=DAEMON \
pf \
pflog \
pfsync \
- postrandom \
powerd \
power_profile \
ppp \
Modified: head/etc/rc.d/adjkerntz
==
--- head/etc/rc.d/adjkerntz Sun Nov 2 01:13:11 2014(r273956)
+++ head/etc/rc.d/adjkerntz Sun Nov 2 01:47:27 2014(r273957)
@@ -4,7 +4,7 @@
#
# PROVIDE: adjkerntz
-# REQUIRE: FILESYSTEMS postrandom
+# REQUIRE: FILESYSTEMS
# BEFORE: netif
# KEYWORD: nojail
Modified: head/etc/rc.d/random
==
--- head/etc/rc.d/random Sun Nov 2 01:13:11 2014(r273956)
+++ head/etc/rc.d/random Sun Nov 2 01:47:27 2014(r273957)
@@ -17,41 +17,58 @@ stop_cmd=random_stop
extra_commands=saveseed
saveseed_cmd=${name}_stop
+save_dev_random()
+{
+ for f ; do
+ if :$f ; then
+ debug saving entropy to $f
+ dd if=/dev/random of=$f bs=4096 count=1 2/dev/null
+ fi
+ done
+}
+
feed_dev_random()
{
- if [ -f ${1} -a -r ${1} -a -s ${1} ]; then
- cat ${1} | dd of=/dev/random bs=8k 2/dev/null
- fi
+ for f ; do
+ if [ -f $f -a -r $f -a -s $f ] ; then
+ if dd if=$f of=/dev/random bs=4096 2/dev/null ; then
+ debug entropy read from $f
+ rm -f $f
+ fi
+ fi
+ done
}
random_start()
{
+ echo -n 'Feeding entropy:'
+
+ if [ ! -w /dev/random ] ; then
+ warn /dev/random is not writeable
+ return 1
+ fi
+
# Reseed /dev/random with previously stored entropy.
- case ${entropy_dir} in
+ case ${entropy_dir:=/var/db/entropy} in
[Nn][Oo])
;;
*)
- entropy_dir=${entropy_dir:-/var/db/entropy}
- if [ -d ${entropy_dir} ]; then
- if [ -w /dev/random ]; then
- for seedfile in ${entropy_dir}/*; do
- feed_dev_random ${seedfile}
- done
- fi
+ if [ -d ${entropy_dir} ] ; then
+ feed_dev_random ${entropy_dir}/*
fi
;;
esac
- case ${entropy_file} in
+ case ${entropy_file:=/entropy} in
[Nn][Oo] | '')
;;
*)
- if [ -w /dev/random ]; then
- feed_dev_random ${entropy_file}
- feed_dev_random /var/db/entropy-file
- fi
+ feed_dev_random ${entropy_file} /var/db/entropy-file
+ save_dev_random ${entropy_file}
;;
esac
+
+ echo '.'
}
random_stop()
@@ -59,7 +76,7 @@ random_stop()
# Write some entropy so when the machine reboots /dev/random
# can be reseeded
#
- case ${entropy_file} in
+ case ${entropy_file:=/entropy} in
[Nn][Oo] | '')
;;
*)
--
Mark R V Murray
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org
Re: svn commit: r273958 - head/sys/dev/random
Hi DES,
I’m scared witless of this being on-by-default, for the reason given in the
removed comment. I’d much prefer to see it only turned on if a kernel option is
set, and the embedded folks /et al/ can use that.
Please reinstate the #ifdef RANDOM_AUTOSEED, and set a kernel option to turn it
on. Please also leave the comment; summarily turning on an unprepared generator
is not going to be obvious to anyone but an attacker.
Moving the point of the auto-firstseed to where is good, thanks.
M
On 2 Nov 2014, at 02:01, Dag-Erling Smørgrav d...@freebsd.org wrote:
Author: des
Date: Sun Nov 2 02:01:55 2014
New Revision: 273958
URL: https://svnweb.freebsd.org/changeset/base/273958
Log:
Restore the auto-reseed logic, but move it to a much later point,
immediately before kick_init.
Approved by: so (self)
Modified:
head/sys/dev/random/random_adaptors.c
head/sys/dev/random/yarrow.c
Modified: head/sys/dev/random/random_adaptors.c
==
--- head/sys/dev/random/random_adaptors.c Sun Nov 2 01:47:27 2014
(r273957)
+++ head/sys/dev/random/random_adaptors.c Sun Nov 2 02:01:55 2014
(r273958)
@@ -447,30 +447,8 @@ random_adaptors_deinit(void)
}
/*
- * First seed.
- *
- * NB! NB! NB!
- * NB! NB! NB!
- *
- * It turns out this is bloody dangerous. I was fiddling with code elsewhere
- * and managed to get conditions where a safe (i.e. seeded) entropy device
should
- * not have been possible. This managed to hide that by unblocking the
device anyway.
- * As crap randomness is not directly distinguishable from good randomness,
this
- * could have gone unnoticed for quite a while.
- *
- * NB! NB! NB!
- * NB! NB! NB!
- *
- * Very luckily, the probe-time entropy is very nearly good enough to cause a
- * first seed all of the time, and the default settings for other entropy
- * harvesting causes a proper, safe, first seed (unblock) in short order
after that.
- *
- * That said, the below would be useful where folks are more concerned with
- * a quick start than with extra paranoia in a low-entropy environment.
- *
- * markm - October 2013.
+ * Reseed the active adaptor shortly before starting init(8).
*/
-#ifdef RANDOM_AUTOSEED
/* ARGSUSED */
static void
random_adaptors_seed(void *unused __unused)
@@ -484,6 +462,5 @@ random_adaptors_seed(void *unused __unus
arc4rand(NULL, 0, 1);
}
-SYSINIT(random_seed, SI_SUB_INTRINSIC_POST, SI_ORDER_LAST,
-random_adaptors_reseed, NULL);
-#endif /* RANDOM_AUTOSEED */
+SYSINIT(random_seed, SI_SUB_KTHREAD_INIT, SI_ORDER_FIRST,
+random_adaptors_seed, NULL);
Modified: head/sys/dev/random/yarrow.c
==
--- head/sys/dev/random/yarrow.c Sun Nov 2 01:47:27 2014
(r273957)
+++ head/sys/dev/random/yarrow.c Sun Nov 2 02:01:55 2014
(r273958)
@@ -508,7 +508,9 @@ void
random_yarrow_reseed(void)
{
+ mtx_lock(random_reseed_mtx);
reseed(SLOW);
+ mtx_unlock(random_reseed_mtx);
}
int
--
Mark R V Murray
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r273958 - head/sys/dev/random
On 2 Nov 2014, at 09:59, Andrey Chernov a...@freebsd.org wrote: On 02.11.2014 12:45, Mark R V Murray wrote: Hi DES, I’m scared witless of this being on-by-default, for the reason given in the removed comment. I’d much prefer to see it only turned on if a kernel option is set, and the embedded folks /et al/ can use that. We don't need yet one kernel knob to make sysadmin life a bit more harder. This thing needs to be autosensed somehow. F.e. if no disk interrupts or ethernet interrupt hooks are executed, switch to AUTOSEED automatically (or by any other automatic way). DES’s change makes no difference in a Tier-1 platform, except potentially hiding a security problem. In the embedded world Tier-2+ (MIPS/ARM) where the problem is raising its head, customised kernels are very common indeed, and this option gives further control to the engineer configuring the system. M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r273872 - in head: etc/defaults etc/rc.d libexec/save-entropy share/examples/kld/random_adaptor sys/conf sys/dev/glxsb sys/dev/random sys/kern sys/modules sys/modules/padlock_rng sys/m
On 2 Nov 2014, at 12:51, Dag-Erling Smørgrav d...@des.no wrote: Jan Beich jbe...@vfemail.net writes: I have a minimalistic kernel where everything is pushed to a module for easier/faster debugging before kload. As its config has no |device random| loading random.ko fails because nothing provides random_adaptors [...] Yes, there is work to be done there. Ideally, the random module should include the random_adaptors framework and /dev/random itself, while Yarrow and Fortuna should be separate modules which can coexist, rather than mutually exclusive kernel options. Compiling both into the kernel is possible, but tricky, so I didn’t do it this time round. The reason for the trickiness is that randomdev_soft.c gets compiled for each hash (Yarrow, Fortuna) with hash-specific #defines set. Not insoluble, but I just didn’t get to it. I’ll fix the random_adaptors bit shortly. M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r273958 - head/sys/dev/random
On 2 Nov 2014, at 12:41, Dag-Erling Smørgrav d...@des.no wrote: Mark R V Murray m...@grondar.org writes: I’m scared witless of this being on-by-default, for the reason given in the removed comment. I’d much prefer to see it only turned on if a kernel option is set, and the embedded folks /et al/ can use that. You didn't seem to mind this code when we introduced it in 10-CURRENT. Removing it breaks pretty much everything, not just embedded systems. We can add a sysctl to turn it off, but it has to be on by default. I’ve had a closer look at things, and I’m coming round to your side. Note that this has NO effect on Fortuna. Fortuna’s self-starting appears to be more reliable. Note that the alternative is to feed more trash into /dev/random at boot, as we did before. It may give us a warm and fuzzy feeling which we don't get from automatically seeding, but the reality is that we have no idea how good that trash is either. In fact, most of what we used to feed into /dev/random at boot (ps, sysctls etc) was constant or nearly so. I prefer to trust that we get enough entropy from attachtimes and I/O in the boot process - and the data I gathered indicates that there is more than enough entropy from attachtimes alone, even on SFF systems and VMs. OK, Fair enough. :-) Moving the point of the auto-firstseed to where is good, thanks. ...except that I'm not sure it doesn't break root-on-geli etc, but at least it doesn't break it more than not having auto-firstseed at all. M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r273958 - head/sys/dev/random
On 2 Nov 2014, at 12:42, Dag-Erling Smørgrav d...@des.no wrote: Mark R V Murray m...@grondar.org writes: DES’s change makes no difference in a Tier-1 platform, except potentially hiding a security problem. I will assume that you did not read the discussion that lead up to my commits, because if you did, you know this is a lie. Telling me that I got it wrong would be a lot more accurate than accusing me of lying. Lying would require an act of malice on my part, which I can assure you is absent. Please choose your words more carefully. M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r273958 - head/sys/dev/random
On 2 Nov 2014, at 13:22, Ian Lepore i...@freebsd.org wrote: On Sun, 2014-11-02 at 09:45 +, Mark R V Murray wrote: Hi DES, I´m scared witless of this being on-by-default, for the reason given in the removed comment. I´d much prefer to see it only turned on if a kernel option is set, and the embedded folks /et al/ can use that. Please reinstate the #ifdef RANDOM_AUTOSEED, and set a kernel option to turn it on. Please also leave the comment; summarily turning on an unprepared generator is not going to be obvious to anyone but an attacker. Moving the point of the auto-firstseed to where is good, thanks. M To give you some idea of how usable this new stuff is on a system that isn't an x86 server or someone's desktop or laptop... after commenting out the postrandom so that a board would at least boot (but before DES' resend change), I left a board sitting idle at the login prompt. It was somewhere between 40 minutes and an hour before I saw this: FreeBSD/arm (rpi) (ttyu0) login: random: reseed - fast - thresh 96,1 - 0 48 0 0 0 130 0 0 620 0 0 0 0 0 0 0 0 0 0 0 random: reseed - slow - thresh 128,2 - 0 44 0 0 0 130 0 0 619 0 0 0 0 0 0 0 0 0 0 0 random: unblocking device. Thanks for doing this, Ian. This is good information, and tells me a lot about Yarrow on some systems. Securing a system against some theoretical attack has value only to the point where the system is no longer usable at all. At that point you kind of have to declare the attacker the winner, and he didn't even have to actually launch an attack. Point conceded. :-) M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r273872 - in head: etc/defaults etc/rc.d libexec/save-entropy share/examples/kld/random_adaptor sys/conf sys/dev/glxsb sys/dev/random sys/kern sys/modules sys/modules/padlock_rng sys/m
On 2 Nov 2014, at 19:07, Adrian Chadd adr...@freebsd.org wrote: On 2 November 2014 05:08, Mark R V Murray ma...@freebsd.org wrote: On 2 Nov 2014, at 12:51, Dag-Erling Smørgrav d...@des.no wrote: Jan Beich jbe...@vfemail.net writes: I have a minimalistic kernel where everything is pushed to a module for easier/faster debugging before kload. As its config has no |device random| loading random.ko fails because nothing provides random_adaptors [...] Yes, there is work to be done there. Ideally, the random module should include the random_adaptors framework and /dev/random itself, while Yarrow and Fortuna should be separate modules which can coexist, rather than mutually exclusive kernel options. Compiling both into the kernel is possible, but tricky, so I didn’t do it this time round. The reason for the trickiness is that randomdev_soft.c gets compiled for each hash (Yarrow, Fortuna) with hash-specific #defines set. Not insoluble, but I just didn’t get to it. I’ll fix the random_adaptors bit shortly. Also as a side note - the kernel on the embedded MIPS boards here are now 1MiB compressed now because loading random as a module isn't supported or working right. :( I’m looking at it. M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r273958 - head/sys/dev/random
On 2 Nov 2014, at 19:20, Konstantin Belousov kostik...@gmail.com wrote: On Sun, Nov 02, 2014 at 11:05:27AM -0800, Adrian Chadd wrote: [snip all the conversation] Ok. There's still a problem that I can trigger by trying to Ctrl-C a process that's blocked reading for randomness. I'll try to chase up more details about and file a PR about it. The unfortunate part is that the kernel side stack trace of the offending / hung process isn't currently helpful. :( From what I see, signals are essentially ignored in the read code. See random_adaptors.c:random_adaptor_read(): /* Sleep instead of going into a spin-frenzy */ tsleep(random_adaptor, PUSER | PCATCH, block, hz/10); The error which would indicate the signal catch, is dropped. Also, unbound sleep does not drop random_adaptor_lock, which means that you cannot module which could provide some more randomness for you, while any thread is stuck in read loop. Hi I don’t quite follow what you mean, but it sounds like you understand the problem. Could you please explain with a bit more detail? Thanks, M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r273958 - head/sys/dev/random
On 2 Nov 2014, at 19:46, Konstantin Belousov kostik...@gmail.com wrote:
I don???t quite follow what you mean, but it sounds like you understand
the problem. Could you please explain with a bit more detail?
Which problem ? There are two.
One is the Adrian' complain. tsleep(9) catches signals, and return
EINTR/ERESTART when catched. Typical driver code checks for the
errors from {t,m}sleep(9) and aborts the operation if error is
returned. I.e. you should do
error = tsleep(...);
if (error != 0) {
abort the loop;
return to caller;
}
The fine detail is that for the case when read has already partially
progressed, i.e. something was copied out to uio, the error must
not be returned, but short read performed instead.
OK, I think I follow this.
In another mail you say:
Yes, this is because error from tsleep() in random_adaptor_read()
does not abort the loop. But next loop iteration calls tsleep()
which returns immediately since there is still pending signal.
The process continues indefinitely.
.. which supports this what you say further above. Thanks.
This leads to another question about the code in random_adapter_read():
if ra_read method sleeps, it must handle the signals as well, return
error, and the second loop which perorms ra_read/uiomove should be
aborted as well. Again, error from either ra_read or uiomove(9)
must result in short read if something was already copied to uio.
Currently, there is no error returned by ra_read (or it is ignored),
and error from uiomove always returned, even if something was already
copied.
Are you saying the same thing again, or something else? If you are saying
something else, then I am struggling to follow you.
Second problem is that random_adaptor_lock is owned while tsleep()
is called (or whatever sleep primitive is used inside ra_read). If
platform could only provide randomness through some hw, and module
is loaded while thread is blocked, module cannot register, while
reading thread cannot make progress.
I’m sorry, I don’t understand this.
M
--
Mark R V Murray
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r273958 - head/sys/dev/random
This look visually OK to me. I’ll run it locally, but it needs So permission to commit. I guess you can self-certify, right? :-) M On 2 Nov 2014, at 20:27, Xin Li delp...@delphij.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, Mark, I'd like to propose the attached patch for review. It replaces tsleep's with sx_sleep's, then checks the return value and quit the loop. Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0 iQIcBAEBCgAGBQJUVpO0AAoJEJW2GBstM+nsTcoQAKQglUQUKCh4h+flynK+of1J I8pyCJTqkJHsvQu7Lj8Nh4gd6OQM3+XdpEGymA/wB1Q906cNI8ieLwuXCOmCxYhw xs2XJL5cyp1myDqCp3BRrNta8PPSF8gxfnCeU/0LuItrvcNaE3axNb/eu4g3u5s7 NZObx84C03uRoHMz+9qG0qkZbutY/qN8YP3DQ1WvkYom/i4UT2NGa1EgHLYa9Ofu REQ/lADumxqn5Cw6viKym1wI1HrCu00X602jGjivEzn1L7DSfKFJjckyLC2IbbdY Ydy4ejsILJRPFDt6PrcSWkaSBIy585wP90YsFvSK4riyy1i3HUF4pE5wQPPG/ogV ATm4S9GZgr4mM3SHZrcaTDyrm9BEsEizqBs/F3yyuKBqZt0xtTjv+tupCN5AG1LX DnfgLj7pNAW2SIF7lul34/CzisoKB7b5oEpL9YWOh8DvZiEgHMex4nRqTNAt9T8F 7f5bGvcMHfkIOQIUanxlganUW2ZgVaDPYQADjrEsfqD2pTwwK7glN0jXKJ9YStGW kzbjAQil9X/fliVSzPubbO0XTqAtjnPwONBbjw06vlrwZlkHbLOTz0VVZ3cAJcei 4CkCiEQtuFWbD9QVCUe6snztRRTI542dIlWSDPhSxYV3+hrkCgCeJ3fMvTutf7YZ ejIPZ/NOkhddVmvjMHKw =XrYs -END PGP SIGNATURE- random-tsleep.diffrandom-tsleep.diff.sig -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r273872 - in head: etc/defaults etc/rc.d libexec/save-entropy share/examples/kld/random_adaptor sys/conf sys/dev/glxsb sys/dev/random sys/kern sys/modules sys/modules/padlock_rng sys/m
Hi Garrett, On 31 Oct 2014, at 21:04, Garrett Cooper yaneurab...@gmail.com wrote: Could you please add an UPDATING entry for this? Some users (like me) who do make installworld from old kernels are experiencing issues (some dealing with filesystem corruption). Please see this thread on -current@ for more details: https://lists.freebsd.org/pipermail/freebsd-current/2014-October/053039.html Will do. Thanks for the reminder. This also should have had “Relnotes: yes” in the commit message because this deserves to be put in the release notes for 11.0 Oops. :-( M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r273872 - in head: etc/defaults etc/rc.d libexec/save-entropy share/examples/kld/random_adaptor sys/conf sys/dev/glxsb sys/dev/random sys/kern sys/modules sys/modules/padlock_rng sys/m
Hi I’m not sure what you are showing me here? How yo you draw the “not enough entropy” conclusion? The writing happens at shutdown; before you do the shutdown could you please do a ‘sysctl kern.random’ and post the result? Do you have anything random-related in your rc.conf? Could you please do a verbose boot on a kernel with “options RANDOM_DEBUG” set and send me the dmesg output from a failing box. M On 1 Nov 2014, at 22:15, Alexander Kabaev kab...@gmail.com wrote: On Sat, 1 Nov 2014 14:57:02 -0700 Adrian Chadd adr...@freebsd.org wrote: Hi, I'm having a problem with this on MIPS router boards now: db bt 277 Tracing pid 277 tid 100034 td 0x80d7b9c0 cpu_switch+90 (?,?,?,?) ra ca90db68 sp 0 sz 0 sched_switch+224 (?,?,?,?) ra ca90db680028 sp 0 sz 0 mi_switch+27c (?,?,?,?) ra ca90db900020 sp 0 sz 0 80176358+1a0 (?,?,?,?) ra ca90dbb00028 sp 0 sz 0 801765dc+2d0 (?,?,?,?) ra ca90dbd80030 sp 0 sz 0 sleepq_timedwait_sig+18 (?,?,?,?) ra ca90dc080020 sp 0 sz 0 _sleep+3b8 (?,?,?,803199e0) ra ca90dc280068 sp 0 sz 0 random_adaptor_read+114 (?,?,?,?) ra ca90dc900038 sp 0 sz 0 800b1898+c0 (?,?,?,?) ra ca90dcc80048 sp 0 sz 0 80187450+6c (?,?,?,?) ra ca90dd100028 sp 0 sz 0 kern_readv+8c (?,?,?,?) ra ca90dd380050 sp 0 sz 0 sys_read+48 (?,?,?,?) ra ca90dd880040 sp 0 sz 0 trap+7f0 (?,?,?,?) ra ca90ddc800b8 sp 0 sz 0 MipsUserGenException+10c (?,?,?,408ed960) ra ca90de80 sp 0 sz 0 ... I've included random into the kernel rather than as a module now. This -looks- like it's not getting enough entropy now? -adrian Me too, on amd64 box. The machine gets hung for several minutes after 'writing entropy file' until random is unblocked. Anecdotally, banging on the keyboard trying to help the entropy gathering along seems to speed the process up. -- Alexander Kabaev -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r273872 - in head: etc/defaults etc/rc.d libexec/save-entropy share/examples/kld/random_adaptor sys/conf sys/dev/glxsb sys/dev/random sys/kern sys/modules sys/modules/padlock_rng sys/m
On 31 Oct 2014, at 14:22, Dag-Erling Smørgrav d...@des.no wrote: Andrey Chernov a...@freebsd.org writes: Mark Murray ma...@freebsd.org writes: Deleted: head/etc/rc.d/initrandom It should be added to ObsoleteFiles.inc Good catch, fixed in r273907. Thanks! M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r273872 - in head: etc/defaults etc/rc.d libexec/save-entropy share/examples/kld/random_adaptor sys/conf sys/dev/glxsb sys/dev/random sys/kern sys/modules sys/modules/padlock_rng sys/m
On 31 Oct 2014, at 14:22, Dag-Erling Smørgrav d...@des.no wrote: Mark Murray ma...@freebsd.org writes: Log: This is the much-discussed major upgrade to the random(4) device, known to you all as /dev/random. Much discussed and long-awaited :) Thank you for your hard work and persistence! Thank you! Reviewed by:trasz,des(partial),imp(partial?),rwatson(partial?) Must... resist... tentation to make a joke about imp(partial?)… *snigger* :-) M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r266083 - in head/sys/arm: arm include
Hi Michael,
If that works, then Brilliant! :-) :-)
Could you please fix this so the _PMC_USER_READ_WRITE_ is all in one place
(it’s too dangerous to split up), and put an architecture-specific #ifdef
around just the MCR instruction we care about.
With that, its good to commit, I’d say. I’ll likely follow up and exclude the
architectures that are unproven.
M
On 17 Jun 2014, at 10:52, Michael Tuexen tue...@freebsd.org wrote:
On 16 Jun 2014, at 22:13, Mark R V Murray ma...@freebsd.org wrote:
Hi Mark,
I just adopted the comments to the code change. So here is the improved patch:
Index: cpufunc.c
===
--- cpufunc.c (revision 267575)
+++ cpufunc.c (working copy)
@@ -1404,18 +1404,36 @@
static __inline void
cpu_scc_setup_ccnt(void)
{
-/* This is how you give userland access to the CCNT and PMCn
- * registers.
- * BEWARE! This gives write access also, which may not be what
- * you want!
- */
+#if defined(CPU_ARM1136) || defined(CPU_ARM1176)
#ifdef _PMC_USER_READ_WRITE_
- /* Set PMUSERENR[0] to allow userland access */
+ /* This is how you give userland access to the CCNT and PMCn
+ * registers.
+ * BEWARE! This gives write access also, which may not be what
+ * you want!
+ * Use the Secure User and Non-secure Access Validation Control Register
+ * to allow userland access
+ */
+ __asm volatile (mcrp15, 0, %0, c15, c9, 0\n\t
+ :
+ : r(0x0001));
+#endif
+ /* Set PMCR[2,0] to enable counters and reset CCNT */
+ __asm volatile (mcrp15, 0, %0, c15, c12, 0\n\t
+ :
+ : r(0x0005));
+#else
+#ifdef _PMC_USER_READ_WRITE_
+ /* This is how you give userland access to the CCNT and PMCn
+ * registers.
+ * BEWARE! This gives write access also, which may not be what
+ * you want!
+ * Set PMUSERENR[0] to allow userland access
+ */
__asm volatile (mcrp15, 0, %0, c9, c14, 0\n\t
:
: r(0x0001));
#endif
-/* Set up the PMCCNTR register as a cyclecounter:
+ /* Set up the PMCCNTR register as a cyclecounter:
* Set PMINTENCLR to 0x to block interrupts
* Set PMCR[2,0] to enable counters and reset CCNT
* Set PMCNTENSET to 0x8000 to enable CCNT */
@@ -1426,6 +1444,7 @@
: r(0x),
r(0x0005),
r(0x8000));
+#endif
}
#endif
Let me know if I can help.
Best regards
Michael
On 16 Jun 2014, at 20:38, Michael Tuexen tue...@freebsd.org wrote:
Hmm, the documentation reads
Which docs are you using?
I’m using DDI0360F. (And that could easily be a wrong choice).
M
--
Mark R V Murray
--
Mark R V Murray
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r266083 - in head/sys/arm: arm include
On 17 Jun 2014, at 19:58, Michael Tuexen tue...@freebsd.org wrote: So you want something like: Yup! Looks good! :-) If you want to blame me for reviewing this, thats fine, but I’ve not run it (I’m waiting for a replacement RPI, still). Please don’t be offended if a follow-up commit of mine rearranges this slightly! (It won’t be for a week or two). M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r266083 - in head/sys/arm: arm include
On 16 Jun 2014, at 08:28, Michael Tuexen tue...@freebsd.org wrote:
your patch for accessing the value is correct. However, the initialisation
code also
needs to be adopted to the platform. So in addition to your patch, you also
need:
Thanks!
Is there an easy test to see if the code actually works as expected and not
that it just
allows the system to boot?
Yes. :-)
#include sys/types.h
#include stdio.h
static __inline uint64_t
get_cyclecount(void)
{
uint32_t ccnt;
uint64_t tsc;
/* Read CCNT. */
__asm __volatile(mrc p15, 0, %0, c15, c12, 1: =r (ccnt));
tsc = (uint64_t)ccnt;
return (tsc);
}
#define N 10
int
main(int argc, char *argv[])
{
int i;
uint64_t ccnt[N];
for (i = 0; i N; i++)
ccnt[i] = get_cyclecount();
for (i = 1; i N; i++)
printf(%6d %016llX %16llu\n, i, ccnt[i], ccnt[i] - ccnt[i -
1]);
return (0);
}
Should print a whole lotta numbers, incrementing, unless you hit the wraparound.
Regarding the 32-bit limitation: Do we want to increment the register only
every
64 clock cycle?
Definitely not! The value is in the low bits; wrap is of little consequence.
M
--
Mark R V Murray
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r266083 - in head/sys/arm: arm include
On 16 Jun 2014, at 20:25, Michael Tuexen tue...@freebsd.org wrote: Should print a whole lotta numbers, incrementing, unless you hit the wraparound. Don't I need to compile a kernel with _PMC_USER_READ_WRITE_ being defined, since without it a user process can't access the register. When running it on a kernel not defining _PMC_USER_READ_WRITE_, I get a core with Illegal instruction. No. That only enables _write_ access. That’s on ARMv7. What’s in ARMv6 may also work. Let me build a kernel with the above define and retest. Please try without it. M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r266083 - in head/sys/arm: arm include
On 16 Jun 2014, at 20:38, Michael Tuexen tue...@freebsd.org wrote: Hmm, the documentation reads Which docs are you using? I’m using DDI0360F. (And that could easily be a wrong choice). M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r266083 - in head/sys/arm: arm include
On 30 May 2014, at 09:42, Michael Tuexen tue...@fh-muenster.de wrote: On 29 May 2014, at 21:21, Mark R V Murray ma...@freebsd.org wrote: On 29 May 2014, at 19:27, Michael Tuexen tue...@fh-muenster.de wrote: On 29 May 2014, at 20:15, Mark R V Murray ma...@freebsd.org wrote: On 29 May 2014, at 19:13, Michael Tuexen tue...@fh-muenster.de wrote: I can make it work on RPI, but trying to find what else it will/won’t work on is more problematic. Wouldn't it require to use different registers on the RPI? This would mean you would need more #ifdefs… Thats the problem; too many #ifdefs. So you could just keep the code for now, but reduce the #ifdefs to the ones you know that work. Later on, you can replace it by the driver stuff… That’s what I was thinking, yes. Great. Let me know if you need testing support on the RPI… I’ve come to the conclusion that my RPI-B is hosed. It doesn’t even boot Raspian properly. Sorry about how long this has taken. Please could someone with a working RPI please check that the following patch works (may need to apply by hand due to cut/paste). Thanks, with repeated apologies. M -- Mark R V Murray --- include/cpu.h (revision 267507) +++ include/cpu.h (working copy) @@ -25,7 +25,16 @@ * Read PMCCNTR. Curses! Its only 32 bits. * TODO: Fix this by catching overflow with interrupt? */ +/* The ARMv6 vs ARMv7 divide is going to need a better way of + * distinguishing between them. + */ +#if defined(CPU_ARM1136) || defined(CPU_ARM1176) + /* ARMv6 - Earlier model SCCs */ + __asm __volatile(mrc p15, 0, %0, c15, c12, 1: =r (ccnt)); +#else + /* ARMv7 - Later model SCCs */ __asm __volatile(mrc p15, 0, %0, c9, c13, 0: =r (ccnt)); +#endif ccnt64 = (uint64_t)ccnt; return (ccnt64); #else /* No performance counters, so use binuptime(9). This is slow */ ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r266083 - in head/sys/arm: arm include
On 29 May 2014, at 12:05, Hans Petter Selasky h...@selasky.org wrote: On 05/22/14 09:09, Mark R V Murray wrote: On 21 May 2014, at 21:15, Hans Petter Selasky h...@selasky.org wrote: On 05/14/14 21:11, Mark Murray wrote: Author: markm Date: Wed May 14 19:11:15 2014 New Revision: 266083 URL: http://svnweb.freebsd.org/changeset/base/266083 Log: Give suitably-endowed ARMs a register similar to the x86 TSC register. Hi, Regression issue: This commit prevents RPI-B from booting. Thanks, I’ll look at it ASAP. M Any news on this issue? Hi Yes, thanks! I can make it work on RPI, but trying to find what else it will/won’t work on is more problematic. I’m considering disabling this on RPI, and then spending a bit of time writing a full driver for this counter, then the annoying details of the problem can be solved in FDT code. M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r266083 - in head/sys/arm: arm include
On 29 May 2014, at 19:13, Michael Tuexen tue...@fh-muenster.de wrote: I can make it work on RPI, but trying to find what else it will/won’t work on is more problematic. Wouldn't it require to use different registers on the RPI? This would mean you would need more #ifdefs… Thats the problem; too many #ifdefs. M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r266083 - in head/sys/arm: arm include
On 29 May 2014, at 19:27, Michael Tuexen tue...@fh-muenster.de wrote: On 29 May 2014, at 20:15, Mark R V Murray ma...@freebsd.org wrote: On 29 May 2014, at 19:13, Michael Tuexen tue...@fh-muenster.de wrote: I can make it work on RPI, but trying to find what else it will/won’t work on is more problematic. Wouldn't it require to use different registers on the RPI? This would mean you would need more #ifdefs… Thats the problem; too many #ifdefs. So you could just keep the code for now, but reduce the #ifdefs to the ones you know that work. Later on, you can replace it by the driver stuff… That’s what I was thinking, yes. M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r266083 - in head/sys/arm: arm include
On 21 May 2014, at 21:15, Hans Petter Selasky h...@selasky.org wrote: On 05/14/14 21:11, Mark Murray wrote: Author: markm Date: Wed May 14 19:11:15 2014 New Revision: 266083 URL: http://svnweb.freebsd.org/changeset/base/266083 Log: Give suitably-endowed ARMs a register similar to the x86 TSC register. Hi, Regression issue: This commit prevents RPI-B from booting. Thanks, I’ll look at it ASAP. M -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r263218 - in head: lib/libcrypt lib/libmd sys/conf sys/crypto/sha2
On 16 Mar 2014, at 21:15, John-Mark Gurney j...@funkthat.com wrote: Mark Murray wrote this message on Sun, Mar 16, 2014 at 17:24 +: I haven?t looked at this closely, but if you?ve dropped support for sha256, then sys/dev/random/... can?t use it :-( Please read closer... To many things would break if sha256 was really removed… Oops! Thanks! *blush* M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: svn commit: r263218 - in head: lib/libcrypt lib/libmd sys/conf sys/crypto/sha2
{
- u_int32_t state[8];
- u_int64_t bitcount;
- u_int8_tbuffer[SHA256_BLOCK_LENGTH];
-} SHA256_CTX;
-typedef struct _SHA512_CTX {
- u_int64_t state[8];
- u_int64_t bitcount[2];
- u_int8_tbuffer[SHA512_BLOCK_LENGTH];
-} SHA512_CTX;
-
-#endif /* SHA2_USE_INTTYPES_H */
-
typedef SHA512_CTX SHA384_CTX;
-/*** SHA-256/384/512 Function Prototypes **/
-
-void SHA256_Init(SHA256_CTX *);
-void SHA256_Update(SHA256_CTX*, const u_int8_t*, size_t);
-void SHA256_Final(u_int8_t[SHA256_DIGEST_LENGTH], SHA256_CTX*);
-char* SHA256_End(SHA256_CTX*, char[SHA256_DIGEST_STRING_LENGTH]);
-char* SHA256_Data(const u_int8_t*, size_t,
char[SHA256_DIGEST_STRING_LENGTH]);
+/*** SHA-384/512 Function Prototypes **/
void SHA384_Init(SHA384_CTX*);
void SHA384_Update(SHA384_CTX*, const u_int8_t*, size_t);
@@ -137,4 +84,6 @@ char* SHA512_Data(const u_int8_t*, size_
}
#endif /* __cplusplus */
+#include sha256.h
+
#endif /* __SHA2_H__ */
Modified: head/sys/crypto/sha2/sha256.h
==
--- head/sys/crypto/sha2/sha256.h Sun Mar 16 01:22:23 2014
(r263217)
+++ head/sys/crypto/sha2/sha256.h Sun Mar 16 01:43:23 2014
(r263218)
@@ -29,12 +29,14 @@
#ifndef _SHA256_H_
#define _SHA256_H_
+#ifndef _KERNEL
#include sys/types.h
+#endif
typedef struct SHA256Context {
uint32_t state[8];
uint64_t count;
- unsigned char buf[64];
+ uint8_t buf[64];
} SHA256_CTX;
__BEGIN_DECLS
@@ -42,9 +44,11 @@ void SHA256_Init(SHA256_CTX *);
void SHA256_Update(SHA256_CTX *, const void *, size_t);
void SHA256_Final(unsigned char [32], SHA256_CTX *);
char *SHA256_End(SHA256_CTX *, char *);
+char *SHA256_Data(const void *, unsigned int, char *);
+#ifndef _KERNEL
char *SHA256_File(const char *, char *);
char *SHA256_FileChunk(const char *, char *, off_t, off_t);
-char *SHA256_Data(const void *, unsigned int, char *);
+#endif
__END_DECLS
#endif /* !_SHA256_H_ */
Modified: head/sys/crypto/sha2/sha256c.c
==
--- head/sys/crypto/sha2/sha256c.cSun Mar 16 01:22:23 2014
(r263217)
+++ head/sys/crypto/sha2/sha256c.cSun Mar 16 01:43:23 2014
(r263218)
@@ -30,7 +30,11 @@ __FBSDID($FreeBSD$);
#include sys/endian.h
#include sys/types.h
+#ifdef _KERNEL
+#include sys/systm.h
+#else
#include string.h
+#endif
#include sha256.h
--
Mark R V Murray
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: svn commit: r257535 - head/sys/netgraph
On 2 Nov 2013, at 05:53, Adrian Chadd adr...@freebsd.org wrote: Hm! A good question! On 1 November 2013 22:22, Bruce Evans b...@optusnet.com.au wrote: if (harvest.point_to_point) - random_harvest((m-m_data), 12, 2, RANDOM_NET_NG); '(m-m_data)' is not just a pair of style bugs. It gives address of the pointer (somewhere in the mbuf header), not the address of pointed- to data, so the randomness was almost null. The style bugs are excessive parentheses and chumminess with the implementation (non-use of the accessor function mtod()). + random_harvest(mtod(m, const void *), 12, 2, RANDOM_NET_NG); Presumably you really do want to harvest the pointed-to data and there are at least 12 bytes of it, so the semantic fix isn't backwards or a buffer overrun. Mark - did you initially mean the address of the mbuf m_data pointer, or the data payload itself? As Bruce says - the address of payload data itself. We don’t have 12-byte pointers in FreeBSD. :-) M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: svn commit: r257535 - head/sys/netgraph
On 2 Nov 2013, at 09:32, Mark R V Murray m...@grondar.org wrote: Mark - did you initially mean the address of the mbuf m_data pointer, or the data payload itself? As Bruce says - the address of payload data itself. We don’t have 12-byte pointers in FreeBSD. :-) Cancel that. The address passed must be the address of the m_data field in the mbuf structure. The harvested data is 12 bytes from that address forward, so not the data pointed to by that m_data pointer but the pointer value itself and some following junk too. M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: svn commit: r257535 - head/sys/netgraph
On 2 Nov 2013, at 22:28, Bruce Evans b...@optusnet.com.au wrote: On Sat, 2 Nov 2013, Mark R V Murray wrote: On 2 Nov 2013, at 09:32, Mark R V Murray m...@grondar.org wrote: Mark - did you initially mean the address of the mbuf m_data pointer, or the data payload itself? As Bruce says - the address of payload data itself. We don’t have 12-byte pointers in FreeBSD. :-) Cancel that. The address passed must be the address of the m_data field in the mbuf structure. The harvested data is 12 bytes from that address forward, so not the data pointed to by that m_data pointer but the pointer value itself and some following junk too. Is that really worth using? Yes. Most of the value comes from the timing. The 12 bytes we snatch on the way past are opportunistic, and hopefully cheap due to being in-cache. M -- -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: svn commit: r256377 - in head: etc/defaults etc/rc.d share/examples/kld/random_adaptor share/man/man4 sys/boot/forth sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe
On 13 Oct 2013, at 08:48, Konstantin Belousov kostik...@gmail.com wrote: On Sat, Oct 12, 2013 at 12:57:57PM +, Mark Murray wrote: Author: markm Date: Sat Oct 12 12:57:57 2013 New Revision: 256377 URL: http://svnweb.freebsd.org/changeset/base/256377 Log: Merge from project branch. Uninteresting commits are trimmed. Refactor of /dev/random device. Main points include: The random.ko is broken. On boot, I get link_elf_obj: symbol live_entropy_source_deregister undefined KLD file random.ko - could not finalize loading There are several files from dev/random which are listed as 'optional random' in conf/files but are not added to the SRCS in modules/random/Makefile. I do not know the intent of splitting the dev/random into the module and non-optional part of the kernel, so cannot provide the patch. Ah - I know what is going on here. Fix coming, thanks! M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: svn commit: r256377 - in head: etc/defaults etc/rc.d share/examples/kld/random_adaptor share/man/man4 sys/boot/forth sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe
On 13 Oct 2013, at 08:48, Konstantin Belousov kostik...@gmail.com wrote: On Sat, Oct 12, 2013 at 12:57:57PM +, Mark Murray wrote: Author: markm Date: Sat Oct 12 12:57:57 2013 New Revision: 256377 URL: http://svnweb.freebsd.org/changeset/base/256377 Log: Merge from project branch. Uninteresting commits are trimmed. Refactor of /dev/random device. Main points include: The random.ko is broken. On boot, I get link_elf_obj: symbol live_entropy_source_deregister undefined KLD file random.ko - could not finalize loading There are several files from dev/random which are listed as 'optional random' in conf/files but are not added to the SRCS in modules/random/Makefile. I do not know the intent of splitting the dev/random into the module and non-optional part of the kernel, so cannot provide the patch. Please fix. Here's the fix: Index: sys/modules/random/Makefile === --- sys/modules/random/Makefile (revision 256427) +++ sys/modules/random/Makefile (working copy) @@ -10,7 +10,8 @@ SRCS+= nehemiah.c SRCS+= ivy.c .endif -SRCS+= randomdev_soft.c yarrow.c hash.c +SRCS+= randomdev_soft.c random_harvestq.c live_entropy_sources.c +SRCS+= yarrow.c hash.c rwfile.c SRCS+= rijndael-alg-fst.c rijndael-api-fst.c sha2.c SRCS+= bus_if.h device_if.h vnode_if.h opt_cpu.h opt_random.h M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: svn commit: r256377 - in head: etc/defaults etc/rc.d share/examples/kld/random_adaptor share/man/man4 sys/boot/forth sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe
On 13 Oct 2013, at 16:13, Konstantin Belousov kostik...@gmail.com wrote: Surely this works, thank you. The rwfile.c content probably should be taken under the #ifdef RANDOM_RWFILE. OK - thanks for the feedback! But I do not see much use for the randomdev_read_file() and randomdev_write_file() functions. It would be better to directly code the VFS calls in the random_harvestq_cache(). For one thing, it would eliminate unneccessary close and open of the entropy file. There is some uncertainty about the future of that code, so I want to keep it that way for now. Writing files from the kernel is making so@ very uncomfortable, and there is too much scope for error there. We'll settle it down properly in 11.*. M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: svn commit: r256377 - in head: etc/defaults etc/rc.d share/examples/kld/random_adaptor share/man/man4 sys/boot/forth sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe
On 13 Oct 2013, at 17:18, Ian Lepore i...@freebsd.org wrote: On Sun, 2013-10-13 at 16:18 +0100, Mark R V Murray wrote: On 13 Oct 2013, at 16:13, Konstantin Belousov kostik...@gmail.com wrote: Surely this works, thank you. The rwfile.c content probably should be taken under the #ifdef RANDOM_RWFILE. OK - thanks for the feedback! But I do not see much use for the randomdev_read_file() and randomdev_write_file() functions. It would be better to directly code the VFS calls in the random_harvestq_cache(). For one thing, it would eliminate unneccessary close and open of the entropy file. There is some uncertainty about the future of that code, so I want to keep it that way for now. Writing files from the kernel is making so@ very uncomfortable, and there is too much scope for error there. Indeed, it makes me nervous too, as a heavy user of readonly root filesystems. If writing this file is so critical that it has to be done by the kernel, then what happens when it fails? Right now it prints an error and continues -- if it is not so critical that failure means panic, then why is the kernel doing it at all? Good points all. The intent is not to win the arms-race outright, but to win the common-case battles as convincingly as possible. That said, its not looking good for the process, but I still want to give it a decent look before/if yanking it. Why is the file even in the root filesystem? /var/db seems to be the right place for a transient file needed by the system. Because that appears to be the best place to put first-boot entropy from sysinstall/bsdinstall. /var/db/entropy/... will also be used if possible; watch this space. Speaking of errors, that might include things like the current code calling vn_close() with the FREAD flag on a file open for writing. Thanks :-( :-) M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: svn commit: r256377 - in head: etc/defaults etc/rc.d share/examples/kld/random_adaptor share/man/man4 sys/boot/forth sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe
On 13 Oct 2013, at 19:08, Adrian Chadd adr...@freebsd.org wrote: Hi Mark, Can we make the VFS random seeding stuff a compile time option, so we can disable it for the embedded platforms where we'll never use it? Like 'options RANDOM_RWFILE'? M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: svn commit: r256377 - in head: etc/defaults etc/rc.d share/examples/kld/random_adaptor share/man/man4 sys/boot/forth sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe
On 12 Oct 2013, at 17:27, Adrian Chadd adr...@freebsd.org wrote: hihi, I've just test booted this on a MIPS board. It doesn't hang at boot waiting for entropy. http://people.freebsd.org/~adrian/mips/20131012-ar9344-boot-1.txt Thanks! You are most welcome! M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: svn commit: r256377 - in head: etc/defaults etc/rc.d share/examples/kld/random_adaptor share/man/man4 sys/boot/forth sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe
On 12 Oct 2013, at 17:35, Teske, Devin devin.te...@fisglobal.com wrote: Can you maybe test with ZFS + Geli? I'm concerned because we told it to use random(4) instead of urandom(4). I hope there's enough entropy when creating the geli stuff that said process doesn't hang. I think DES's patch will help there too (not that anyone testing our ZFS patches reported any hangs... including when testing GELI -- this was before DES's patch). urandom is a symlink to random. M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: svn commit: r256377 - in head: etc/defaults etc/rc.d share/examples/kld/random_adaptor share/man/man4 sys/boot/forth sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe
On 12 Oct 2013, at 17:44, Teske, Devin devin.te...@fisglobal.com wrote: You know... for years I've been compiling a custom apache for $work and using the --with-random=/dev/urandom flag. And then recently in the past couple years in 8.x I recall having problems with a GnuPG related tool that would hang due to lack of entropy on a freshly installed box when generating stuff using random(4). Are the days of choosing between urandom(4) and random(4) over? They were over last millennium :-) Would SSL function great on a freshly installed box even if using random(4) for apache? (it wants to default to /dev/random anyways) Yup! No worse than usual. M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: svn commit: r256377 - in head: etc/defaults etc/rc.d share/examples/kld/random_adaptor share/man/man4 sys/boot/forth sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe
On 12 Oct 2013, at 17:49, Teske, Devin devin.te...@fisglobal.com wrote: Doubly-thanks! Glad to be useful. M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: svn commit: r256377 - in head: problems on ARM BEAGLEBONE
On 13 Oct 2013, at 01:07, Ian Lepore i...@freebsd.org wrote: It looks like the cause of the problem is that both the dummy and the yarrow generators register, dummy first, and so it gets chosen even though yarrow is available. Correct diagnosis! This is now fixed; sorry for the hassle. M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: svn commit: r255362 - in head: share/examples/kld share/examples/kld/random_adaptor sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe sys/dev/ubsec sys/kern sys/mips/
On 7 Sep 2013, at 17:40, Dag-Erling Smørgrav d...@des.no wrote: Mark Murray ma...@freebsd.org writes: Log: Bring in some behind-the-scenes development, mainly By Arthur Mesh, the rest by me. Umm, this should have been submitted to secteam@ for review. My bad. I made the presumption that since we had discussed it in person that this would be OK, so my fault. I'd prefer not to churn by backing out, but will do so if needed. M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: svn commit: r255362 - in head: share/examples/kld share/examples/kld/random_adaptor sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe sys/dev/ubsec sys/kern sys/mips/
On 7 Sep 2013, at 17:55, Glen Barber g...@freebsd.org wrote: On Sat, Sep 07, 2013 at 06:40:32PM +0200, Dag-Erling Smørgrav wrote: Mark Murray ma...@freebsd.org writes: Log: Bring in some behind-the-scenes development, mainly By Arthur Mesh, the rest by me. Umm, this should have been submitted to secteam@ for review. This also causes problems booting when /dev/random is nonexistent. See the new thread on -current@ with subject random(4) update causes mips compile fail | mips boot fail. Sean confirmed r255361 does not exhibit the boot failure. I can't find that thread :-( M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: svn commit: r255362 - in head: share/examples/kld share/examples/kld/random_adaptor sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe sys/dev/ubsec sys/kern sys/mips/
On 7 Sep 2013, at 18:20, Dag-Erling Smørgrav d...@des.no wrote: Mark R V Murray m...@grondar.org writes: Dag-Erling Smørgrav d...@des.no writes: Umm, this should have been submitted to secteam@ for review. I made the presumption that since we had discussed it in person that this would be OK, so my fault. We discussed the outline, but we still need to review the details. I'd prefer not to churn by backing out, but will do so if needed. I'm reviewing the patch as we speak. I haven't yet seen anything that would justify reverting the commit, but the mips breakage Glen mentioned needs to be fixed. OK, thanks, I'm on that MIPS breakage. M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP using GPGMail
Re: svn commit: r255362 - in head: share/examples/kld share/examples/kld/random_adaptor sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe sys/dev/ubsec sys/kern sys/mips/
On 7 Sep 2013, at 19:34, Dag-Erling Smørgrav d...@des.no wrote:
I didn't see anything that deviated from the plan we agreed upon in
Cambridge.
That was the idea! :-D
Several random_harvest() calls have been changed to reduce the entropy
estimate - that's a good thing (as long as we don't reduce it to an
unusable level, which I don't think is the case). I also see that the
network entropy harvesting bug we talked about has been fixed, which is
also a good thing. As far as I can tell, these are the only changes
which affect the quality of the output.
Indeed.
The renaming part made the patch hard to read - IWBNI it had been
committed separately, but it didn't kill me. Another factor that
reduces readability is that the patch needlessly unfolds
previously wrapped lines, e.g.
- if (++random_state.outputblocks =
- random_state.gengateinterval) {
+ if (++random_state.outputblocks =
random_state.gengateinterval) {
which doesn't actually change anything but introduces a style bug and
increases the reviewers' workload. In fact, the patch introduces quite
a few style bugs (including some that I personally aprove of but bde@
may complain about, such as s/u_char/uint8_t/), but that can be
addressed when we get a fresh batch of round tuts.
Apologies for making your life hard; that was unintended. I'll be working on
this code some more; I'll fix those long lines then.
(joking aside - barring an overriding reason, we should strive to always
conform to style(9))
Indeed; while this may not be a perfect lurch in that direction, the uintN_t
changes were a style(9) nod.
In Yarrow, buffer sizes are now consistently referred to by BLOCKSIZE
rather than a mix of BLOCKSIZE and (int)sizeof(whatever), which improves
code readability at the cost of patch readability. However, it appears
that the *meaning* of BLOCKSIZE has changed from bits to bytes, and if I
read the code correctly, it used to be 256 bits but is now 128.
Correct; it was a mess and I tidied it up. Having 256-bit blocks bought
us nothing; the intent is to use the natural key and block sizes of the
AES and SHA256 building-blocks.
I dislike the use of pseudo in sys/dev/random/pseudo_rng.c since it is
easily confused with the P in PRNG and pseudo_rng.c is actually not a
PRNG but rather a collection of fake or dummy RNGs for testing purposes.
Perhaps s/pseudo/dummy/g would be in order.
Good point. I'll do that.
So, this is a provisional OK from my part. *However*, I did not review
the new harvesting queue in detail, and a bug there could, in the worst
case, result in all the harvested entropy being discarded and Yarrow
receiving kilobyte upon kilobyte of zeroes; so I'd like to get a second
opinion.
Of course!
M
--
Mark R V Murray
signature.asc
Description: Message signed with OpenPGP using GPGMail
