Messages in this thread |  | | | Date | Sun, 23 Jul 2000 09:45:35 +0100 (BST) | | From | James Sutherland <> | | Subject | Re: Direct access to hardware |
| |
On 22 Jul 2000, Linus Torvalds wrote:
> In article <Pine.LNX.4.10.10007221822320.5862-100000@dax.joh.cam.ac.uk>, > James Sutherland <jas88@cam.ac.uk> wrote: > > > >So much for the "root is god" claims made earlier, then. What about iopl() > >and the like? IF capabilities can be used to block this (and similar), and > >Andre's "sanity checking" for ATA is added, then surely it *IS* possible > >to prevent root screwing the HDD (without replacing the kernel, at which > >point all bets are off, of course). > > What's the point? > > If the system is secure, then adding sanity checking to the ATA code > makes no difference: nobody gets to do anything improper anyway.
That assumes an infallible root, which is a bit optimistic. What reason is there NOT to have sanity checking, other than some people liking the thrill of Russian roulette with their hardware?
I know enough about electricity not to prod the live wire in my mains supply. Does this mean I should leave the cover off my fusebox? After all, my house is secure, so nobody gets to do anything improper there...
> If the system is not secure, then adding sanity checking to the ATA code > makes no difference: people who could use the ATA thing can use other > things that are much more insidious.
The "security" aspect of this is largely a red herring, I suspect; at best, fixing this will make a malicious root marginally less damaging. The real issue is just that the kernel is accepting unvalidated parameters from userspace, and shooting itself in the foot with them. MS took a fair bit of flak, IIRC, for doing this with WIN32K.SYS in NT4. Do we now expect higher standards of design from NT than Linux? :-)
> The mechanism that everybody wants is _already_ there. It's called > "permissions". No new driver code necessary. > > If those permissions do not work, then they don't work, and adding > last-minute band-aids makes no difference. > > Just as a comparison, look at Windows.
No thanks - I've just eaten :-)
Seriously, in the NT case at least, the kernel is expected to validate the parameters it is passed from userland. It doesn't matter what user or capability set the process has - it can still only pass valid parameters. Where a parameter is being accepted unchecked, the code in question is regarded as a bug, and fixed as such.
> It takes the opposite approach: it has no real seurity, but a LOT of > band-aids to avoid the "obvious" holes. Leaving it wide open.
This isn't a security issue, really, just a "this is a dangerous implementation" issue. As a longer term aim, I'd like to see this sort of loophole for hardware manufacturers to bypass the kernel closed off, too - I don't want to see a load of vendor-specific binaries screwing with the hardware completely outside the kernel's control.
Other things like CPU microcode updates have sanity checking - why not do the same here? HDD firmware upgrades can hardly be performance critical, after all!
James.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
|  |