whats the point os clearing SS after cpl switch?
esp is loaded from ist, and ss is 0.


any reason they did that this way?
if i want to use a stack, i must load ss manually. and when i load manually ss, i could also load esp.

why provide this diffrent scheme for ss and esp?
performance issues? they care about those 1/4 cycle it would take interrupt to load ss or what?

so performance is the answer.
retf return always to higher privilege. cpu null ss anyway, as any other segment register wich is loaded with less priviliged data!

could you tell me the exact reason, why they did that? or it was just an random decission?

why then cpu loads RSP from TSS?

tell me something i dont know.
or never mind, you dont know either i guess.

yes i know it but WHY? why disconnest RSP rfom SS in manner of switching?!


how does value of SS affect nested transfers? i dont get it, when i issue int/call/interrupt, ss should be ALWAYS (in 64 bit mode not only when cpl change) pushed along with RSP.


does it mean, when i return from something and ss is null, i may keep it?
returning is always to more priviliged area, so its kernel > user.
kernel set SS to for example kernel only segment with DPL = 0, and then it pass down via ret unmodified segment register.
what will happen? i can access kernel segment from userland! remember that cpl is onlr checked when loading segment register! i have full access to kernel segment! of course if its in flat mode there is no danger.
now lets think is it possible for userland app to push null ss.

user code (ss != 0) is interrupted by something. ss = 0, ss on stack = old ss wich is != 0. interrupt happend with CPL = 2. next interrupt occur, with CPL = 0.
null ss is pushed on stack. ring0 code load special secret descriptor into ss, and return to higher, cpl = 2. ss on stack was 0, so now ring2 can access ring0 data.
great. did i just found a bug?

ive noticed long mode enforce flat memory model in few ways.
this 'bug' might be 1 of those ways.
if only ring 0 and 3 are used, its ok.

a115433,

Interrupt/exception handler returns with iret, AFAIK.

Loading ss with NULL by retf/iret when 64-bit target CPL<3 simply does not cause descriptor load (and #GP thereof). Access via NULL ss still causes exception afterward.

code is in cpl = 3.
it escalate to cpl = 2 via call gate.
stack:

ss
rsp
rflags
cs
rip

code is now in cpl = 2, with RSP from TSS. ss is null, in order to use any stack operations it has to load it.
before loading ss exception fires, lets say clock.
ss is 0, and #GP fires instead.
ss is still 0, so #GP cant continue, and another #GP fires.
this continue untill machine is physicly RESET.

a115433,

Why #GP fires when clock interrupt occurs? Ring 2 code isn't established valid stack segment selector yet, but processor interrupt handling doesn't use ss anyway, it uses proper ring stack (corresponding to handler's code segment DPL) to save registers.

NULL ss disallows your code to access data via it, not processor itself (as it does even before ring 2 code begins execution).

it uses proper ring stack (corresponding to handler's code segment DPL) to save registers.

you mean it take rsp from IST, and bypass SS?


so, reason for passing null stack is just to make me add code to load ss?
there must be a reason!

a115433,

Yes, from RSP0…2 (or IST if told to do so).

64-bit TSS doesn't contain selectors for stack segment, can you propose any other reasonable value to load into ss when privilege level changes?

right i get it now.
ss and rsp both must be changed, and zeroing ss is just a consequence of lack ss's in TSS.

oh well, i guess its the end of this thread, all secrets solved.