Hi, I'm experimenting with some x86 code that involves reading from I/O ports. I noticed--much to my surprise--that I don't have to use seL4_IA32_IOPort_In8() to read from a port; my program works just as fine using the "in" assembly statement directly, without any caps. The TSS segment limit is initialized with 0x67 https://github.com/seL4/seL4/blob/master/src/arch/x86/kernel/vspace.c#L158 and the "I/O Map base address" is initialized with 0 (zero) https://github.com/seL4/seL4/blob/master/src/arch/x86/kernel/vspace.c#L43 I believe the result is that ring 3 programs can access I/O port addresses below 0x388 (0x67 * 8) without triggering a protection violation. So my question is: Shouldn't capabilities be required for all ports? Or what what is the reason or motivation behind this? Thanks, Josef
Hi Josef, Looks like just a mistake from whoever did the original port. All port accesses are meant to require capabilities to perform. Thanks for pointing this out, I will push out a fix shortly. Adrian On Mon 24-Aug-2015 11:45 PM, Josef M. wrote:
Hi,
I'm experimenting with some x86 code that involves reading from I/O ports. I noticed--much to my surprise--that I don't have to use seL4_IA32_IOPort_In8() to read from a port; my program works just as fine using the "in" assembly statement directly, without any caps.
The TSS segment limit is initialized with 0x67 https://github.com/seL4/seL4/blob/master/src/arch/x86/kernel/vspace.c#L158
and the "I/O Map base address" is initialized with 0 (zero) https://github.com/seL4/seL4/blob/master/src/arch/x86/kernel/vspace.c#L43
I believe the result is that ring 3 programs can access I/O port addresses below 0x388 (0x67 * 8) without triggering a protection violation.
So my question is: Shouldn't capabilities be required for all ports? Or what what is the reason or motivation behind this?
Thanks, Josef
_______________________________________________ Devel mailing list Devel@sel4.systems https://sel4.systems/lists/listinfo/devel
________________________________ The information in this e-mail may be confidential and subject to legal professional privilege and/or copyright. National ICT Australia Limited accepts no liability for any damage caused by this email or its attachments.
participants (2)
-
Adrian Danis
-
Josef M.