Sean Kelly wrote:
Many peripheral hardware device do not like having their registers blindly read (it's quite common for a read operation on a register to signal an ASIC that it's ok to do a certain action) and will respond with nasty things like interrupt storms, endless PCI target aborts, etc. Whether this is silly or not is not the point; this is just one of the many places in Unix that have no seatbelts and assume that the superuser knows what he is doing.On Thu, Dec 19, 2002 at 11:35:01PM -0800, Nate Lawson wrote:>On Fri, 20 Dec 2002, Sean Kelly wrote: > >>On my 5.0-CURRENT kernel built 45 minutes ago, I can bring my system to its >>knees by doing >> >># cat /dev/io >> >>While I understand that this isn't exactly something one would normally be >>doing, is it really something that should bring the system down? > >You're running as root. So does "yes > /dev/da0" and "cat /dev/urandom > >/dev/mem" and ... (infinity) While I don't really care to test it, I wager that `yes >/dev/da0` will not cause the system to lock hard. But you seem to be talking abot something very different. You are talking about WRITING. I am talking about READING. # cat /dev/da0 # cat /dev/urandom None of these bring the system to its knees. So why does # cat /dev/io totally lock my system solid? According to the manpage: The special file /dev/io is a controlled security hole that allows a pro- cess to gain I/O privileges (which are normally reserved for kernel- internal code). Any process that holds a file descriptor on /dev/io open will get its IOPL bits in the flag register set, thus allowing it to per- form direct I/O operations. This says nothing about what happens if you attempt to read() from /dev/io, as `cat /dev/io` would be expected to do. At the least, there should be a big, fat, blinking WARNING on the manpage telling you that `cat /dev/io` will bring your system down.
Scott
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
