[lkml]   [2000]   [Jul]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Direct access to hardware
    On Sun, 23 Jul 2000, Vojtech Pavlik wrote:

    > > 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...
    > Actually, the situation is more like that you have a covered fusebox in
    > your house, but you don't have a lock on it. Yes, you can unscrew the
    > cover and get yourself screwed (write a program that uses the ioctl and
    > kills the drive), and no lock is protecting you from fiddling with the
    > wires, but you can't get killed by just simply touching the thing when
    > walking through your house in the dark.
    > This amount of protection (I don't say security, this can't ever be
    > secure) seems to be fine for most households.
    > Normal programs won't ever have the chance to do anything bad using the
    > ioctl. They don't use it. They don't even have /dev/hda open.
    > By the way, the ioctl exists since 2.0 days, very likely since 1.0 even.
    > Has *anyone* killed their drive by accident this way?
    > Seems like the current protection against accidental damage is ok.
    > Against intentional damage only disabling all raw io access can help.

    Which should really be done anyway wherever possible. Possibly make an
    exception for graphics - give the X server and co "direct" access to the
    graphics card only.

    > > 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.
    > The kernel validates the parameters. The inode, the ioctl number, the
    > pointer to the structure, and then passes the data to the drive. It
    > doesn't validate the data. It cannot reliably - either it'll filter too
    > much or too little, but never get it right with not all of the commands
    > being known.

    It shouldn't allow these blocks of unvalidated data through at all, then -
    that's too dangerous. If the kernel doesn't know what's going on, HTF is
    it supposed to enforce any kind of security or other system policy??

    > > 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.
    > This is a good point. But in that case, the right solution would be just
    > to simply remove this raw hd io ioctl and replace it with hardware
    > abstracted (best independent on IDE/ATAPI) get/set info/options and
    > read/write firmware commands to the kernel via some interface, be it
    > another ioctl or /proc tree or /dev node.

    That's exactly what I wanted all along: remove the "do something
    arbitrary, and no I won't tell you [the kernel] what it is" function, and
    replace it with "update HDD firmware", "change PIO mode", etc.

    > That'd be ok. That's hardware abstraction. That's what a kernel is
    > supposed to do. But not filtering data provided by userland, that's
    > policy and doesn't belong to the kernel. The difference is subtle, but
    > still is there.

    It's not filtering; IDE commands shouldn't originate in userland to begin
    with. Userland apps should make a request to the kernel for a specific
    kernel facility; the kernel then implements this by sending IDE commands
    as needed.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:57    [W:0.037 / U:74.344 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site