Date: Tue, 11 Sep 2012 02:38:15 -0700 From: Doug Barton <dougb@FreeBSD.org> To: obrien@freebsd.org Cc: Arthur Mesh <arthurmesh@gmail.com>, freebsd-rc@freebsd.org, Xin Li <delphij@delphij.net>, freebsd-security@freebsd.org, RW <rwmaillists@googlemail.com>, Mark Murray <markm@freebsd.org> Subject: Re: svn commit: r239569 - head/etc/rc.d Message-ID: <504F0687.7020309@FreeBSD.org> In-Reply-To: <20120911082309.GD72584@dragon.NUXI.org> References: <50453686.9090100@FreeBSD.org> <20120904220754.GA3643@server.rulingia.com> <20120906174247.GB13179@dragon.NUXI.org> <20120906230157.5307a21f@gumby.homeunix.com> <20120906224703.GD89120@x96.org> <20120907015157.GA29497@server.rulingia.com> <20120910135218.GA68128@dragon.NUXI.org> <504E343A.4020802@FreeBSD.org> <20120911064636.GB72584@dragon.NUXI.org> <504EE446.6060500@FreeBSD.org> <20120911082309.GD72584@dragon.NUXI.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 09/11/2012 01:23 AM, David O'Brien wrote:
>> On 09/10/2012 23:46, David O'Brien wrote:
>>> In what way did I suggest we don't need to seed the PRNG?
>>> I simply removed an outdated and incorrect statement.
>>
>> Yes, the comment as it stood was out of date. I'm not sure that removing
>> it (rather than rephrasing it) was the right call.
>
> Doug you're a FreeBSD committer, you know how to use an editor and
> 'svn diff'. Where is your patch suggesting a rephrase?
David, being rude isn't really helping at this point. If I wasn't
spending all of my FreeBSD time responding to the same stuff from you
and Arthur over and over again, I'd have more time to produce the
patches I've already suggested. As it is, you'll just have to wait.
Meanwhile, I've asked you to hold off on committing more changes (twice
now publicly, once in private), so please do that.
>>> In fact writing into /dev/random CANNOT "seeded" yarrow. All /dev/random
>>> input is untrusted and is assumed to have _0_ entropy:
>>>
>>> void
>>> random_yarrow_write(void *buf, int count)
>>> {
>>> ...
>>> random_harvest_internal(get_cyclecount(), (char *)buf + i,
>>> chunk, 0, 0, RANDOM_WRITE);
>>
>> You're taking that out of context. The 0 there is just an estimate, but
>> it's added to the tailq anyway.
>
> Yes the input written to /dev/random is put into the generator
> (provided you have the seed buffer space).
>
> The "0, 0" is the 'bits' and 'frac' argument to
> random_harvest_internal(), which become 'event->bits' and 'event->frac'.
> Follow the code from there and point out how I am wrong.
>
> What overrides the estimate then?
Better question, what is the estimate actually used for?
> This is discussed in the yarrow paper.
> Have you read it yet?
Yes, when I implemented the rc.d stuff in the first place, and again
recently.
>>> So we have two issues -- (1) is how yarrow is operating per the design
>>> with its checks on "seeded",
>>
>> I am specifically avoiding that issue as it is out of scope for the
>> rc.d-related discussion. There is room for a larger discussion on
>> whether or not we should make .seeded dynamic again.
>>
>> But regardless of that decision, it's unquestionable that we need to
>> seed the device at boot time, which is what I am interested in.
>
> Unquestionable in what regard? Unquestionable in that we must do so to
> get any useful output of /dev/random.
Yes, as I have said repeatedly.
> Unquestionable in that FreeBSD will not boot? As I mentioned, I tested
> that. The system booted up fine with no delays, etc... Scary.
Again, the issue of whether .seeded should be made dynamic again is out
of scope for this conversation.
>> ... and something that I pointed out that with the current defaults is
>> close enough to impossible not to be a threat model we need to spend
>> much time on.
>
> Oh? You've done sufficient research? You've gathered 100,000 keys from
> random FreeBSD machines from across the Internet? I am aware of research
> that has.
references?
> I'm not saying FreeBSD was a red hearing as Debian was; but
> you seem to be quickly dismissing something you seem to have spent little
> time investigating or thinking about.
Again, being rude isn't helpful. I've actually spent a lot of time
thinking about these issues, both at the time I wrote the code, and
recently.
>>> Also, both jbh <201209050944.38042.jhb@freebsd.org> and RW
>>> <20120905021248.5a17ace9@gumby.homeunix.com> feel this likely does
>>> happen just from reading the code. Please explain from either
>>> (1) a code reading, or (2) your own instrumented kernel that dropping
>>> of input to /dev/random does not occur.
>>
>> Once again, you're the one asserting that there is a problem with a
>> system that has worked well for 12 years, so the burden of proof is on
>> you. That said, I'm interested in Arthur's evidence.
>
> Are you not a sufficient C programmer that you couldn't hack this up
> yourself with the amount of time you've spent arguing it?
Seriously. Stop being such an ass.
I've said lots of times now that my FreeBSD time is limited, and THE
BURDEN OF PROOF IS ON YOU. If you think it's easy, whip it up. If you're
right, the truth will benefit all of us.
>>>> The use of dd to feed the entropy in with 2k chunks is specifically to
>>>> address this issue.
>>>
>>> Maybe I'm missing something... The code in 'initrandom' is
>>> "| dd of=/dev/random bs=8k". Where are you getting 2k chunks from that?
>>
>> You're right, I didn't have a chance to look over the code when I wrote
>> that response, and was going by my (obviously faulty) memory on that
>> trivial point.
>
> This seems to be one of your problems -- you don't seem to be reading any
> code or papers before replying.
Again, rudeness for no good reason. I've spent more time than I should
have had to on this already, including reading and re-reading the
material that you've provided.
>> My understanding is that Arthur's tests were with the
>> current defaults. It would be interesting to see what happens if we
>> reduce that to 4k (to match the input buffer size),
>
> What do you think is the size of ${entropy_file}?
There are more things being pumped into the device with dd than just
that 1 file. And users can change the size of the file in
/var/db/entropy from the defaults as well.
>> or perhaps even lower.
>
> Just how much do you expect the write(2) to be slowed down by breaking up
> the 4k write into 2 or 3 chunks?
I don't know, that's why we test things.
But as I said, that's just one of many possible changes we could make to
address the concern about dropping input. I can't speak intelligently
about what other changes would be useful until I've seen the data that
shows what we're dropping now.
Doug
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?504F0687.7020309>