[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