Re: [Patch 0/2] powerpc: avoid userspace poking to legacy ioports
From: Jean Delvare <hidden>
Date: 2008-02-18 20:58:56
Also in:
lkml
On Tue, 19 Feb 2008 07:42:03 +1100, Benjamin Herrenschmidt wrote:
quoted
Maybe Christian's patch can be improved to not do the check on these? As long as /dev/port exists, it seems reasonable that the kernel should behave, no matter what I/O ports are accessed from user-space.nonsense. /dev/mem exists for example, but you are still not supposed to go bang all over the place in it.
You should at least be able to read from it without crashing the machine. Of course writing is a different story.
quoted
quoted
I hate that sensors_detect.. or for that matter any other userland code that pokes random ports like that. It should die.What do you propose as a replacement?Dunno, something less scary, like knowing where your sensors are on a given machine...
You mean, having a complete database for the, what, 4000 PC motherboards out there? And maintaining it day after day? _This_ sounds much scarier to me than the current situation.
honestly, it's just scary the risk you guys are taking by banging random IO ports.
I don't remember anyone reporting problems with this in the past 3 or 4 years, so it doesn't seem to be a big problem in practice.
At the very least, that shouldn't be done on non-x86.
I am surprised that anyone would actually run sensors-detect on non-x86... Non-PC hardware usually doesn't have sensors driven by "hwmon" drivers anyway, or people know what they have and do not need detection. But I would be totally fine with updating sensors-detect to skip some of the probes on non-x86 hardware. There are basically 3 /dev/port probes that are done currently: * Super-I/O chips at 0x2e/0x2f and 0x4e/0x4f. * Legacy PC hardware monitoring chips at 0x290-0x297. * IPMI interface at 0x0ca3 and 0x0cab (read-only). Please tell me which ones should be skipped on PowerPC. Christian, can you tell me which of these probes caused trouble for you?
quoted
And how is userland code poking at random ports different from kernel code poking at random ports? We could move sensors-detect inside the kernel (and I have some plan to do that) but I fail to see how this would solve this particular problem.It wouldn't, but at least I could NAK it or make it CONFIG_X86 :-)
The same could be done for user-space (or at the /dev/port level.) -- Jean Delvare