[Prev][Next][Index][Thread]
Re: DPL_3 IDT entries
Le Jeudi 16 Novembre 2000 22:33, Alastair Reid a écrit :
> Rogelio M. Serrano Jr. writes:
> > Why are most of the default IDT entries have a DPL 0? What issues are
> > involved with DPL 3 IDT entries?
>
> If I understand you correctly, you're asking why we run in privileged mode
> (as though we were an OS kernel) instead of in unprivileged mode (as though
> we were a normal application)?
>
> The answer is that some of the OSKit components need to run in that mode.
> I'm not sure exactly which ones but the most likely suspects are the SVM
> component (which manipulates the MMU) and code taken from environments
> which use DPL 0 (I believe/imagine this includes Linux and FreeBSD device
> drivers).
>
> That said, I imagine (but don't know for sure) that most OSKit code
> couldn't care less which mode it runs in so you probably could build
> interesting OSKit kernels using DPL 3 entries though you'll have to check
> the standard (and somewhat tortuous) bootstrap sequence carefuly.
Tha's not exactly Rogelio's question. The DPL field in an IDT entry is the
level at which a code must run to be able to call the descriptor with an "int
$vector" instruction. You have to put 0 to the entries corresponding to
hardware interrupts. It prevents the user from letting the OS think that an
hardware interrupt has occured by using "int $irq_vector".
In fact, you only have to put the level 3 to entries corresponding to system
calls : the only entries that may be called from user space with an "int"
operation.
Now, with the Pentium II and above processors, you can use another pair of
instruction for system traps : SYSENTER and SYSEXIT. It seems to be faster
that trap gates.
References: