lkml.org 
[lkml]   [2000]   [Jul]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Direct access to hardware
On Sun, 23 Jul 2000, James Sutherland wrote:

> On Sat, 22 Jul 2000, Miquel van Smoorenburg wrote:
> > According to James Sutherland:
> > > On 21 Jul 2000, Miquel van Smoorenburg wrote:
> > > > It _is_ possible. Check out "capabilities".
> > >
> > > It isn't possible. Root can bypass them all completely, as long as
> > > /dev/kmem etc. exist.
> >
> > If CAP_SYS_RAWIO isn't set, even root cannot open /dev/mem /dev/kmem
> > and /dev/port. Read linux/char/mem.c, check open_port etc
>
> Now, if only that were actually honoured properly by the kernel (it isn't
> yet - this particular piece of kernel does NOT require this cap yet), AND
> it were not present on any process except under very special circumstances
> (i.e. a firmware update tool or similar), we'd be OK.

2-line patch offered up to fix this, which I would *tend* to suspect
would be accepted by Linus, so this can certainly be fixed.

> 2. When a use is found for prodding the hardware directly for this, make
> sure it is NOT done from userspace directly - provide a suitable kernel
> API, with appropriate sanity checks. There is a clear precedent for this;
> look at the CPU microcode updates, for example. The kernel handles this,
> and WILL prevent you from loading the `wrong' update (an earlier version,
> or the wrong CPU's microcode, for example).

Convince drive manufactures and similar to make these updates part
of the SPEC and to conform to it. Otherwise we'd end up w/ junk in the
kernel for every different drive out there to support this, which would be
something of a pain (though I know we do similar for other things).

> We should be able to avoid ANY normal need to bypass the kernel and hit
> the hardware directly for this sort of thing; if you are trying to perform
> a firmware upgrade, do it via /dev/hda-firmware or whatever, NOT by doing
> an end-run around the kernel and giving userspace omnipotence. If I wanted
> a truly unprotected/unrestricted root, I'd be running MS DOS...

The main problem w/ this is convinceing drive manufactures to use
it. The problem is that most of them like the 'security through obscurity'
idea and won't give out the info and would rather do the end-run around any
OS...

Stephen


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

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.152 / U:0.208 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site