bugThe GNU Hurd - Bugs: bug #15295, Mach lets processes write to I/O...

 
 

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

Submitter:  Samuel Thibault <sthibaul>
Submitted:  Mon 26 Dec 2005 09:23:52 PM UTC
   
 
Category:  GNU Mach Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Hardware Support
Status:  Fixed Privacy:  Public
Assigned to:  tschwinge Originator Name: 
Open/Closed:  Closed Reproducibility:  Every Time
Size (loc):  None Planned Release:  GNU Mach 1.4
Effort:  0.00
Wiki-like text discussion box: 


* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 07 May 2007 10:11:49 PM UTC, comment #14: 

I just installed the following to fix this issue; using a different way then it was first suggested here.


#v+
2007-05-07  Thomas Schwinge  <tschwinge@gnu.org>

--- ``Mach lets processes write to I/O ports''

  • i386/Makefrag.am (libkernel_a_SOURCES): Add `i386/i386/io_perm.c',

`i386/i386/io_perm.h', `i386/i386/machine_task.c', `i386/i386/task.h'
and remove `i386/i386/io_port.h', `i386/i386/iopb.c',
`i386/i386/iopb.h'.

  • i386/i386/io_port.h: Remove file.
  • i386/i386at/kd.c: Don't include <i386/io_port.h>.

(vga_port_list, kd_io_device, kd_io_map_open, kd_io_map_close): Don't
define and don't use anymore.

  • include/stddef.h: New file.


  • i386/i386/io_perm.c: Include <string.h>, <device/device_emul.h>,

<ipc/ipc_space.h> and don't include <oskit/ds_oskit.h>.
(io_perm_device_emulation_ops): New variable.
(dev_open_alloc, setup_no_senders): Remove declarations.
(convert_io_perm_to_port, convert_port_to_io_perm, io_perm_deallocate):
Rewrite.
(no_senders): New function.
(i386_io_perm_create, i386_io_perm_modify): Rewrite partially, to adapt
to the GNU Mach environment.

  • i386/i386/io_perm.h: Include <device/dev_hdr.h> and

<ipc/ipc_types.h>.
(io_perm, io_perm_t): New structure and accompanying type definition.
(IO_PERM_NULL): Define.

  • i386/i386/locore.S (ktss): Move variable to...
  • i386/i386/ktss.c: ... here, make it a ``struct task_tss''.

(ktss_init): Initialize the `task_tss' structure and the i/o permission
bit map.

  • i386/i386/ktss.h: Adapt to that.
  • i386/i386/machine_task.c (machine_task_module_init): Adapt the `zinit'

call to the GNU Mach environment.

  • i386/i386/mp_desc.c: Include <machine/ktss.h>.
  • i386/i386/tss.h: Include <machine/io_perm.h>.

(task_tss): New structure, equivalent to the OSKit-Mach one.

  • i386/include/mach/i386/mach_i386.defs: Don't include

<device/device_types.defs>.
(device_list_t): Remove type.

  • i386/include/mach/i386/mach_i386_types.h (device_list_t): Remove type

definition.

2007-05-07  Marcus Brinkmann  <marcus@gnu.org>

--- ``Mach lets processes write to I/O ports''

  • i386/i386/iopb.h, i386/i386/iopb.c: Obsolete files removed.


  • i386/i386/pcb.c (switch_context): Update the I/O permission

bitmap from stack_handoff() here (not only in stack_handoff()).

  • i386/i386/machine_task.c (machine_task_module_init): Set

ZONE_COLLECTABLE and ZONE_EXHAUSTIBLE flags for the iopb zone.
Requested by Roland McGrath <roland@frob.com>.

  • i386/i386/io_perm.h: New file.
  • i386/i386/io_perm.c: New file.
  • i386/i386/machine_task.c: New file.
  • i386/i386/mp_desc.h: (struct mp_desc_table): Change type of ktss to

struct task_tss.
(mp_ktss): Likewise for array of pointers to the struct.

  • i386/i386/mp_desc.c: Include `machine/tss.h' and `machine/io_perm.h'.

