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 _______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://mail.gnu.org/mailman/listinfo/bug-hurd