Date: Fri, 20 Dec 2002 03:48:12 -0700 From: Scott Long <scott_long@btc.adaptec.com> To: Sean Kelly <smkelly@zombie.org> Cc: Nate Lawson <nate@root.org>, current@freebsd.org Subject: Re: `cat /dev/io` leads to system lockup. Message-ID: <3E02F56C.7080002@btc.adaptec.com> In-Reply-To: <20021220081215.GA35355@edgemaster.zombie.org> References: <20021220081215.GA35355@edgemaster.zombie.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Sean Kelly wrote: > 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. > 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. Scott To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E02F56C.7080002>