(mp_ktss): Change type to array of struct task_tss.
(mp_desc_init): Cast pointer to x86_tss into pointer to task_tss,
and use size of struct task_tss instead size of struct x86_tss.
Initialize the task_tss structure.

  • i386/i386/pcb.c: Include `stddef.h' and `machine/tss.h'.

(iopb_create, iopb_destroy): Prototypes removed.
(curr_ktss): Cast pointer to base_tss to pointer to struct
task_tss.
(switch_ktss): Always use kernel TSS.
(update_ktss_iopb): New function.
(stack_handoff): Call update_ktss_iopb.
(pcb_module_init): Do not call iopb_init.
(pcb_terminate): Do not call iopb_destroy.
(thread_setstatus): Remove local variable tss.
(thread_getstatus): Rewrite i386_ISA_PORT_MAP_STATE case handler.

  • i386/i386/task.h: New file.
  • i386/i386/thread.h: Do not include `i386/iopb.h'.

(struct i386_machine_state): Remove member io_tss.

  • i386/include/mach/i386/mach_i386.defs [KERNEL_SERVER]: Include

`machine/io_perm.h'.  Define intran, outtran and destructor.
(io_port_t): New type.
(io_perm_t): Likewise.
(i386_io_port_add): Interface removed.
(i386_io_port_remove): Likewise.
(i386_io_port_list): Likewise.
(i386_io_perm_create): New interface.
(i386_io_perm_modify): Likewise.

  • i386/include/mach/i386/mach_i386_types.h [MACH_KERNEL]: Include

`i386/io_perm.h'.
[!MACH_KERNEL]: Define types io_port_t and io_perm_t.

  • kern/task.c (task_init): Call machine_task_module_init.

(task_create): Call machine_task_init.
(task_deallocate): Call machine_task_terminate.
(task_collect_scan): Call machine_task_collect.

  • task.h: Include `machine/task.h'.

(struct task): Add member machine.
#v-


Thanks to everyone who helped!


Now, please test this.  The first thing you'll notice is that X.org, the Hurd console and pciutils will no longer work.  They need to be adapted.

After new GNU Mach packages are in place, glibc needs to be rebuilt so that it'll offer the `ioperm' function.

Thomas Schwinge <tschwinge>
Group administrator
Sat 14 Jan 2006 01:23:45 AM UTC, comment #13: 

So, to sum it up, the patchset includes

- file #5766 of patch #4737 - patch-gnumach-1-user_tss
- file #3270 - patch-gnumach-2-default_noio
- file #3271 - patch-gnumach-3-device_port_fix
- file #3272 - patch-gnumach-4-more_ports
- file #3273 - patch-gnumach-5-io_per_task
- file #3274 - patch-gnumach-6-io_device
- file #3275 - patch-hurd-ioperms

plus file #3255 - patch-xorg-hurd-ioperms-all against Xorg.

Samuel Thibault <sthibaul>
Group administrator
Sat 14 Jan 2006 01:04:32 AM UTC, comment #12: 

Here is an update of the console-client fix for io port access.

Anonymous
Sat 14 Jan 2006 01:03:14 AM UTC, comment #11: 

Here is an update of the patch that adds an "io" device which represents all io ports.

Anonymous
Sat 14 Jan 2006 01:01:48 AM UTC, comment #10: 

Here is an update of the patch that makes io permission per task.

Anonymous
Sat 14 Jan 2006 12:59:40 AM UTC, comment #9: 

Here is an update of the patch that adds a few necessary ports (timer and speaker)

Anonymous
Sat 14 Jan 2006 12:58:04 AM UTC, comment #8: 

Here is an update of the i386_io_port_add/remove() parameter fix.

Anonymous
Sat 14 Jan 2006 12:56:40 AM UTC, comment #7: 

