Różnica w ABI między funkcjami Linuksa x86_64 a syscalls

Question

Konwencja wywoływania funkcji x86_64 SysV ABI definiuje liczbę całkowitą 4, która ma być przekazana do rejestru rcx. Z drugiej strony, system ABI systemu Linux używa r10 w tym samym celu. Wszystkie pozostałe argumenty są przekazywane w tych samych rejestrach zarówno dla funkcji, jak i dla syscalls.

Prowadzi to do dziwnych rzeczy. Sprawdź, na przykład, realizacja mmap w glibc dla platformy x32 (dla których istnieje rozbieżność taka sama):

00432ce0 <__mmap>: 
    432ce0:  49 89 ca    mov %rcx,%r10 
    432ce3:  b8 09 00 00 40   mov $0x40000009,%eax 
    432ce8:  0f 05     syscall 

Więc rejestr są już na swoim miejscu, z wyjątkiem ruszamy rcx do r10.

Zastanawiam się, dlaczego nie zdefiniować ABI systemu operacyjnego tak, aby było takie samo jak wywołanie funkcji ABI, biorąc pod uwagę, że są one już tak podobne.

Answer 1

Celem jest zapewnienie szybszej metody wprowadzania Ring-0 w celu wykonania wywołania systemowego. Ma to być ulepszenie w stosunku do starej metody, która polegała na wywołaniu przerwania oprogramowania (int 0x80 w systemie Linux).

Jednym z powodów, dla których instrukcja jest szybsza, jest to, że nie zmienia ona pamięci, ani nawet nie zmienia rsp, aby wskazywać na stos jądra. W przeciwieństwie do przerwania programowego, w którym procesor jest zmuszony do umożliwienia systemowi operacyjnemu wznowienia działania bez wciskania czegokolwiek, dla tego polecenia CPU może przyjąć, że oprogramowanie wie, że coś tu się dzieje.

W szczególności syscall przechowuje dwie części stanu przestrzeni użytkownika w rejestrach. RIP do powrotu po wywołaniu jest przechowywany w rcx, a flagi są przechowywane w R11 (because RFLAGS is masked with a kernel-supplied value before entry to the kernel). Oznacza to, że oba te rejestry są przeplatane instrukcją.

Ponieważ są one clobbered, ABI syscall używa innego rejestru zamiast rcx, stąd użycie r10 dla czwartego argumentu.

r10 jest naturalnym wyborem, ponieważ in the x86-64 SystemV ABI nie jest wykorzystywany do przekazywania args funkcji, a funkcje nie trzeba zachować wartość swojego rozmówcy z r10. Tak więc funkcja opakowania syscall może mov %rcx, %r10 bez żadnego zapisu/przywrócenia. Nie byłoby to możliwe z żadnym innym rejestrem, dla systemów 6-arg i konwencji wywoływania funkcji SysV ABI.

---

BTW, zadzwoń system 32-bitowy ABI jest również dostępny z sysenter, który wymaga współpracy pomiędzy przestrzeni użytkownika i przestrzeni jądra, aby umożliwić powrót do przestrzeni użytkownika po sysenter. (tj. przechowywanie pewnego stanu w przestrzeni użytkownika przed uruchomieniem sysenter). Jest to wyższa wydajność niż int 0x80, ale jest niezręczna. Wciąż używa go glibc (przeskakując do kodu przestrzeni użytkownika na stronach vdso, które jądro zamienia w przestrzeń adresową każdego procesu).

AMD to syscall jest kolejnym podejściem do tego samego pomysłu, co wersja sysenter firmy Intela: zmniejszanie kosztów wejścia/wyjścia z jądra przez nieutrzymywanie absolutnie wszystkiego.

Answer 2

AMD's syscall clobbers rejestru rcx, w ten sposób używany jest r10.