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 wrote: > > Mark Murray 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-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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 Sat, Jul 25, 2015 at 10:30:55AM -0700, John-Mark Gurney wrote: > Alexey Dokuchaev wrote this message on Sat, Jul 25, 2015 at 14:36 +: > > On Fri, Jul 24, 2015 at 07:59:35AM +0100, Mark R V Murray wrote: > > > [...] > > > > 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. > > > > I like the microphone idea. Not just it adds another hard-to-mess-with > > (?) entropy source, it can also be a nice "reference" example for people > > wanting to write their own sources and plug them into the RNG framework. > > Shouldn't be done in kernel, just do it from userland, by adding the > following to cron: > 3 * * * * rootsleep $(jot -r 1 120 1); dd > if=/dev/dsp bs=512 count=5 2>/dev/null | sha512 > /dev/random Hey, that's nice, thanks! I didn't realize from reading random(4) that it can be fed like this. Perhaps manpage should be updated (the cron trick could be a nice candidate for EXAMPLES section or something)... ./danfe ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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
kpn...@pobox.com wrote this message on Sun, Jul 26, 2015 at 18:51 -0400: > > Microphones don???t typically exist on virtual machines, servers, > > appliances/embedded gadgets, and trusted computers. Nice idea for the > > desktop, but far from universal. > > Personally, I _hate_ the idea of having a mic on my desktop. If the machine > is hacked the mic can be turned against me. Same with cameras. If there > is no mic (and no camera) then I can't be harmed in this way. I should have been more clear on my use of the "mic"... I'm only talking about using the mic input w/o a mic attached... Even w/o the mic attached, there are slight variations in the input due to the ADC and pre-amp... > There have been women who were blackmailed because they took their laptop > with them when they were bathing. Obviously I'm not going to be blackmailed > in this way (I'm a guy, for starters), but the principle holds. I want to > be able to hold a private conversation in the same room as my computer and > not have to worry about anyone listening in. It's impossible for FreeBSD to attach a mic if there isn't one already attached, nor will it ever be required to attach one to run FreeBSD. Also, if one is hardwired, like in many laptops, using it for randomness won't increase or decrease the likelyhood of the above happening... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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 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 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-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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
Mark R V Murray wrote this message on Sat, Jul 25, 2015 at 20:24 +0100: > > On 25 Jul 2015, at 19:31, John-Mark Gurney 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. I have been following the discussions that Ian and you have had publicly, so I understand the issues involved... I agree we should provide Ian w/ the tools necessary for his boxes to have sufficient entropy... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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 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-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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
Scott Long wrote this message on Sat, Jul 25, 2015 at 10:04 -0600: > > On Jul 25, 2015, at 8:36 AM, Alexey Dokuchaev wrote: > > > > On Fri, Jul 24, 2015 at 07:59:35AM +0100, Mark R V Murray wrote: > >> [...] > >>> 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. > > > > I like the microphone idea. Not just it adds another hard-to-mess-with > > (?) entropy source, it can also be a nice "reference" example for people > > wanting to write their own sources and plug them into the RNG framework. > > > > Microphones don???t typically exist on virtual machines, servers, > appliances/embedded gadgets, and trusted computers. Nice idea for the > desktop, but far from universal. 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... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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
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 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'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... 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... > 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? 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)... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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
Alexey Dokuchaev wrote this message on Sat, Jul 25, 2015 at 14:36 +: > On Fri, Jul 24, 2015 at 07:59:35AM +0100, Mark R V Murray wrote: > > [...] > > > 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. > > I like the microphone idea. Not just it adds another hard-to-mess-with > (?) entropy source, it can also be a nice "reference" example for people > wanting to write their own sources and plug them into the RNG framework. Shouldn't be done in kernel, just do it from userland, by adding the following to cron: 3 * * * * rootsleep $(jot -r 1 120 1); dd if=/dev/dsp bs=512 count=5 2>/dev/null | sha512 > /dev/random -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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 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-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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 Jul 25, 2015, at 2:10 AM, Mark R V Murray wrote: > > >> On 25 Jul 2015, at 06:06, Scott Long 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. :-) What you posted this morning for review is a great start. Thanks for the productive conversation on this. Scott ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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 Jul 25, 2015, at 8:36 AM, Alexey Dokuchaev wrote: > > On Fri, Jul 24, 2015 at 07:59:35AM +0100, Mark R V Murray wrote: >> [...] >>> 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. > > I like the microphone idea. Not just it adds another hard-to-mess-with > (?) entropy source, it can also be a nice "reference" example for people > wanting to write their own sources and plug them into the RNG framework. > Microphones don’t typically exist on virtual machines, servers, appliances/embedded gadgets, and trusted computers. Nice idea for the desktop, but far from universal. Scott ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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 Fri, Jul 24, 2015 at 07:59:35AM +0100, Mark R V Murray wrote: > [...] > > 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. I like the microphone idea. Not just it adds another hard-to-mess-with (?) entropy source, it can also be a nice "reference" example for people wanting to write their own sources and plug them into the RNG framework. ./danfe ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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 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-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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 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-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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
Scott Long wrote this message on Fri, Jul 24, 2015 at 23:06 -0600: > > > On Jul 24, 2015, at 12:59 AM, Mark R V Murray wrote: > > > >> On 24 Jul 2015, at 02:25, John-Mark Gurney wrote: > > > >> 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. > > 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 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.] -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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
Mark R V Murray wrote this message on Fri, Jul 24, 2015 at 07:59 +0100: > > On 24 Jul 2015, at 02:25, John-Mark Gurney 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. Except that we should set a sane default policy. Hashing 136 bytes of the mbuf of every ethernet packet isn't a sane default policy. I'm not saying don't have the hooks, but as Scott and others would like, they need to be turned off by default... > > 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. Well, just a random proposal to allow both, but these points should be turned off by default, not enabled by default... > > 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. I'm fine w/ more choices, but we need to make sure we have sane defaults.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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 Jul 24, 2015, at 12:59 AM, Mark R V Murray wrote: > > >> On 24 Jul 2015, at 02:25, John-Mark Gurney 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. > Sure, and that’s not an unreasonable goal, but the devil is in the details. 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? >> 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 ;-) >> 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. > 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 ;-) Scott ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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 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-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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 Fri, 2015-07-24 at 07:59 +0100, Mark R V Murray wrote: > > On 24 Jul 2015, at 02:25, John-Mark Gurney 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. > But keep in mind that loader(8) is optional and not used at all on some non-x86 systems. -- Ian ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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 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-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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
Scott Long wrote this message on Thu, Jul 23, 2015 at 07:45 -0600: > > On Jul 23, 2015, at 1:03 AM, Mark R V Murray wrote: > > > > > >> On 23 Jul 2015, at 00:53, Warner Losh 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. :-) > > > > > > 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. > > 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. > > 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
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 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-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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 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-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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
[ Guys, please teach your MUA to wrap messages over 72-76 boundary and trim excessive/irrelevant quoting, thank you. ] On Thu, Jul 23, 2015 at 07:45:14AM -0600, Scott Long via svn-src-all wrote: > > On Jul 23, 2015, at 1:03 AM, Mark R V Murray wrote: > > 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. [...] Being not a crypto-guy by any means, I find this reasoning sound and fair. But read on... > 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 [that in] the end, a lot of code thrash > happened and the effectiveness of Yarrow was questionable. > > 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. [...] That'll be a huge step > backwards for FreeBSD. > > 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? [...] > An academically beautiful entropy system that hamstrings the OS from > doing other essential things isn't all that interesting, IMO. 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.) 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. 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? 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? Is there some sort of restricted, private API to get a clue about current entropy status? ./danfe ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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 Jul 23, 2015, at 1:03 AM, Mark R V Murray wrote: > > >> On 23 Jul 2015, at 00:53, Warner Losh 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. :-) > > 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. 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. 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. Scott ___ svn-src-head@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 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-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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 Thu, 23 Jul 2015, Mark R V Murray wrote: On 23 Jul 2015, at 00:53, Warner Losh 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. :-) 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. 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. Thanks, Jeff M -- Mark R V Murray ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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 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-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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 Jul 22, 2015, at 4:53 PM, Jeff Roberson wrote: > > On Wed, 22 Jul 2015, Mark R V Murray wrote: > >> >>> On 22 Jul 2015, at 22:42, Jeff Roberson 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. I’m not sure I’m happy about this answer. Do you have some research backing up such cavalier claims? >>> 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. Warner signature.asc Description: Message signed with OpenPGP using GPGMail
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 Wed, 22 Jul 2015, Mark R V Murray wrote: On 22 Jul 2015, at 22:42, Jeff Roberson 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 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. Thanks, Jeff 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-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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 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-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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 Tue, 30 Jun 2015, Mark Murray wrote: Author: markm Date: Tue Jun 30 17:00:45 2015 New Revision: 284959 URL: https://svnweb.freebsd.org/changeset/base/284959 Log: Huge cleanup of random(4) code. * GENERAL - Update copyright. - Make kernel options for RANDOM_YARROW and RANDOM_DUMMY. Set neither to ON, which means we want Fortuna - If there is no 'device random' in the kernel, there will be NO random(4) device in the kernel, and the KERN_ARND sysctl will return nothing. With RANDOM_DUMMY there will be a random(4) that always blocks. - Repair kern.arandom (KERN_ARND sysctl). The old version went through arc4random(9) and was a bit weird. - Adjust arc4random stirring a bit - the existing code looks a little suspect. - Fix the nasty pre- and post-read overloading by providing explictit functions to do these tasks. - Redo read_random(9) so as to duplicate random(4)'s read internals. This makes it a first-class citizen rather than a hack. - Move stuff out of locked regions when it does not need to be there. - Trim RANDOM_DEBUG printfs. Some are excess to requirement, some behind boot verbose. - Use SYSINIT to sequence the startup. - Fix init/deinit sysctl stuff. - Make relevant sysctls also tunables. - Add different harvesting "styles" to allow for different requirements (direct, queue, fast). - Add harvesting of FFS atime events. This needs to be checked for weighing down the FS code. - 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. 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. Thanks, Jeff - Fix the random(9) manpage. - Loadable modules are not present for now. These will be re-engineered when the dust settles. - Use macros for locks. - Fix comments. * src/share/man/... - Update the man pages. * src/etc/... - The startup/shutdown work is done in D2924. * src/UPDATING - Add UPDATING announcement. * src/sys/dev/random/build.sh - Add copyright. - Add libz for unit tests. * src/sys/dev/random/dummy.c - Remove; no longer needed. Functionality incorporated into randomdev.*. * live_entropy_sources.c live_entropy_sources.h - Remove; content moved. - move content to randomdev.[ch] and optimise. * 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. * src/sys/dev/random/random_harvestq.c src/sys/dev/random/random_harvestq.h - Add early (re)boot-time randomness caching. * src/sys/dev/random/randomdev_soft.c src/sys/dev/random/randomdev_soft.h - Remove; no longer needed. * src/sys/dev/random/uint128.h - Provide a fake uint128_t; if a real one ever arrived, we can use that instead. All that is needed here is N=0, N++, N==0, and some localised trickery is used to manufacture a 128-bit 0ULLL. * src/sys/dev/random/unit_test.c src/sys/dev/random/unit_test.h - Improve unit tests; previously the testing human needed clairvoyance; now the test will do a basic check of compressibility. Clairvoyant talent is still a good idea. - This is still a long way off a proper unit test. * src/sys/dev/random/fortuna.c src/sys/dev/random/fortuna.h - Improve messy union to just uint128_t. - Remove unneeded 'static struct fortuna_start_cache'. - Tighten up up arithmetic. - Provide a method to allow eternal junk to be introduced; harden it against blatant by compress/hashing. - Assert that locks are held correctly. - Fix the nasty pre- and post-read overloading by providing explictit functions to do these tasks. - Turn into self-sufficient module (no longer requires randomdev_soft.[ch]) * src/sys/dev/random/yarrow.c src/sys/dev/random/yarrow.h - Improve messy union to just uint128_t. - Remove unneeded 'staic struct start_cache'. - Tighten up up arithmetic. - Provide a method to allow eternal junk to be introduced; harden it against blatant by compress/hashing. - Assert that locks are held correctly. - Fix the nasty pre- and post-read overloading by providing explictit functions to do these tasks. - Turn into self-sufficient module (no longer requires randomdev_soft.[ch]) - Fix some magic numbers elsewhere used as FAST and SLOW. Differential Revision: https://reviews.freebsd.org/D2025 Reviewed by: vsevolod,delphij,rwatson,trasz,jmg Approved by: so (delphij) Added: head/sys/dev/random/randomdev_none.c (contents, props changed) - copie
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
> > Mark, do you have an estimate of when loadable modules will be supported > > again? > > About a week, I’d say. Thanks! Will keep an eye out. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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 wrote: > > Mark R V Murray 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-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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
Mark R V Murray 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? We've been holding off sync'ing from head - which is hardly ideal. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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 wrote: > > On Fri, Jul 17, 2015 at 3:01 PM, Mark R V Murray wrote: >> >>> On 17 Jul 2015, at 22:39, K. Macy 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-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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 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-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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
hi,
So I'll have to update the AP images that I build, as now I have to
add that sysctl to things.
It also means everyone has to update their /etc after updating or
they'll end up with this particular mode not being disabled.
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.
-adrian
On 16 July 2015 at 16:14, K. Macy wrote:
> On Thu, Jul 16, 2015 at 3:28 PM, K. Macy wrote:
>> I discovered this when I MFC'd and my kernel wouldn't link because of
>> unresolved symbols. I thought I had put the issue aside when I added
>> RANDOM_DUMMY to my kernel config.
>>
>> However, I just hit this:
>>
>> while (!random_alg_context.ra_seeded()) {
>> if (nonblock) {
>> error = EWOULDBLOCK;
>> break;
>> }
>> tsleep(&random_alg_context, 0, "randseed", hz/10);
>> /* keep tapping away at the pre-read until we seed/unblock.
>> */
>> random_alg_context.ra_pre_read();
>> printf("random: %s unblock wait\n", __func__);
>> }
>>
>> My system wouldn't boot because this was endlessly spamming the
>> console. I don't know what the right default here is. But I can say
>> that this is not it.
>
>
> I've also realized that a process blocked here is uninterruptible.
> Hence any process reading an insufficiently seeded /dev/random is
> unkillable. For example my boot can't proceed past dd doing a read and
> I can't ^C it. Did you test RANDOM_DUMMY?
>
>
> -K
>
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-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 Thu, Jul 16, 2015 at 3:28 PM, K. Macy wrote:
> I discovered this when I MFC'd and my kernel wouldn't link because of
> unresolved symbols. I thought I had put the issue aside when I added
> RANDOM_DUMMY to my kernel config.
>
> However, I just hit this:
>
> while (!random_alg_context.ra_seeded()) {
> if (nonblock) {
> error = EWOULDBLOCK;
> break;
> }
> tsleep(&random_alg_context, 0, "randseed", hz/10);
> /* keep tapping away at the pre-read until we seed/unblock. */
> random_alg_context.ra_pre_read();
> printf("random: %s unblock wait\n", __func__);
> }
>
> My system wouldn't boot because this was endlessly spamming the
> console. I don't know what the right default here is. But I can say
> that this is not it.
I've also realized that a process blocked here is uninterruptible.
Hence any process reading an insufficiently seeded /dev/random is
unkillable. For example my boot can't proceed past dd doing a read and
I can't ^C it. Did you test RANDOM_DUMMY?
-K
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-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
I discovered this when I MFC'd and my kernel wouldn't link because of
unresolved symbols. I thought I had put the issue aside when I added
RANDOM_DUMMY to my kernel config.
However, I just hit this:
while (!random_alg_context.ra_seeded()) {
if (nonblock) {
error = EWOULDBLOCK;
break;
}
tsleep(&random_alg_context, 0, "randseed", hz/10);
/* keep tapping away at the pre-read until we seed/unblock. */
random_alg_context.ra_pre_read();
printf("random: %s unblock wait\n", __func__);
}
My system wouldn't boot because this was endlessly spamming the
console. I don't know what the right default here is. But I can say
that this is not it.
I would also like to observe that a good back of the envelope
per-packet budget is 1000 cycles (stock FreeBSD is much worse than
this - nonetheless it is a reasonable figure to strive for). Many
drivers will for a variety of reasons allocate mbufs and clusters
separately. This means that if you're harvesting on alloc / free, your
function is being called 4 times per-packet. Let's have a hypothetical
that your function takes 50 cycles* - in this case your entropy
collection would be consuming a full 20% of the per-packet budget. At
high-packet rates your entropy is likely to be caused more by
indeterminacy of cache misses and lock contention than any true
randomness in the arrival rate.
* It may be less, it may be much more.
I'm not sure where the workflow fell short in this instance, but I'm
inclined to believe that this could have been handled better.
-K
On Thu, Jul 16, 2015 at 11:29 AM, Mark R V Murray wrote:
>
>> On 16 Jul 2015, at 15:08, Ian Lepore wrote:
>>
>> On Thu, 2015-07-16 at 06:39 +0100, Mark Murray wrote:
On 15 Jul 2015, at 23:43, Adrian Chadd 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-head@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/svn-src-head
> To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-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 wrote: > > On Thu, 2015-07-16 at 06:39 +0100, Mark Murray wrote: >>> On 15 Jul 2015, at 23:43, Adrian Chadd 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-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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 Thu, 2015-07-16 at 06:39 +0100, Mark Murray wrote: > > On 15 Jul 2015, at 23:43, Adrian Chadd 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? -- Ian ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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 15 Jul 2015, at 23:43, Adrian Chadd 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 -- ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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 30 June 2015 at 10:00, Mark Murray wrote: > Author: markm > Date: Tue Jun 30 17:00:45 2015 > New Revision: 284959 > URL: https://svnweb.freebsd.org/changeset/base/284959 > - Add harvesting of FFS atime events. This needs to be checked for > weighing down the FS code. > - 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? -adrian ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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 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-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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 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).
/*
* $Id: $
*
* Copyright (c) 2014, Juniper Networks, Inc.
* All rights reserved.
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include "hmac.h"
#include "hmac_shim.h"
#include "hmac_drbg.h"
#include "hmac_drbg_adaptor.h"
#include "health_tests.h"
#include "debug.h"
/*
* The context mutex protects the consistency of the hmac_drbg state
*/
struct mtx drbg_mtx;
static int hmac_drbg_security_level = 256;
/*
* hmac_drbg context
*/
static struct random_hmac_drbg_s drbg_ctx;
static void random_hmac_drbg_init(void);
static void random_hmac_drbg_deinit(void);
static int random_hmac_drbg_block(int);
static int random_hmac_drbg_read(void *, int);
static void random_hmac_drbg_write(void *, int);
static int random_hmac_drbg_poll(int, struct thread *);
static void random_hmac_drbg_reseed(void);
void random_hmac_drbg_unblock(void);
struct random_adaptor random_hmac_drbg = {
.ident = "Software, HMAC DRBG, NIST 800-90A",
.init = random_hmac_drbg_init,
.deinit = random_hmac_drbg_deinit,
.block = random_hmac_drbg_block,
.read = random_hmac_drbg_read,
.poll = random_hmac_drbg_poll,
.reseed = random_hmac_drbg_reseed,
.seeded = 0,
};
/* entropy bit counter */
uint64_t random_hmac_drbg_ecount;
void
random_hmac_drbg_unblock(void)
{
if (!random_hmac_drbg.seeded) {
random_hmac_drbg.seeded = 1;
selwakeuppri(&random_hmac_drbg.rsel, PUSER);
wakeup(&random_hmac_drbg);
}
}
static void
hmac_drbg_process_event(struct harvest *event)
{
/* If entropy health test fails, discard the entropy */
if (entropy_health_test(event) != 0) {
return;
}
/*
* Feed noise in to our DRBG.
* Performance optimization: even though not all fields in event are
* entropic, it's much faster to call random_hmac_drbg_write() on the
* whole struct, vs calling random_hmac_drbg_write() separately for
* event->somecounter and event->entropy.
*/
random_hmac_drbg_write(event, sizeof(*event));
random_hmac_drbg_ecount += event->bits;
if (random_hmac_drbg_ecount >= hmac_drbg_security_level)
random_hmac_drbg_unblock(); /* Unblock random(4) */
}
void
random_hmac_drbg_init(void)
{
int error;
mtx_init(&drbg_mtx, "hmac_drbg context mutex", NULL, MTX_DEF);
error = hmac_drbg_init(&drbg_ctx, NULL);
KASSERT(error == 0, ("hmac_drbg_init() failure: %d\n", error));
random_harvestq_init(hmac_drbg_process_event);
/* Register the randomness harvesting routine */
randomdev_init_harvester(random_harvestq_internal,
random_hmac_drbg_read);
}
static void
random_hmac_drbg_deinit(void)
{
mtx_destroy(&drbg_mtx);
}
static int
random_hmac_drbg_block(int flag)
{
int error = 0;
mtx_lock(&drbg_mtx);
while (!random_hmac_drbg.seeded && !error) {
if (flag & O_NONBLOCK)
error = EWOULDBLOCK;
else {
printf("Entropy device is blocking.\n");
error = msleep(&random_hmac_drbg,
&drbg_mtx, PUSER | PCATCH, "block", 0);
}
}
mtx_unlock(&drbg_mtx);
return (error);
}
static int
random_hmac_drbg_read(void *buf, int count)
{
int error;
mtx_lock(&drbg_mtx);
error = hmac_drbg_get_bytes(&drbg_ctx, buf, count);
KASSERT(error != -1, ("hmac_drbg_get_bytes() failure: %d\n",
error));
mtx_unlock(&drbg_mtx);
return(error != -1 ? count : 0);
}
static void
random_hmac_drbg_write(void *buf, int count)
{
int error;
mtx_lock(&drbg_mtx);
error = hmac_drbg_update(&drbg_ctx, buf, count);
KASSERT(error == 0, ("hmac_drbg_update() failure: %d\n", error));
mtx_unlock(&drbg_mtx);
}
static int
random_hmac_drbg_poll(int events, struct thread *td)
{
int revents = 0;
mtx_lock(&drbg_mtx);
if (random_hmac_drbg.seeded)
revents = events & (POLLIN | POLLRDNORM);
else
selrecord(td, &random_hmac_drbg.rsel);
mtx_unlock(&d
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 wrote: > > Mark R V Murray 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-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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 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-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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 July 2015 at 12:17, Arthur Mesh wrote: > On Thu, Jul 02, 2015 at 12:13:54PM -0700, Adrian Chadd wrote: >> Could we please get something like this implemented in upstream >> FreeBSD? I'm sure a number of vendors would like to see a (not by >> default) FIPS-140 random number generator provided. It'd certainly be >> a good check list item for people evaluating the use of freebsd in an >> appliance. > > Adrian, > > Absolutely, once our FIPS lab approves our implementation. Otherwise, it > may cause more harm than good. That'd be fantastic, thanks! -a ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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 Thu, Jul 02, 2015 at 12:13:54PM -0700, Adrian Chadd wrote: > Could we please get something like this implemented in upstream > FreeBSD? I'm sure a number of vendors would like to see a (not by > default) FIPS-140 random number generator provided. It'd certainly be > a good check list item for people evaluating the use of freebsd in an > appliance. Adrian, Absolutely, once our FIPS lab approves our implementation. Otherwise, it may cause more harm than good. -- Arthur Mesh Juniper Networks +1 408 936-4968 pgpBvL1bWKrEW.pgp Description: PGP signature
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 July 2015 at 11:55, Simon J. Gerraty wrote: > Mark R V Murray 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. > > Same would apply for anyone else doing FIPS 140 evaled products. Could we please get something like this implemented in upstream FreeBSD? I'm sure a number of vendors would like to see a (not by default) FIPS-140 random number generator provided. It'd certainly be a good check list item for people evaluating the use of freebsd in an appliance. Thanks, -a ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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
Mark R V Murray 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. Same would apply for anyone else doing FIPS 140 evaled products. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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 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). We do not need ability to switch adaptors at run-time. Thanks -- Arthur Mesh Juniper Networks +1 408 936-4968 pgpBHpQLIJeWa.pgp Description: PGP signature
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 wrote: > > Mark R V Murray 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-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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
Mark R V Murray 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. > 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... Thanks --sjg ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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 wrote: > > Mark Murray 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-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-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
Mark Murray 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. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