Here is an update of the patch that set default IO permissions to none.

Anonymous
Fri 06 Jan 2006 11:43:50 PM UTC, comment #6: 

Oops, I forgot to login on savannah before submitting the two previous files.

The patchset should now be complete for gnumach1 to be io-protected without sacrificing the Hurd console and xfree86/xorg. Other programs would probably want an implementation of ioperm()/iopl(), but I'd say it is for later work, either with gnumach2 (for which an implementation is available), with a redesign of gnumach1, or with L4/whatever.

Samuel Thibault <sthibaul>
Group administrator
Fri 06 Jan 2006 11:34:24 PM UTC, comment #5: 

Hi,

Here is a patch that adds an "io" device representing all IO ports. It uses a special value so as to avoid an ugly 65537 array. X on PCI devices now becomes possible.

Anonymous
Mon 02 Jan 2006 10:42:58 PM UTC, comment #4: 

Note: patch-gnumach-5-io_per_task replaces patch #4740.

Samuel Thibault <sthibaul>
Group administrator
Sat 31 Dec 2005 10:48:18 AM UTC, comment #3: 

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.

Samuel Thibault <sthibaul>
Group administrator
Wed 28 Dec 2005 03:36:35 PM UTC, comment #2: 

Trying to apply patch #3216 , patch #3219 , and patch #4737 does work as expected for single-threaded programs like ioport/ioport2/ioport3.  I patched my Hurd console to use i386_io_port_add, it now works.

However, some illegal instructions still happen because for now, gnumach's io permissions are thread-specific, so that only the thread that called i386_io_port_all has i/o access.  I guess this will be a problem for almost every program: people usually expect i/o permissions to be for the whole task, not for a single thread.  Some libraries will even create threads and call some callbacks within them, and these callbacks could potentially need i/o permissions (this is what happens with the Hurd console).

So I'd say we should turn gnumach to handle io permissions per task.  This doesn't pose any technical problem, since until now every task/thread was using the kernel tss ; it's just a matter of storing the tss per task, not per thread.

Samuel Thibault <sthibaul>
Group administrator
Mon 26 Dec 2005 09:52:01 PM UTC, comment #1: 

Note that this depends on patch #4737 for proper user TSS functionning.

Marcus' proposed file #3216 does fix the issue indeed.  But of course then neither the console nor Xorg work any more (illegal instruction), and i386_io_port_add() still fails.  A simple solution for now could be to open the iopl device, which gives access to a collection of allowed ports (see gnumach/i386/i386at/iopl.c).

Samuel Thibault <sthibaul>
Group administrator
Mon 26 Dec 2005 09:23:52 PM UTC, original submission:  

Message received at -email is unavailable- (full text, mbox):

From: Kalle Olavi Niemitalo <tosi@ees2.oulu.fi>
To: -email is unavailable-
Subject: Mach lets processes write to I/O ports
Date: 05 Oct 1999 21:14:38 +0300

Package: gnumach
Version: 1:1.2-1.kn.1
Severity: normal

(The version was 1:1.2-1 before I applied my Alt Gr patch and
disabled almost all devices.)

Roland McGrath <roland@frob.com> writes:

> > I then
> > removed the call, but the program could still write to the ports.
> > So maybe it's automatic after all.
>
> Hmm, it shouldn't be.  It would be good if someone could look into this
> (maybe you can get a test case together and file a BTS report?), but I'm
> not going to worry about it for now.


So, here is the report.

The following program should not work.  Mach shouldn't let
processes read or write I/O ports unless they have explicitly
asked for permission.  But the program works.  Worse, it doesn't
even require root privileges.

see ../util.h and ioport.c


Message received at -email is unavailable- (full text, mbox):

From: Kalle Olavi Niemitalo <kon@iki.fi>
To: -email is unavailable-
Subject: Re: Mach lets processes write to I/O ports
Date: 03 May 2001 11:53:41 +0300

