while executing syscall, where does kernel get its stack?

int use TSS, sysenter use IA32_SYSENTER_ESP, what about syscall?
does the stack isnt switched, and im executing on userland stack while cpl = 0?
or TSS is used?

i think (since you load a selector in IA32_STAR[47:32]), stack pointer isnt changed at all, but access is made through kernel segment. but if its right, why bother with IA32_STAR[47:32]? just reload CS and stack stays, ehh.

any suggestions?

Almost true. syscall loads next selector (remember "IA32_STAR_MSR[47:32]+8"?) into ss, modifying [shadow] descriptor to be flat (0+4GiB) R/W expand-up segment with DPL==0. It's a fast switch, kernel code ends up with same esp as syscaller (probably pointing into probably flat caller's stack segment).

hmmm.. so i can deallocate stack while kernel is accessing it?
i can do that from cpl = 3, os will page fault in cpl = 0, and thats not good i guess?

or kernel before accessing arguments must use something like MmProbeAndLockPages() on stack (create mdl first ofc), then access it?
Also i can pass sensitive read only address (there is that in windows, containing systemroot path, ticks and other stuff)?


syscall/sysret are newer than sysenter/sysexit, are they better? how to handle stack (no)switch? And how does it know the size of allocation, or limit? i can do whatever i want.

How're you supposed to do that while you don't have control? SMP? Race condition.

Locked pages are entirely another issue.

syscall is just as it is, fast transfer to ring 0 without excessive checks.

When in doubt, RTFM. I'll collaborate, but only in constructive cases, OK?

!rolling

ive found about swapgs instruction, wich can be used to replace GS base with address of data.


ok, what about preemption?
thread execute syscall, swapgs, and gets preempted?
MSR holding kernel struct is swapped with propably 0 from GS, and next thread will want to swapgs = what?

or maybe context switching also save this msr?

asmmsa: Preemption is controlled by the OS. It is not an automatic hardware function. If the OS wants to run another task then it switches when it is ready.

ok but how context scheduler knows, when GS was swapped, and when it wasnt?

when for example timer interrupt fires, this scheduler checks if thread has any time left, and if it does not have, its switched. And when its switched, MSR of GS is not saved or changed, wich leads to my question.

does syscall/sysret work on multitasking os or not?

Well it has been used in Windows and Linux for many years now. So I think it is safe to answer yes.

linux pass arguments in registers so its nor really a problem.
windows use stack, so what about it?

swapgs cant be used to get pointer to kernel stack because it destroy MSR holding gs base.


you dont know, right? maybe syscall/sysret are not designed to support stack switching? if so, they suck badly and i wonder why they are used. sysenter/sysexit are way better.

Just compare the value in GS to see if you have the kernel value or some other value. This is not supposed to be a problem when writing an OS and the syscall/sysret can absolutely 100% support all type of multitasking and stack switching in any way you want to implement it. You just have to use them properly.

so, before making task switch, i must check if my GS base is = predefined kernel value, and if it is, execute swapgs and save somewere information that gs was swapped. when switching to new task, read this information and if set, swapgs.

It just depends upon how you write your OS kernel. Without knowledge of your code no one else can say what will work for you in you code.