Hi,
I want to use the TSS I/O permission bit map to support fine grained control of I/O access for user-level apps (x86 32 bit target). From looking at the kernel code, I believe the bit map is switched out per-process as part of the Context class (Space::_io_space) - correct me if I am wrong. My query is how to set/clear the bits for a given target task from a "root" task with sufficient privileges (e.g., base caps and sigma0 caps). I could extend the kernel scheduler protocol, but I don't want to do this if there is already a clean way in place.
Thanks Daniel Waddington
Hi,
On Mon Jan 23, 2012 at 15:54:29 -0800, Daniel Waddington wrote:
I want to use the TSS I/O permission bit map to support fine grained control of I/O access for user-level apps (x86 32 bit target). From looking at the kernel code, I believe the bit map is switched out per-process as part of the Context class (Space::_io_space) - correct me if I am wrong. My query is how to set/clear the bits for a given target task from a "root" task with sufficient privileges (e.g., base caps and sigma0 caps). I could extend the kernel scheduler protocol, but I don't want to do this if there is already a clean way in place.
IO-ports are handled similar to page-faults, i.e. they can be mapped to other tasks, and the pager receives io-page-faults when one of its clients accesses an IO-port without having it. For example look for L4_PROTO_IO_PAGE_FAULT and l4_iofpage().
Adam
Hi Adam,
I see. So it seems that you have to map all of the IO port space before getting IOPL raised to 3 (assuming Kconfig IO_PROT & !IO_PROT_3) and therefore the default mode of operation is a driver will map the whole space if it wants to use IO instructions directly. Is it right that you currently don't use the TSS IO bitmap to allow access to only specific IO ports with CPL > IOPL?
Thanks Daniel
On 01/24/2012 11:03 AM, Adam Lackorzynski wrote:
Hi,
On Mon Jan 23, 2012 at 15:54:29 -0800, Daniel Waddington wrote:
I want to use the TSS I/O permission bit map to support fine grained control of I/O access for user-level apps (x86 32 bit target). From looking at the kernel code, I believe the bit map is switched out per-process as part of the Context class (Space::_io_space) - correct me if I am wrong. My query is how to set/clear the bits for a given target task from a "root" task with sufficient privileges (e.g., base caps and sigma0 caps). I could extend the kernel scheduler protocol, but I don't want to do this if there is already a clean way in place.
IO-ports are handled similar to page-faults, i.e. they can be mapped to other tasks, and the pager receives io-page-faults when one of its clients accesses an IO-port without having it. For example look for L4_PROTO_IO_PAGE_FAULT and l4_iofpage().
Adam
Hi,
On Tue Jan 24, 2012 at 13:12:03 -0800, Daniel Waddington wrote:
I see. So it seems that you have to map all of the IO port space before getting IOPL raised to 3 (assuming Kconfig IO_PROT & !IO_PROT_3) and therefore the default mode of operation is a driver will map the whole space if it wants to use IO instructions directly. Is it right that you currently don't use the TSS IO bitmap to allow access to only specific IO ports with CPL > IOPL?
'in' and 'out' are supposed to work just fine on single ports, no need to request all 64k ports for that and no iopl3 required.
Adam
After further experimentation and learning - I can confirm it does work as you say (at least on x86 32bit).
Daniel
On 01/25/2012 05:29 AM, Adam Lackorzynski wrote:
Hi,
On Tue Jan 24, 2012 at 13:12:03 -0800, Daniel Waddington wrote:
I see. So it seems that you have to map all of the IO port space before getting IOPL raised to 3 (assuming Kconfig IO_PROT& !IO_PROT_3) and therefore the default mode of operation is a driver will map the whole space if it wants to use IO instructions directly. Is it right that you currently don't use the TSS IO bitmap to allow access to only specific IO ports with CPL> IOPL?
'in' and 'out' are supposed to work just fine on single ports, no need to request all 64k ports for that and no iopl3 required.
Adam
l4-hackers@os.inf.tu-dresden.de