From: Daniel G. <da...@fp...> - 2004-12-15 17:18:14
|
On Tue, 2004-12-14 at 19:11 -0800, Nathanael Bettridge wrote: > IOPL is a chiplevel function. It has no idea what root > even is. It sees only the three rings, and in flat > paging mode, AFAIK (and definitely in current > syllable), only ring 0 (kernel) and 3 (user) are > really relevant. In other words, if its allowed in > user mode, it can be done, regardless of the user > account. It might not be easy to get at via libc or > whatever, but it can still be done. To do things > properly, we'd have to either shunt hw-accessing code > to ring 1 or 2, or have it all done via syscalls. > > Disclaimer: of course, I could be wrong ;) No, it's still easy. IOPL is included in the saved context state when transitioning from 3 -> 0 (ie on a syscall or interrupt). Thus, it's restored during the 0 -> 3 transition (ie, on iret). Since Syllable, like all Unix kernels, stores this state on a per-process basis, it's easy to enable/disable IOPL on a per-process (or per-user, like most Unix does) basis. Obvsiously, Syllable's not currently doing this, but just allowing all processes to have IOPL enabled. This doesn't mean it couldn't be done. Most likely, we want to enable IOPL on the appserver, and deny it to anything else, by default. Linux does this based on it's fine-grained Capabilities. Daniel |