[bug #15295] Mach lets processes write to I/O ports

[Samuel Thibault]

Follow-up Comment #3, bug #15295 (project hurd):

Well, actually, gnumach2 does indeed set i/o port permissions on tasks rather
than on threads.  I have a small working patch for making gnumach1 behave that
way too.

But what about the interface?

- gnumach1 provides i386_io_port_add(thread, dev) which adds device-defined
ports to allowed ones: for instance, device "kd" has video registers (I'd add
speaker ports though, since they are used too) ; device "iopl" has a bunch of
registers: speaker, game port, sound, printer, video, and gives read-only
access to any i/o port.
- gnumach2 provides i386_io_perm_create(master, from, to, &new_io_perm) for
creating an "i/o range" and i386_io_perm_modify(task, io_perm, enable) for
enabling/disabling access to the range.
- glibc usually provides a mere ioperm(base, count, enable) that just
sets/clears bits, but how to implement that easily with the two interfaces
above?

As far as the Hurd is concerned, only the console needs i/o ports: vga &
speaker access.  Using either of the 3 interfaces above is fine ; currently,
ioperm() is used (and ENOSYS is ignored for the gnumach1 case).  I have a
small patch for making it use the gnumach1 interface.

On the other hand, XFree86 and Xorg actually need hardly any port access:
they have to poke pci config, pci video registers, etc ; the hook there is
hence just "enable full I/O access".  For this, the current gnumach1
i386_io_port_add() implementation isn't suited: it would require defining a
65537-sized array of every numbers between 0 and 65535...  While the gnumach2
and ioperm() interfaces would be fine.


So, what should we do?  Gnumach1 was left with an i/o security issue opened
for years now.  It wasn't very serious so far, but there are now hurd boxes
on the Internet which really deserve fixing that issue on the short term. 
Here are some possibilities:

- I already have small working patches for making gnumach1 i/o protected,
letting the gnumach1 interface as is, and making the Hurd console use it for
port access.  This would be just fine for these text-only hurd boxes. 
XFree86/Xorg will work with ISA video boards (I have small working patches),
but not with PCI devices (needs full I/O access).  This is hence sufficient
for X to work in qemu -isa.
- Same as above, plus we define an "all I/O ports" gnumach1 device, either
with an ugly-but-interface-compliant 65537 array, with a special value, or
with some evil bypass hack.  X on PCI devices would then become possible.  I
still don't know how to easily implement glibc's ioperm().
- We backport the gnumach2 interface to gnumach1.  It shouldn't be hard, but
the patch would get quite bigger.  Same remarks as just above.
- We define yet another interface, having in mind the future L4/Hurd port.

Gnumach1's interface is interesting in that it could, in a way, arbitrate i/o
port access between tasks.  It could be difficult to really achieve perfect
separation, though.  Gnumach2's design looks much like glibc's raw ioperm(),
with some sexy "enable/disable this io_perm" shortcut.

I'm not sure whether fancy design makes sense here.  Note that current
implementations in gnumach 1 and 2 have a bug: if a task asks for i/o access
to speaker+video (represented by some port A), asks i/o access to video (port
B), and then drops its i/o access to speaker+video (port A), access to video
(port B) doesn't work! (because the i/o bitmap is blindly modified when
dropping port A)  This would happen with glibc's ioperm() semantic too, but
the application programmer is aware of that.  This example shows how fancy
design is tricky to implement, and I'm not sure whether we really want to
implement that in the gnumach kernel.  Actual i/o port use is generally quite
trivial, and if programmers really want fancy i/o bitmaps handling, they can
implement it themselves in their application with the only help of a raw
ioperm()-like call.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?func=detailitem&item_id=15295>

_______________________________________________
  Message posté via/par Savannah
  http://savannah.gnu.org/