IO Protection

[Mius]

How can i implement io protection for user tasks?

[rverma]

You will have to create an IO Map which is associated with the context. kernel can mask the prohibited IO operations. So when ever an application does IO request, it has to be routed through kernel, and kernel will check for the IO MAP and allows/disallows the access to IO. I hope it helps.

[Mius]

But, how can i create an IO map?

[df]

its part of the TSS

[Dangamoose]

Read the Intel manual 3 on ia-32 processors under Task Management.

Dangamoose

[Mius]

But I don't use TSS!
I use software taskswitching.

[knicos]

You have to modify the IOPL bits in the EFLAGS register to restrict user access to opcodes (eg in, out, ...)

[Mius]

But, can i allow a process to use only a few ports, and not restrict all the accesses to the ports?

(sorry for my very bad English)

[df]

no, thats what the IO permissions bitmap is for in the TSS. if you use software switching, then the answer is, no.

[Mius]

But Linux uses software taskswitching, doesn't it?

[carbonBased]

No, Linux uses TSS based task switching.

What you might be thinking of (and I'm not sure if Linux does this) is a hybrid between software and hardware task switching.

Essentially, there are only two TSSs in use, ever... to switch tasks, inside your timer interrupt, you copy the appropriate data into the TSS that's not in use and jump to it.

Alternatively, you can have your timer interrupt in a task gate, and change the data in the TSS that it will return to upon an iret.

These are crude explainations, I realize... I'm fairly certain both methods work, but I haven't yet implemented either.  I'm currently using straight TSS based multitasking, but am considering a switch very soon... at the very least, they both afford me more then 8192 possible tasks/threads.

Cheers,
Jeff

[df]

im sure linux uses software switching to save/load state, rather than TSS.