OSDev.org

James molloy sets the access byte in the tss's gdt entry as 0xE9... the flag byte is set to zero

ok, let me break this down

0xE9 is 0b11101001

dpl is set to 3 ----> why is dpl for tss set to user mode? why?

ex bit is 1 ---> why is tss executable? why?

rw bit is 0 -----> what does it mean? tss should be writable right, before esp0 and ss0 will be used to store esp and ss?

sz bit is 0 -----> it is 16 bit protected mode? 32 bit sounds more right?

also the limit field is the size of the tss struct right? james molloy also had bug computing the limit field of tss..

Someone please explain those bits to me!!!!

ITchimp wrote:dpl is set to 3 ----> why is dpl for tss set to user mode? why?

Because the guy made mistakes. The TSS DPL will only matter if hardware task switching is actually used, and someone jumps to that TSS. But since it is the only TSS in the system, it must be busy. When interrupted by a task gate, it will still be busy. Therefore a jump to the TSS will merely result in a GPF.

Quite frankly, for a software task switching system, the DPL of the TSS does not seem to matter a great deal. Still, it should be set to 0, so userspace can't futz with it. It is possible I'm overlooking something. Maybe userspace can jump to that TSS once, with weird consequences.

ITchimp wrote:ex bit is 1 ---> why is tss executable? why?

rw bit is 0 -----> what does it mean? tss should be writable right, before esp0 and ss0 will be used to store esp and ss?

sz bit is 0 -----> it is 16 bit protected mode? 32 bit sounds more right?

Those bits are for data/code segments. Since, however, the S bit of the descriptor is clear, it is a system segment. Therefore the low nybble of that byte is a "type" field. Type 9 stands for "32-bit TSS (available)".

ITchimp wrote:Someone please explain those bits to me!!!!

Multiple exclamation marks, the sure sign of a diseased mind. (Terry Pratchett)

Anyway, you could just look it up in the bloody documentation, which other people have been patiently explaining to you. You go to the search engine of your least distrust, type in "intel software developer's manual", find this page: https://software.intel.com/content/www/ ... and-4.html
Then you hit "download". In the downloaded document, volume 3 (the one most interesting to you) starts at page 2700. You want to have a look at chapter 3. I did nothing else to answer your question.

Oh, and you ditch the bloody Molloy tutorial, it has been nothing but a source of grief on this forum.

Thanks so much for the pointer, I am reading the intel manual right now...
one more question pops up...
the limit field...

I have seen certain variation on this

1. limit is the size of segment

2. limit is the the end of the segment meaning it is base +sizeof(tss_entry) in my case...

I am reading intel manual and still can't decide which one is correct....

Neither is correct, but one is only off by one. As page 2798 states, for expand-up segments (the normal kind), the limit is the highest allowed offset into the segment. For the TSS, it should therefore be set to the size of the TSS minus 1. That is why, for all-encompassing segments, you use a limit of 0xFFFFF and the granularity bit. The highest allowed offset if therefore 0xFFFF_FFFF, which is all of address space. If the limit was the size of the segment, the last page of address space could not be accessed if the base address is 0.