bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Gnumach and I/O


From: Samuel Thibault
Subject: Re: Gnumach and I/O
Date: Sat, 11 Mar 2006 01:21:30 +0100
User-agent: Mutt/1.5.9i-nntp

Roland McGrath, le Fri 10 Mar 2006 16:04:05 -0800, a écrit :
> > Then why splitting ioperm()'s work into two i386_io_perm_create()
> > and i386_io_perm_modify() calls
> 
> More concretely, it separates the general permission from the specific
> permission, making the latter a transferrable capability, which is the
> Mach and Hurd style of doing things.

Ah, yeah ok, this makes sense (didn't think about this
possibility). However, the implementation should then be as I thought in
the first place:

> When I had a first look at this, I thought that the idea was that
> these "io ranges" would give io permission when i386_io_perm_modify is
> used for actually enabling them, and until they are destroyed ; i.e.
> just like how gnumach 1's i/o permissions are supposed to work

Because else, the nasty scenario I already mentionned before can happen:

- some task A creates an io range 1 for speaker+timer, and gives it to
C, telling it "this is for speaker access" (yes, access to some part of
the timer is needed for this too).
- some task B creates an io range 2 for timer, and give it to C, telling
it "this is for timer access".
- C enables its io range 1 ("speaker access"), enables its io range 2
("timer access"). He has both io permissions.
- C doesn't need speaker access any more, so it disables its io range 1
("speaker access"). But with the current gnumach2 implementation, this
disables timer access too! (since it's in io range 1) C gets SIGILL :)

Since C can't know how io ranges 1 and 2 overlap, it can't know how to
solve this.

Maybe we can consider that io ranges will never overlap, and hence keep
the current gnumach 2 implementation.

Doing it right, like I thought in the first place --- when io range 1
is disabled, timer access is not dropped because io range 2 is still
enabled --- is a bit more difficult, but should be feasible: by keeping
a list of enabled io ranges, one can look for overlapping ones, and
re-enable io access for them.

What do people prefer? :)

Regards,
Samuel




reply via email to

[Prev in Thread] Current Thread [Next in Thread]