On Tue, Apr 29, 2003 at 10:33:09PM -0400, Chuck Ebbert wrote:
> Gabriel Paubert wrote:
>
> >> And shouldn't CR3 be intitialized in case anyone actually wants to
> >> switch back to the kernel TSS?
> >
> > For now no, since the only task gate ever taken (double fault), never
> > returns (you don't want to update the TSS's CR3 field on every
> > switch_to() so you would have to do it in the task gate return
> > path, as well as having a correct LDT field).
>
> I want to write a TSS-based debug exception handler that just does
> an iret when it gets invoked. For now it looks easier to just keep
> CR3 up-to-date on every switch.
It seems cr3 is in the same cache line as esp0 for a 32 byte cache line,
so it's not that big a deal, but I'd still try to avoid this.
>
> > However, returning from a task gate is so much fraught with races wrt
> > segment registers that the best thing to do is to avoid it.
>
> Even with interrupts off?
Yes. Consider the following:
create an LDT entry
load the segment to %fs
clear the LDT entry (or mark it non present),
-> %fs is now stale but still marked valid
...(no task switch)
Interrupt handled through task gate
-> stale selector written to TSS
...(interrupt handler)
iret-> TS/NP/SF exception when loading segments in the
new task (I believe it can't be GP)
Of course on an SMP machine with shared LDT, there are even more
ways of triggering segment related exceptions.
Currently %fs and %gs are lazily cleaned up when switching processes
using the standard fixup mechanism, %ds and %es are cleaned up if
necessary when popping them off the stack in the return to user
mode path (the one which ends up in iret). There is no way to recover
from bad user %cs/%ss, the process simply exits in the iret fixup.
But this works only because you can put a specific fixup for each
instruction which loads a given segment register (or two for iret).
In an iret from a task gate, you don't have this fine grained control
(all registers are loaded at once and then checked one by one)
and the return address is unpredictable, so the fixup mechanism is out.
This does not mean that there is no way to safely return from an
interrupt handled through a task gate, but it's not simple (you
don't want to change the existing lazy cleanup mechanism which is
about as simple and low overhead as it gets for the common cases).
Gabriel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Apr 30 2003 - 22:00:35 EST