svn commit: r239569 - head/etc/rc.d

[Bjoern A. Zeeb]

On Thu, 13 Sep 2012, Bjoern A. Zeeb wrote:

Hi,

I have removed freebsd-rc for this part of the discussion as it's
unrelated.


Ok, this is an aweful lot of individual parts and my feeling is that
we want to go through them very focused.  Some of them have been
discussed enough already with good solutions but then found to depend
on other things later.  Some questions are clearly for "future
research and not to be answered any time soon".

The one I'd like to start with is the Problem of "over-seeding", as in
that we are currently dropping possible entropy.  The reason to start
with that is: what and how we'll feed things in will depend on how we
solve this problem.

So far (wherever) I have heard multiple solutions and added some
(unreasonable ones?) upfront to tick them off.  I left my personal
comments already.  A simple "no" or "usable" can help; deleting all
unreasonable options and "ACK" on OK ones can help.  If i am entirely
wrong, let me know in private.

1) continue to over-[fs]eed as we always did
    (seems out of question, no improvement)

2) compress (as in gzip) the input of better_than_nothing
    (multiple people objected, no literature, questionable outcome,
    speed, still not great control over how much data we seed)

3) hash (arch dependent?) the entire input of better_than_nothing
    in the shell script
    (at least a good idea on how much data we seed)

4) hash (arch dependent?) individual parts of better_than_nothing
    in the shell script
    (seed more and still know how much data we'd seed)

5) send all data to the kernel but XORing the data together on overflow
    in the kernel
    (can control when buffer full and only then take action when
    needed, indepedent on how seed data is chosen, withdrawn)

6) send all data to the kernel but XORing the data + counter value
    together on overflow in the kernel
    (can control when buffer full and only then take action when
    needed, indepedent on how seed data is chosen, but why XOR?)

7) send all data to the kernel and hash (arch dependent?) it + counter value
    into the buffer on overflow, as in b[n] = H(b[n] + c + i[n]) in the kernel
    (can control when buffer full and only then take action when
    needed, indepedent on how seed data is chosen, uses standard
    technology)

8) ?


Things to consider: overall time this takes?
Things to consider: how often this needs to be done?
Things to consider: how to consume the most entropy?
Things to consider: can it be done arch specific if needed?
Things to consider: would there be a challenging problem implementing this?
...

Things I really love not to hear in this step:
- discussions on how much seed data/entropy we send
- discussions on which seed data/entropy we send
- discussions on the order of seed data/entropy we send
- ...

Thanks,
/bz

-- 
Bjoern A. Zeeb                                 You have to have visions!
          Stop bit received. Insert coin for new address family.