Re: What's wrong with IDE patch and what proper solution should be...

From: Meelis Roos (mroos@linux.ee)
Date: Sun Jul 23 2000 - 13:32:43 EST


PBD> Right now, you can write (for example) an Iomega Jaz utility without
PBD> any kernel futzing at all. Contrast this with Windows where it seems
PBD> necessary to always install a new driver.

What IS the solution?

If the drivers can be done in the userspace then the damage can be done in
the userspace (assuming the hardware can be damaged).

I assume that root-level userspace comprimise is possible (statistics show that
it happens too often to ignore it - like it or not). So the kernel should
protect all hardware form being damaged.

We can restrict these ioctls and direct access to i/o ports with capabilities.

OTOH:

* We want to use some mapped memory & ports (xfree)
  Solution exists as a memory and port range enabler
  So the side channel (doing direct io) can be closed for unnecessary
  access.

* We want to use raw ide & scsi & etc commands. This is a problem.
  Is a general safe filter even possible (such that cd writing, zip dives
  etc continue to work)? I assume this is not possible.

So the only 'bulletproof' way is to do all hardare access in kernel and not
provide userspace _any_ methods for doing it directly. This means all zip
drivers & graphics drivers & so on in the kernel :-(

Therefore:

_IF_ the hardware can be damaged THEN no userspace application must be able to
access it directly and to use such devices, a kernel level driver must exist to
provide all the access safely.

Or am I missing something?

-- 
Meelis Roos (mroos@linux.ee)

- 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/



This archive was generated by hypermail 2b29 : Sun Jul 23 2000 - 21:00:20 EST