How can we implement the system call using sysenter/syscall directly in x86 Linux? Can anybody provide help? It would be even better if you can also show the code for amd64 platform.
I know in x86, we can use
__asm__(
" movl $1, %eax \n"
" movl $0, %ebx \n"
" call *%gs:0x10 \n"
);
to route to sysenter indirectly.
But how can we code using sysenter/syscall directly to issue a system call?
I find some material http://damocles.blogbus.com/tag/sysenter/ . But still find it difficult to figure out.
First of all, you can't safely use GNU C Basic
asm("");
syntax for this (without input/output/clobber constraints). You need Extended asm to tell the compiler about registers you modify. See the inline asm in the GNU C manual and the inline-assembly tag wiki for links to other guides for details on what things like"D"(1)
means as part of anasm()
statement.I'm going to show you how to execute system calls by writing a program that writes
Hello World!
to standard output by using thewrite()
system call. Here's the source of the program without an implementation of the actual system call :You can see that I named my custom system call function as
my_write
in order to avoid name clashes with the "normal"write
, provided by libc. The rest of this answer contains the source ofmy_write
for i386 and amd64.i386
System calls in i386 Linux are implemented using the 128th interrupt vector, e.g. by calling
int 0x80
in your assembly code, having set the parameters accordingly beforehand, of course. It is possible to do the same viaSYSENTER
, but actually executing this instruction is achieved by the VDSO virtually mapped to each running process. SinceSYSENTER
was never meant as a direct replacement of theint 0x80
API, it's never directly executed by userland applications - instead, when an application needs to access some kernel code, it calls the virtually mapped routine in the VDSO (that's what thecall *%gs:0x10
in your code is for), which contains all the code supporting theSYSENTER
instruction. There's quite a lot of it because of how the instruction actually works.If you want to read more about this, have a look at this link. It contains a fairly brief overview of the techniques applied in the kernel and the VDSO. See also The Definitive Guide to (x86) Linux System Calls - some system calls like
getpid
andclock_gettime
are so simple the kernel can export code + data that runs in user-space so the VDSO never needs to enter the kernel, making it much faster even thansysenter
could be.It's much easier to use the slower
int $0x80
to invoke the 32-bit ABI.As you can see, using the
int 0x80
API is relatively simple. The number of the syscall goes to theeax
register, while all the parameters needed for the syscall go into respectivelyebx
,ecx
,edx
,esi
,edi
, andebp
. System call numbers can be obtained by reading the file/usr/include/asm/unistd_32.h
.Prototypes and descriptions of the functions are available in the 2nd section of the manual, so in this case
write(2)
.The kernel saves/restores all the registers (except EAX) so we can use them as input-only operands to the inline asm. See What are the calling conventions for UNIX & Linux system calls on i386 and x86-64
Keep in mind that the clobber list also contains the
memory
parameter, which means that the instruction listed in the instruction list references memory (via thebuf
parameter). (A pointer input to inline asm does not imply that the pointed-to memory is also an input. See How can I indicate that the memory *pointed* to by an inline ASM argument may be used?)amd64
Things look different on the AMD64 architecture which sports a new instruction called
SYSCALL
. It is very different from the originalSYSENTER
instruction, and definitely much easier to use from userland applications - it really resembles a normalCALL
, actually, and adapting the oldint 0x80
to the newSYSCALL
is pretty much trivial. (Except it uses RCX and R11 instead of the kernel stack to save the user-space RIP and RFLAGS so the kernel knows where to return).In this case, the number of the system call is still passed in the register
rax
, but the registers used to hold the arguments now nearly match the function calling convention:rdi
,rsi
,rdx
,r10
,r8
andr9
in that order. (syscall
itself destroysrcx
sor10
is used instead ofrcx
, letting libc wrapper functions just usemov r10, rcx
/syscall
.)(See it compile on Godbolt)
Do notice how practically the only thing that needed changing were the register names, and the actual instruction used for making the call. This is mostly thanks to the input/output lists provided by gcc's extended inline assembly syntax, which automagically provides appropriate move instructions needed for executing the instruction list.
The
"0"(callnum)
matching constraint could be written as"a"
because operand 0 (the"=a"(ret)
output) only has one register to pick from; we know it will pick EAX. Use whichever you find more clear.Note that non-Linux OSes, like MacOS, use different call numbers. And even different arg-passing conventions for 32-bit.
Explicit register variables
Just for completeness, I want to provide an example using GCC explicit register variables.
This mechanism has the following advantages:
r8
,r9
andr10
which are used for system call arguments: How to specify register constraints on the Intel x86_64 register r8 to r15 in GCC inline assembly?S -> rsi
Register variables are used for example in glibc 2.29, see:
sysdeps/unix/sysv/linux/x86_64/sysdep.h
.Also note that other archs such as ARM have dropped the single letter mnemonics completely, and register variables are the only way to do it it seems, see for example: How to specify an individual register as constraint in ARM GCC inline assembly?
main_reg.c
GitHub upstream.
Compile and run:
Output
For comparison, the following analogous to How to invoke a system call via sysenter in inline assembly? produces equivalent assembly:
main_constraint.c
GitHub upstream.
Disassembly of both with:
is almost identical, here is the
main_reg.c
one:So we see that GCC inlined those tiny syscall functions as would be desired.
my_write
andmy_exit
are the same for both, but_start
inmain_constraint.c
is slightly different:It is interesting to observe that in this case GCC found a slightly shorter equivalent encoding by picking:
to set the
fd
to1
, which equals the1
from the syscall number, rather than a more direct:For an in-depth discussion of the calling conventions, see also: What are the calling conventions for UNIX & Linux system calls on i386 and x86-64
Tested in Ubuntu 18.10, GCC 8.2.0.