OSDev.org

x64
I would like to do syscall (syscall-sysret) from ring 0 to ring 0. Is it possible?

I try to change GDT to:

dq 0
dw 0ffffh,0,09b00h,0afh ; code R, ring 0
dw 0ffffh,0,09300h,0afh ; data RW, ring 0
dw 0ffffh,0,09300h,0afh ; data RW, ring 0
dw 0ffffh,0,09b00h,0afh ; code R, ring 0
dq 0e90000003001h + ((tss and 0xFFFFFF) shl 16) + ((tss and 0xFF000000) shl 32),tss shr 32 ; app tss

GPF, Bochs log: "check_cs(0x0023): non-conforming code seg descriptor dpl != cpl, dpl=0, cpl=3"

I try to change GDT to:
dq 0
dw 0ffffh,0,09b00h,0afh ; code R, ring 0
dw 0ffffh,0,09300h,0afh ; data RW, ring 0
dw 0ffffh,0,0f200h,0afh ; data RW, ring 3
dw 0ffffh,0,0fa00h,0afh ; code R, ring 3
dq 0e90000003001h + ((tss and 0xFFFFFF) shl 16) + ((tss and 0xFF000000) shl 32),tss shr 32 ; app tss

Bochs - OK
QEmu - restart (tripple fault??)

It shouldn't work. The documentation on syscall/sysret states that the destination selectors for sysret should be in ring 3. Other than that, it seems pretty meaningless to use syscall/sysret within ring 0.

BTW, did you setup the corresponding MSRs prior to your test? Did you use 0x48 prefix for sysret?

Yes, I did.

You should be able to syscall from any ring, however sysret will always try to return to ring 3. My memory manager runs in ring 1 and it uses syscall but the kernel uses iret to return to it

If you are going from ring0 to ring0, you should refactor your code and do direct function call - this is much quicker.

The GDT layout should be code/data/code/data as CS := selector_base and SS := selector_base + 8

AMD reference volume 2 & 3:

The processor assumes (but does not check) that the SYSCALL target CS has CPL=0 and the SYSRET target CS has CPL=3.

SYSCALL sets the CPL to 0, regardless of the values of bits 33–32 of the STAR register.

SYSRET sets the CPL to 3, regardless of the values of bits 49–48 of the star register. SYSRET can only be executed at CPL 0.

Sorry for disturbing.

cyr1x: thank's, my fault.

bluemoon: I was thinking about ring 0 only OS for app & kernel. Only as idea. It's quite interesting: no protection, cooperative multitasking, and so on = fast speed. Probably . Far call is fast, but fixed offset... I don't want to do so... Didn't want .

summersong wrote:Far call is fast, but fixed offset... I don't want to do so... Didn't want .

I was talking about near call, but anyway this does not necessary be fixed offset, you can do relocation, run time linking or "query near-call interface" with slower method like INT.