tags 46709 security
severity 46709 critical
quit

Letting processes write to EGA ports isn't that awful (with
today's sync-protected monitors), but if Mach also lets them
write to ports used by IDE or SCSI, then it "introduces a
security hole on systems where you install the package."

No, I didn't really test whether Mach allows that -- I don't know
enough about IDE to do that in a way that won't hurt my data.
However, I think it's very likely.  Please show I'm mistaken.

This would be a local attack, but might not require any UIDs.



Message received at -email is unavailable- (full text, mbox):

From: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>
To: Kalle Olavi Niemitalo <kon@iki.fi>, -email is unavailable-
Subject: Re: Bug #46709: Mach lets processes write to I/O ports
Date: Sun, 7 Oct 2001 05:19:28 +0200

[Message part 1 (text/plain, inline)]

On Thu, May 03, 2001 at 11:53:41AM +0300, Kalle Olavi Niemitalo wrote:

> Letting processes write to EGA ports isn't that awful (with
> today's sync-protected monitors), but if Mach also lets them
> write to ports used by IDE or SCSI, then it "introduces a
> security hole on systems where you install the package."


I have found the bugs that allow users to write to I/O ports without
requesting permission.  In i386/i386/ktss.c, only the last byte of the
io map of the KERNEL_TSS is set to 0xff (access forbidden), all other
are left as they are (all zeros? random? I don't know, but suspect all
zero).  Threads that don't have their own TSS use the KERNEL_TSS, and
this means all threads by default (see pcb.c).  BTW, I am pretty sure there
is an off by one error, which means that the code writes into the byte past
the bitmap, rather than the last byte of it (I verified that the bitmap
indeed starts at ktss, and that means that ktss + 0x10000/8 is off by one).

This is the first bug.  The second bug is that the i386_io_port_add function
that creates the user tss initializes it with access_all being true, which
means that it is initialized to all zero.  So a thread requesting any access
will always get all (I suspect).  The two places marked with /* XXX */ in
the iopb.c file seem to indicate that this is first a correct interpretation
of the code and that the author knew that this had to be fixed.  Replacing the
TRUE at the XXX with FALSE, and setting all bytes in the map to 0xff in the
KERNEL_TSS should fix this, but I did not test that part.

The reason I could not continue testing the user tss is that
the i386_io_port_add call can't find the device -> io_port mapping.  I tried
both the kd and iopl device, and neither worked.  This requires more
debugging (maybe tomorrow).  We decided by now that this is the wrong approach
anyway, and that all this code is doomed to be replaced by a somewhat
different approach.  However, I think it is not a bad idea to fix this,
especially as it doesn't seem to hard, before going on and messing with it
(well, at least for me as I have to learn more details about the tss stuff
first before I can have a go at the new interface).

I am including my preliminary patch and my two test programs (incomplete,
just for reference) that show the i386_io_port_add problem.  The test
program you submitted fails with Illegal Instruction if you apply my patch.

BTW, I noticed that there are reminiscences of io map support in
thread_setstatus and thread_getstatus, with a reference to a i386_io_port_map
call that seems to be intended to set/get a complete bitmask.  This cruft can
be cleaned up when we have a go at the new interface.

Thanks,
Marcus

See patch1, ioport2.c and ioport3.c

Message received at -email is unavailable- (full text, mbox):

From: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>
To: Kalle Olavi Niemitalo <kon@iki.fi>, -email is unavailable-
Subject: Re: Bug #46709: Mach lets processes write to I/O ports
Date: Sun, 7 Oct 2001 15:20:11 +0200

On Sun, Oct 07, 2001 at 05:19:28AM +0200, Marcus Brinkmann wrote:

> The reason I could not continue testing the user tss is that
> the i386_io_port_add call can't find the device -> io_port mapping.


It turns out that the mach_device_t address registered with io_port_create
doesn't match the mach_device_t address used to lookup the device again.
I don't know why (yet).

