flat assembler
Message board for the users of flat assembler.

Index > OS Construction > long mode, NULL ss

Author
Thread Post new topic Reply to topic
a115433



Joined: 05 Mar 2010
Posts: 144
a115433
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?
Post 06 Mar 2010, 22:16
View user's profile Send private message Reply with quote
ouadji



Joined: 24 Dec 2008
Posts: 1081
Location: Belgium
ouadji
Perhaps an answer here :

Intel 3A/5.8.5 : Stack Switching

"Whenever a call gate is used to transfer program control to a more privileged ...
.... the processor automatically switches .... etc"

Intel 3A/5.8.5.1 : Stack Switching in 64-bit Mode

"The new SS is set to NULL in order to handle nested far transfers ... etc"
...
"On the subsequent RETF, the NULL SS on the stack acts as a flag
to tell the processor not to load a new SS descriptor ..... etc "
...
Intel books

_________________
I am not young enough to know everything (Oscar Wilde)- Image
Post 06 Mar 2010, 22:56
View user's profile Send private message Send e-mail Reply with quote
a115433



Joined: 05 Mar 2010
Posts: 144
a115433
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?
Post 06 Mar 2010, 23:17
View user's profile Send private message Reply with quote
ouadji



Joined: 24 Dec 2008
Posts: 1081
Location: Belgium
ouadji

5.8.6 : Returning from a Called Procedure

The RET instruction can be used to perform
- a near return,
- a far return at the same privilege level
- a far return to a different privilege level

1. / 2. /3.
4. : (If the return requires a privilege level change.)
Loads the SS and ESP registers with the saved SS and ESP
values and switches ... etc ...

here too, in the same book (3A)
Table 5-2. 64-Bit-Mode Stack Layout After CALLF with CPL Change

you should read yourself the intel doc, it's very interesting.
Intel books



_________________
I am not young enough to know everything (Oscar Wilde)- Image
Post 06 Mar 2010, 23:29
View user's profile Send private message Send e-mail Reply with quote
a115433



Joined: 05 Mar 2010
Posts: 144
a115433
tell me something i dont know.
or never mind, you dont know either i guess.
Post 07 Mar 2010, 11:26
View user's profile Send private message Reply with quote
ouadji



Joined: 24 Dec 2008
Posts: 1081
Location: Belgium
ouadji

Quote:

why then cpu loads RSP from TSS ?

5.8.5.1 Stack Switching in 64-bit Mode

... 64-bit mode only loads an inner-level RSP from the TSS .. etc

everything you are looking for is in the Intel book.

_________________
I am not young enough to know everything (Oscar Wilde)- Image
Post 07 Mar 2010, 11:59
View user's profile Send private message Send e-mail Reply with quote
a115433



Joined: 05 Mar 2010
Posts: 144
a115433
Quote:
When stacks are switched as part of a 64-bit mode privilege-level change through a
call gate, a new SS (stack segment) descriptor is not loaded; 64-bit mode only loads
an inner-level RSP from the TSS.

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

Quote:
The new SS is set to NULL in order to handle
nested far transfers (CALLF, INTn, interrupts and exceptions).

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.

Quote:
On the subsequent RETF, the NULL SS on the stack acts as a flag to
tell the processor not to load a new SS descriptor.

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?
Post 07 Mar 2010, 12:31
View user's profile Send private message Reply with quote
ouadji



Joined: 24 Dec 2008
Posts: 1081
Location: Belgium
ouadji

yes i know it, but WHY ?

ok, i understand, i don't know "why" either.
a bug ? it is not impossible, but it would surprise me.
(sorry, my english is bad, i do my best)

_________________
I am not young enough to know everything (Oscar Wilde)- Image
Post 07 Mar 2010, 12:42
View user's profile Send private message Send e-mail Reply with quote
a115433



Joined: 05 Mar 2010
Posts: 144
a115433
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.
Post 07 Mar 2010, 13:40
View user's profile Send private message Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr
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.
Post 07 Mar 2010, 15:25
View user's profile Send private message Reply with quote
a115433



Joined: 05 Mar 2010
Posts: 144
a115433
Quote:
Loading ss with NULL by retf/iret when 64-bit target CPL<3 simply does not cause descriptor load (and #GP thereof).


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.
Post 07 Mar 2010, 15:37
View user's profile Send private message Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr
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).
Post 07 Mar 2010, 17:26
View user's profile Send private message Reply with quote
a115433



Joined: 05 Mar 2010
Posts: 144
a115433
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!
Post 07 Mar 2010, 17:41
View user's profile Send private message Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr
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?
Post 07 Mar 2010, 19:10
View user's profile Send private message Reply with quote
a115433



Joined: 05 Mar 2010
Posts: 144
a115433
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.
Post 07 Mar 2010, 20:20
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.