flat assembler
Message board for the users of flat assembler.
Index
> Windows > 64 bit not understood sub rsp,8 ! Goto page Previous 1, 2, 3, 4, 5, 6, 7, 8, 9 Next |
Author |
|
Overclick 19 May 2022, 02:08
Sorry for stupid questions, but I mean this:
https://docs.microsoft.com/en-us/windows/win32/procthread/scheduling-priorities https://docs.microsoft.com/en-us/windows/win32/procthread/context-switches It doesn't seems to run by hardware only but OS. If so, how exactly that happen? Wiki says this:
|
||||||||||
19 May 2022, 02:08 |
|
Overclick 19 May 2022, 02:20
Quote:
That I mean. So question still the same -- how? Where exactly Windows saves context? Does it move somewhere or use apps stack? If so, doesn't it use some SSE for that? Isn't it potential timebomb for sub rsp,1 ... add rsp,1? |
|||
19 May 2022, 02:20 |
|
revolution 19 May 2022, 02:22
The kernel keeps it's own memory to store the state of each thread's context.
Don't panic, your stack is always safe, the kernel won't touch it. It wouldn't be very secure if it needs to use user space memory to store it's data. |
|||
19 May 2022, 02:22 |
|
macomics 19 May 2022, 02:29
This means that you can not use hardware structures to switch tasks to the full extent. But this does not negate the fact that they must be present and filled in correctly in any case, at least in one instance.
When you are in ring0, no one forbids you to manually change the ring3 data in the current TSS and switch to yourself. So, through the same gateway, you will call the same system code, which will launch another user task. Register information and status will be manually loaded into all processor registers from system structures. But switching tasks will happen by the same mechanism. Due to manual switching, the generation of an interrupt for updating the FPU/XMM context will be prevented, which will greatly simplify and speed up task switching. That is, to create multitasking, Windows and Linux do not rely on hardware structures, but only update data in them using their own structures. Last edited by macomics on 19 May 2022, 02:37; edited 1 time in total |
|||
19 May 2022, 02:29 |
|
Overclick 19 May 2022, 02:30
Quote:
I don't as I don't use rsp like this )) But we have to clear this risks too where we looking for truth about sub rsp,1 )) |
|||
19 May 2022, 02:30 |
|
macomics 19 May 2022, 02:40
The whole truth can be gleaned from the description of the sub rsp, 1 command in the IntelSDM. What is said there does not contradict the system mechanisms in any way. An exception will never be generated by this command.
|
|||
19 May 2022, 02:40 |
|
revolution 19 May 2022, 02:42
One important thing to realise is that when the kernel is executing it doesn't use any of the user's registers. It has it's own values for RSP, RIP, etc. So it makes no difference what values you have in your thread, the kernel doesn't use them. With the caveat that exceptions are the one place where the kernel needs to use your RSP value is to store the context and pass it on to your app.
If you have an invalid RSP value and then cause an exception, and you have asked to receive such exceptions, then when the kernel tries to transfer the context to your invalid stack, it also gets an exception. And I bet you can guess what happens next, the kernel kills your app. There is a slight difference to the behaviour when the app is killed in this fashion. Usually for an unhandled exception the OS displays a message saying your app was killed. But in my testing for apps killed due to exceptions encountering an invalid stack the OS silently kills the app, no message, no nothing. But this behaviour is probably version dependant. Perhaps the newer versions of Windows treat both the same now? |
|||
19 May 2022, 02:42 |
|
macomics 19 May 2022, 02:51
revolution wrote: If you have an invalid RSP value and then cause an exception, and you have asked to receive such exceptions, then when the kernel tries to transfer the context to your invalid stack, it also gets an exception. And I bet you can guess what happens next, the kernel kills your app. |
|||
19 May 2022, 02:51 |
|
Overclick 19 May 2022, 03:43
Quote:
That is clear, I care about stack pointer. Quote:
Same here, but Windows old too (Server2008r2) I don't think they fix it )) |
|||
19 May 2022, 03:43 |
|
revolution 19 May 2022, 05:57
macomics wrote: Triple fault Otherwise it would be really easy to triple fault Windows. Code: format ... ; <register for exceptions here> begin: xor rsp, rsp hlt ; OMG!! Triple fault? |
|||
19 May 2022, 05:57 |
|
macomics 19 May 2022, 09:55
revolution wrote:
|
|||
19 May 2022, 09:55 |
|
revolution 19 May 2022, 12:01
Triple fault is worse than that. It triggers a hardware CPU reset.
Modern OSes will not use it. However the 80286 OSes did use it, deliberately. Because once the CPU was placed into protected mode, there was no way to get out without a CPU reset. So the solution was to deliberately cause a triple fault. Then the CPU starts again in real mode, and the OS can carry on, but now it is in real mode. |
|||
19 May 2022, 12:01 |
|
macomics 19 May 2022, 12:35
revolution wrote: Triple fault is worse than that. It triggers a hardware CPU reset. |
|||
19 May 2022, 12:35 |
|
revolution 19 May 2022, 12:43
macomics wrote: If the OS failed to handle the error, then we see so often the previously mentioned BSOD and reboot. I'm not sure if it is really true, but it is plausible IMO. There is lots of badly designed cheap hardware around. |
|||
19 May 2022, 12:43 |
|
macomics 19 May 2022, 12:56
I think so too, but for old times' sake I still mention it. Win9x could still be brought to a state of panic and BSOD even by a regular program.
|
|||
19 May 2022, 12:56 |
|
Furs 19 May 2022, 13:47
Technically even in latest Windows you can cause BSOD by deliberately abusing some driver bug or hardware bug.
|
|||
19 May 2022, 13:47 |
|
macomics 19 May 2022, 14:55
If we summarize the work with the stack a little and look at the operation of the mechanism for accessing virtual memory, then perhaps something will become more clear and understandable.
Code: user command: push rax -> microcode { subtract rsp, 8 -> move [rsp], rax } (simplified) #virtual: move [rsp], rax -> cs selector: iiiiiiiiiiii0tcc, ss selector: iiiiiiiiiiii0trr + descriptor: b..bbddylb..bl..l where c & r - ring index (CPL & RPL), t - table (GDT / LDT), i - table index, b - base address, d - DPL bits, y - type, l - limit >>> priority check: if (cpl >= rpl > dpl) #SS(0) read page tables & virtual mode bits (cr0.pt, cr4.pae, etc): cr3 -> base address (PLM5 / PLM4 / PDPTE / PDE) #linear: Base address + rsp: ccccccc000000000111111111222222222333333333444444444555555555555 where c - canonical address, 0 - PLM5 index, 1 - PLM4 index, 2 - PDPTE index, 3 - PDE index, 4 - PTB index, 5 - Page offset >>> alignment check: if (fl.AC and ~(b+sp) & 111b) #AC >>> reference check: if (~is_canonical(rsp)) #GP(0) PLM5: b..b*up where b - base address (PLM4), * - other page flags, u - user / super, p - present >>> priority check: if (~u and cpl != 0 or ~p) #PF(fault_code) PLM4: b..b*up where b - base address (PDPTE), * - other page flags, u - user / super, p - present >>> priority check: if (~u and cpl != 0 or ~p) #PF(fault_code) PDPTE: b..b*up where b - base address (PDE), * - other page flags, u - user / super, p - present >>> priority check: if (~u and cpl != 0 or ~p) #PF(fault_code) PDE: b..b*up where b - base address (PTB), * - other page flags, u - user / super, p - present >>> priority check: if (~u and cpl != 0 or ~p) #PF(fault_code) PTB: b..b*up where b - base address (Page), * - other page flags, u - user / super, p - present >>> priority check: if (~u and cpl != 0 or ~p) #PF(fault_code) #physical: [Page + Page offset] = rax Last edited by macomics on 19 May 2022, 16:12; edited 4 times in total |
|||
19 May 2022, 14:55 |
|
revolution 19 May 2022, 15:30
Notice one main thing there:
There is no alignment check. You can use the stack unaligned if you wish to. It won't necessarily be optimal, but it can be done. |
|||
19 May 2022, 15:30 |
|
macomics 19 May 2022, 15:54
revolution wrote: There is no alignment check. More about TLB can be mentioned. But this is already from the cache area. |
|||
19 May 2022, 15:54 |
|
Goto page Previous 1, 2, 3, 4, 5, 6, 7, 8, 9 Next < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.