Re: Syscons flag to turn off random_harvest in scmouse?
On Mon, 27 Nov 2000, Mark Murray wrote: I wasn't screaming for a backout, I asked for a way to turn off harvesting from the mouse code. You're the one that started in, I just responded in the same condescending manner you used with me. If I was condescending, then I apologise. I am somewhat frustrated, however, at the apparrent (general) lack of understanding that is going into this discussion. If I was to provide a hackaround for everything that I am working to fix, then that is _all_ I'd do, and undoing them afterwards would be a nightmare. I think this whole topic is another piece of evidence for the, "Not everyone should be running -current" case. All of the development plans for yarrow and its ancillary pieces have been discussed ad nauseum, and yet some people still refuse to even come within pissing distance of a clue. If the harvesting bothers you THAT much, submit patches or install 4.2. While I tend to be rather impatient regarding things like broken builds or prolonged instability on -current; things like this that are A) directly related to ongoing development, B) temporary, and C) improving, are part of the price. If it's too much of a price to pay, help fix it (the right way) or run another branch. Doug -- So what I want to know is, where does the RED brick road go? Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Syscons flag to turn off random_harvest in scmouse?
| 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. Those are on their way. | 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. The dev/random inderatction here is a _symptom_ of the problem; any other kernel thread would have a similar problem. But I think we are arguing semantics. | 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. Arguing for this is the same as arguing for removal of any code that is not inside Giant. ie, it makes no sense. As I have said before, I am working on certain tweaks to improve the situation. In the meanwhile, this is CURRENT, please be patient, there are worse problems. (Try "tar xzf VERYBIGFILE.tar.gz" sometime and watch your system hard-hang.) | 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. What's wrong with a private patch? 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. Sounds to me like you need STABLE, not CURRENT. 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? Yes. If you're only harvesting from the keyboard and mouse then you are in trouble for headless servers. Correct. 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 human intervention. Correct. On its way, as I have said may times. 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. Help me then. Patches would be useful. Screaming for backout is not. Understanding SMPng is paramount. 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. There is no direct cause-effect here from the random device to that problem. The reandom device is a busy thread outside Giant. *ANY* thread will do that. There are lots of that kind of thing doing that in the kernel ATM, and they all need to be fixed. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Syscons flag to turn off random_harvest in scmouse?
+---[ Mark Murray ]-- | | 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. | | Those are on their way. Good-o. | In the meanwhile, this is CURRENT, please be patient, there are worse I've been tracking -current for a few years now I know the pros/cons. | | 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. | | What's wrong with a private patch? I made the appropriate patches. I really don't see why you object to having a knob to let people turn it off if its screwing with their systems. When everything's ironed out the knob can go, and you can harvest from wherever 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. | | Help me then. Patches would be useful. Patches are much use if noone else had a use for them or they wouldn't be committed. Since there only seems to be me you and I talking about it it doesn't seem to all that popular an idea anyway. | Screaming for backout is not. I wasn't screaming for a backout, I asked for a way to turn off harvesting from the mouse code. You're the one that started in, I just responded in the same condescending manner you used with me. | 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. | | There is no direct cause-effect here from the random device to that | problem. The reandom device is a busy thread outside Giant. *ANY* thread That is simply not true. Code was inserted into the sycons and pcvt code and that's the code in question. Removal of this code doesn't directly effect the random device either by your argument, in which case you shouldn't have an objection. | will do that. There are lots of that kind of thing doing that in the kernel | ATM, and they all need to be fixed. Yeah but if I move my mouse I want interactivity and responsiveness, if I'm untarring a 200Mb file I'm willing to live with the consequences. These are choices. It's wrong to be able to cripple a machine by moving the mouse, and I think its wrong that code with that large an impact doesn't have the option of being turned off. -- 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
Re: Syscons flag to turn off random_harvest in scmouse?
| Screaming for backout is not. I wasn't screaming for a backout, I asked for a way to turn off harvesting from the mouse code. You're the one that started in, I just responded in the same condescending manner you used with me. If I was condescending, then I apologise. I am somewhat frustrated, however, at the apparrent (general) lack of understanding that is going into this discussion. If I was to provide a hackaround for everything that I am working to fix, then that is _all_ I'd do, and undoing them afterwards would be a nightmare. | There is no direct cause-effect here from the random device to that | problem. The reandom device is a busy thread outside Giant. *ANY* thread That is simply not true. Code was inserted into the sycons and pcvt code and that's the code in question. Removal of this code doesn't directly effect the random device either by your argument, in which case you shouldn't have an objection. Let me rephrase the critical part of that chain; the problem is _any_ busy kernel thread. Today its random, tomorrow who knows. Detangle Giant, it all goes away. Optimise the harvester, it becomes less noticable. This is on its way. | will do that. There are lots of that kind of thing doing that in the kernel | ATM, and they all need to be fixed. Yeah but if I move my mouse I want interactivity and responsiveness, if I'm untarring a 200Mb file I'm willing to live with the consequences. These are choices. It's wrong to be able to cripple a machine by moving the mouse, and I think its wrong that code with that large an impact doesn't have the option of being turned off. Its also wrong to fix problems the wrong way. I'm working on a correct fix, and you have a workaround. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Syscons flag to turn off random_harvest in scmouse?
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. Please explain "ill advised". 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. 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 still need the random module to use ssh (and I used to have it built into my kernel, so I could simply unload it). See above. SSH needs good randomness. it is silly to try to break that. 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? M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Syscons flag to turn off random_harvest in scmouse?
+---[ 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 | that. 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 human intervention. 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 random numbers. 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
Re: Syscons flag to turn off random_harvest in scmouse?
To be fair, if the random module depends that badly on getting entropy from the mouse it isn't much good for many of our users who may not even have a mouse, keyboard or console. (Even when using X, personally I use the mouse as little as possible. On some of our servers the console is rarely used). I tend to agree. Moused is an optional component in FreeBSD, thus, we cannot expect that it is always running. It may be a good source of randomness, but the random module cannot and should not depend on it so heavily. Kazu I think the yarrow stuff is probably somewhat more roubust than requiring the mouse - as long as there is some source of entropy. What other sources does the random device currently use? David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Syscons flag to turn off random_harvest in scmouse?
I think the yarrow stuff is probably somewhat more roubust than requiring the mouse - as long as there is some source of entropy. What other sources does the random device currently use? Currently - keyboard and mouse. RSN, also interrupts and network activity. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