Thanks,
Marcus

Message received at -email is unavailable- (full text, mbox):

From: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>
To: Kalle Olavi Niemitalo <kon@iki.fi>, -email is unavailable-
Subject: Re: Bug #46709: Mach lets processes write to I/O ports
Date: Sun, 7 Oct 2001 19:11:01 +0200

On Sun, Oct 07, 2001 at 03:20:11PM +0200, Marcus Brinkmann wrote:

> On Sun, Oct 07, 2001 at 05:19:28AM +0200, Marcus Brinkmann wrote:
> > The reason I could not continue testing the user tss is that
> > the i386_io_port_add call can't find the device -> io_port mapping.
>
> It turns out that the mach_device_t address registered with io_port_create
> doesn't match the mach_device_t address used to lookup the device again.
> I don't know why (yet).


The i386_io_port_add and i386_io_port_remove do not convert the device_t to
a mach_device_t as the other device RPCs for i386 (this is connected to the
glue code in i386/i386at/i386at_ds_routines.c, which is introduces another
level of indirection for device RPCs, without changing the io_port rpcs as
well).

I have fixed this, and i386_io_port_add finds the i/o port list now.
However, the I/O permission are not correctly updated, I still get an
Illegal Instruction exception.  So I am continuing to debug this.

The below patch is to only fix this particular problem.  It's as ugly as the
rest of the glue code :)

Thanks,
Marcus

See patch2

Message received at -email is unavailable- (full text, mbox):

From: Roland McGrath <roland@frob.com>
To: -email is unavailable-
Date: Sun,  7 Oct 2001 15:32:15 -0400 (EDT)

The 0xff byte after the bitmap is a terminator byte, check your Intel book
vol 1, section 9.5.2.  So that, at least, is not the bug you thought it
was.  Note that that extra byte is included in the calculation for the
segment descriptor limit (which is a limit, not a size, so it always has -1).

Your fix is ok, though I would use memset (not that it matters for a
boot-time only thing).

