+-------[ Mark Murray ]----------------------
| > Ok so I've been told this is related to the random module.
| Related, sure, but the real problem is elsewhere.
| > Having had a look through the code I now understand what the problem is.
| > I think that for those people using /dev/sysmouse under X that
| > having random_harvest in scmouse.c is probably ill advised.
| That is a _great_ source of entropy.
So are disk and network accesses, I don't see harvesting code being
sprinkled inside them. Probably because more people would scream if their
network or disk performance died.
| Please explain "ill advised".
Your system will suffer so badly that
a) You will lose serial interrupts when using X
b) You will not be able to use your sound card with acceptable performance
c) If you use an ATAPI cdrom you will get device timeouts;
acd0: READ_BIG command timeout - resetting
ata0: resetting devices .. ata0: mask=01 ostat0=58 ostat2=00
interactive use of -current will be so poor as to be useless.
| > Can we have a flag for syscons to turn this off, or do we just turn off
| > moused and run X with direct access to the mouse? Since it seems you
| > can do this, there wouldn't seem to be harm in having a flag.
| Why? The rest of the kernel has not had the Giant mutex properly
| degraded/removed/unravelled, and this is the real problem.
Well this would indicate that having the current random module is probably
a little premature then. Perhaps we should back it out completely until the
Giant mutices are gone.
| If having the mouse randomness (very approcimately the best randomness
| available) removed is really what you want, then doing a private
| patch in your own sources is probably best.
| Later, when the Giant unravelling progresses, you can remove that.
I'm asking for an non-default flag/option to turn off the harvesting
inside syscons until then. A sysctl would be good.
| > I still need the random module to use ssh (and I used to have it built
| > into my kernel, so I couldn't simply unload it).
| See above. SSH needs good randomness. it is silly to try to break
But if I want that randomness I can't actually use the machine to use ssh.
I don't think turning my machine into a single-purpose graphical entropy
provider is really that acceptable.
As to "good" ;
/* NOTE NOTE NOTE - This is not finished! It will supply numbers, but
* it is not yet cryptographically secure!!
That's your comment isn't it?
If you're only harvesting from the keyboard and mouse then you are
in trouble for headless servers.
Most things that require really strong random numbers are network connected
in some way, so perhaps the harvesting should be focussed more on network
interfaces where it makes more sense, rather than relying on localised
And as mentioned before it seems to be easily circumventable for people
directly talking to their mouse device.
| > It seems a bit of a shame that if you want to use your sound card that
| > you give up X, or you give up ssh.
| If you are function oriented, rather than development oriented,
| why are you useing CURRENT?
Because I don't want to have a -current box for development
and a -stable box as head for it. Running current actually means it gets
tested. Where would you be if noone actually ran it in 'real world' situations.
It just happens that at the moment in the real world it sucks if you want
Look I know you wrote it, and I know you took heat for it. Perhaps
you should back off a bit and have a little objectivity here. I don't want
to get rid of the random module, I want to reduce the impact it has on
my machine when I'm using it interactively, and that's my choice.
Given the number of unanswered emails about hwptr went backwards there's
a lot of people who run current and might also like that choice.
Totally Holistic Enterprises Internet| P:+61 7 3870 0066 | Andrew Milton
The Internet (Aust) Pty Ltd | F:+61 7 3870 4477 |
ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon
PO Box 837 Indooroopilly QLD 4068 |[EMAIL PROTECTED]|
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message