According to my Intel book, the other solution is to have no io bitmap
space at all: missing bits are treated as disallowed if the bitmap is
shorter than 64k, down to 0.  So just changing the limit in the
fill_gdt_descriptor call to sizeof(ktss)-1 should do it too.
If that solution works, it seems preferable off hand.
(That is what you get from oskit's base_tss, which oskit-mach uses.)

Message received at -email is unavailable- (full text, mbox):

From: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>
To: Roland McGrath <roland@frob.com>, -email is unavailable-
Subject: Re: Bug #46709: (no subject)
Date: Sun, 7 Oct 2001 22:20:48 +0200

On Sun, Oct 07, 2001 at 03:32:15PM -0400, Roland McGrath wrote:

> The 0xff byte after the bitmap is a terminator byte, check your Intel book
> vol 1, section 9.5.2.


Ah, that explains it.  I have seen the extra byte, and was wondering what I
missed.  I have the Intel books now (got them today), so I can read up more
about this stuff.

BTW, the user tss does not contain such a terminator, so I will add one.

> Your fix is ok, though I would use memset (not that it matters for a
> boot-time only thing).


Yes, of course that's better.

> According to my Intel book, the other solution is to have no io bitmap
> space at all: missing bits are treated as disallowed if the bitmap is
> shorter than 64k, down to 0.


It also should work to set the io bitmap base address to or beyond the
segment with the same effect.

Thanks,
Marcus

Message received at -email is unavailable- (full text, mbox):

From: Roland McGrath <frob@debian.org>
To: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>
Cc: -email is unavailable-
Subject: Re: Bug #46709: (no subject)
Date: Sun,  7 Oct 2001 16:39:37 -0400 (EDT)

> On Sun, Oct 07, 2001 at 03:32:15PM -0400, Roland McGrath wrote:
> > The 0xff byte after the bitmap is a terminator byte, check your Intel book
> > vol 1, section 9.5.2.
>
> Ah, that explains it.  I have seen the extra byte, and was wondering what I
> missed.  I have the Intel books now (got them today), so I can read up more
> about this stuff.
>
> BTW, the user tss does not contain such a terminator, so I will add one.
>
> > Your fix is ok, though I would use memset (not that it matters for a
> > boot-time only thing).
>
> Yes, of course that's better.
>
> > According to my Intel book, the other solution is to have no io bitmap
> > space at all: missing bits are treated as disallowed if the bitmap is
> > shorter than 64k, down to 0.
>
> It also should work to set the io bitmap base address to or beyond the
> segment with the same effect.


That's what I meant by the bitmap being shorter.  It spans from the
specific base address (and offset from the beginning of the tss) to the end
of the segment, so the segment consists of nothing but the tss when the
bitmap is empty.


Message received at -email is unavailable- (full text, mbox):

From: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>
To: Roland McGrath <frob@debian.org>
Cc: -email is unavailable-
Subject: Re: Bug #46709: (no subject)
Date: Sun, 7 Oct 2001 22:41:31 +0200

On Sun, Oct 07, 2001 at 04:39:37PM -0400, Roland McGrath wrote:
(I said:)

> > BTW, the user tss does not contain such a terminator, so I will add one.


This is wrong, it's called barrier and is there.  I was just confused.

> > It also should work to set the io bitmap base address to or beyond the
> > segment with the same effect.
>
> That's what I meant by the bitmap being shorter.


Ok.

Thanks,
Marcus

Message received at -email is unavailable- (full text, mbox):

From: Florian Weimer <fw@deneb.enyo.de>
To: -email is unavailable-
Subject: Bug status
Date: Sun, 30 Oct 2005 23:14:14 +0100

Is this security bug still open, after more than six years?

Message received at -email is unavailable- (full text, mbox):

From: "Alfred M\. Szmidt" <ams@gnu.org>
To: Florian Weimer <fw@deneb.enyo.de>, -email is unavailable-
Cc: 46709@bugs.debian.org, debian-bugs-dist@lists.debian.org, -email is unavailable-
Subject: Re: Bug #46709: Bug status
Date: Sun, 30 Oct 2005 23:37:14 +0100

   Is this security bug still open, after more than six years?

Yes, but it doesn't belong in the Debian BTS.  It would be nice if
someone could file all these bug reports into the proper place,
http://sv.gnu.org/p/hurd.


Samuel Thibault <sthibaul>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #2197:  patch-hurd-ioperms added by None (3KiB - application/octet-stream - corrected changelog and GCS ; replaces file #3241 : patch-hurd-ioperms)
file #2204:  patch-gnumach-6-io_device added by None (5KiB - application/octet-stream - corrected changelog, moved the io device to an arch-independant place ; replaces file #3254 : patch-gnumach-6-io_device)
file #2203:  patch-gnumach-5-io_per_task added by None (15KiB - application/octet-stream - corrected changelog ; replaces file #3240 : patch-gnumach-5-io_per_task and patch #4740.)
file #2202:  patch-gnumach-4-more_ports added by None (2KiB - application/octet-stream - corrected Changelog ; replaces file #3239 : patch-gnumach-4-more_ports)
file #2201:  patch-gnumach-3-device_port_fix added by None (1KiB - application/octet-stream - Updated changelog and comment in code ; replaces file #3238 : patch-gnumach-3-device_port_fix)
file #2209:  patch-gnumach-2-default_noio added by None (2KiB - application/octet-stream - corrected Changelog ; replaces file #3237 : patch-gnumach-2-default_noio)
file #2243:  patch-xorg-hurd-ioperms-all added by None (2KiB - application/octet-stream - Make Xorg 6.9 request for any IO permissions. Replaces file #3242.)
file #2242:  patch-gnumach-6-io_device added by None (3KiB - application/octet-stream - Adds to gnumach an "io" device that represents all io ports.)
file #2261:  patch-xorg-hurd-ioperms-isa added by sthibaul (2KiB - application/octet-stream - Make Xorg 6.9 request for IO permissions)
file #2260:  patch-hurd-ioperms added by sthibaul (3KiB - application/octet-stream - Make the Hurd console request for IO permissions)
file #2299:  patch-gnumach-5-io_per_task added by sthibaul (16KiB - application/octet-stream - Make io permissions per task)
file #2298:  patch-gnumach-4-more_ports added by sthibaul (1KiB - application/octet-stream - additionnal ports needed by the Hurd console)
file #2297:  patch-gnumach-3-device_port_fix added by sthibaul (1KiB - application/octet-stream - Corrected version of patch2, can be applied asap)
file #2296:  patch-gnumach-2-default_noio added by sthibaul (1KiB - application/octet-stream - Corrected version of patch2, independent of every other patches, should only be applied when the hurd Console and xfree86/xorg are ready to ask for i/o permissions.)
file #2278:  patch2 added by sthibaul (1KiB - application/octet-stream)
file #2277:  ioport3.c added by sthibaul (2KiB - text/x-csrc)
file #2276:  ioport2.c added by sthibaul (2KiB - text/x-csrc)
file #2275:  patch1 added by sthibaul (1KiB - application/octet-stream)
file #2274:  ioport.c added by sthibaul (779B - text/x-csrc)
file #2273:  util.h added by sthibaul (180B - text/x-chdr)

 

Depends on the following items: None found

Items that depend on this one
taskRelease GNU Mach 1.4 (task #6111, Done)

Digest:
   task dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by sthibaul (Updated the item)
  • -email is unavailable- added by tschwinge (Posted a comment)

    •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 25 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-02-03 sthibaul StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2007-05-07 tschwinge StatusConfirmed Ready For Test
    2006-11-16 tschwinge Dependencies- task #6111 is dependent
    2006-05-08 tschwinge Assigned toNone tschwinge
        Planned ReleaseNone GNU Mach 1.4
    2006-01-14 None Attached File- Added patch-hurd-ioperms, #3275
    2006-01-14 None Attached File- Added patch-gnumach-6-io_device, #3274
    2006-01-14 None Attached File- Added patch-gnumach-5-io_per_task, #3273
    2006-01-14 None Attached File- Added patch-gnumach-4-more_ports, #3272
    2006-01-14 None Attached File- Added patch-gnumach-3-device_port_fix, #3271
    2006-01-14 None Attached File- Added patch-gnumach-2-default_noio, #3270
    2006-01-06 None Attached File- Added patch-xorg-hurd-ioperms-all, #3255
    2006-01-06 None Attached File- Added patch-gnumach-6-io_device, #3254
    2006-01-02 sthibaul Attached File- Added patch-xorg-hurd-ioperms-isa, #3242
    2006-01-02 sthibaul Attached File- Added patch-hurd-ioperms, #3241
    2006-01-02 sthibaul Attached File- Added patch-gnumach-5-io_per_task, #3240
    2006-01-02 sthibaul Attached File- Added patch-gnumach-4-more_ports, #3239
    2006-01-02 sthibaul Attached File- Added patch-gnumach-3-device_port_fix, #3238
    2006-01-02 sthibaul Attached File- Added patch-gnumach-2-default_noio, #3237
    2005-12-30 ams StatusNone Confirmed
    2005-12-26 sthibaul Attached File- Added patch2, #3219
    2005-12-26 sthibaul Attached File- Added ioport3.c, #3218
    2005-12-26 sthibaul Attached File- Added ioport2.c, #3217
    2005-12-26 sthibaul Attached File- Added patch1, #3216

    Back to the top

    Copyright © 2024 Free Software Foundation, Inc.
    Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
    The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team.
    Page source code

    Powered by Savane 3.13-6755.
    Corresponding source code