Create an account

Very important

  • To access the important data of the forums, you must be active in each forum and especially in the leaks and database leaks section, send data and after sending the data and activity, data and important content will be opened and visible for you.
  • You will only see chat messages from people who are at or below your level.
  • More than 500,000 database leaks and millions of account leaks are waiting for you, so access and view with more activity.
  • Many important data are inactive and inaccessible for you, so open them with activity. (This will be done automatically)


Thread Rating:
  • 487 Vote(s) - 3.46 Average
  • 1
  • 2
  • 3
  • 4
  • 5
What is the type of system call arguments on Linux?

#1
I want to write a generic function that does a system call. Something like

long my_syscall2(long number, long arg1, long arg2);

I want it to be as portable as possible. The implementation is obviously different for all architectures. Does the signature of the function also need to be different? Can I use `long` or should I use something else?

Here are the possible solutions that I found:

- The kernel uses some [dark magic][1]: (__SYSCALL_DEFINEx calls __SC_LONG to get the type, __SC_LONG contains magic). I heard somewhere that types in user space aren't always the same as in kernel space, so I don't know if I can use it.
- musl-libc [uses long for all architectures that it supports except x32][2]: (defined in [arch]/syscall_arch.h).
- I could find documentation for all processor architectures and compilers that I want to support, look up register sizes and integer types sizes and pick any integer type that has the same size as registers.

So I guess the question is "Is there some rule that says 'type of system call arguments are always `long` with some exceptions like x32' or do I need to look up documentation for every architecture and compiler?"

**Edit:** I know that some system calls take pointers and other types as parameters. I want to write generic functions that can call any system call, with generic parameter types. These generic parameter types should be big enough to hold any of the actual parameter types. I know it's possible because [syscall()][3] function exists.

**Edit2:** Here is another partial solution to this problem.

Implementations of these functions currently look like this:

static __inline long my_syscall2(long number, long arg1, long arg2)
{
unsigned long ret;
__asm__ __volatile__ ("syscall" : "=a"(ret) : "a"(number), "D"(arg1), "S"(arg2)
: "rcx", "r11", "memory");
return ret;
}

The interesting part is `"=a"(ret)`, this means that syscall return value that is stored in register `a` should be saved into variable `ret`. Instead of writing a function that creates local variable, makes syscall, saves its return value into the variable and returns the variable I could write a macro that makes syscall and stores the result into a variable provided by caller. It would look like this:

#define my_syscall2(RET, NUMBER, ARG1, ARG2) \
__asm__ __volatile__ ("syscall" : "=a"(RET) : "a"(NUMBER), "D"(ARG1), "S"(ARG2) \
: "rcx", "r11", "memory");

And it would be used like this:

long result;
void * arg1;
int arg2;
my_syscall2(result, <syscall number>, arg1, arg2);

This way I don't need to know register size and integer type that is big enough to hold a value of the register.


[1]:

[To see links please register here]

[2]:

[To see links please register here]

[3]:

[To see links please register here]

Reply

#2
I suggest that you use the existing [syscall][1] system call, rather than try to write one on your own. It seems to do exactly what you want. Look at the "Architecture-specific requirements" section of the manual page for a discussion of the valid questions you raised.


[1]:

[To see links please register here]

Reply

#3
System call arguments are passed in registers. There size is thus limited to the size of a CPU register. That is, 32 bit on a 32 bit architecture, 64 bit on a 64 bit architecture. Floating point numbers cannot be passed to the kernel this way. Traditionally the kernel does not use floating point instructions (and may not be able to as the FPU state is usually not saved on entry to the kernel) so try to avoid floating point numbers in your own system calls.

System calls that use arguments of smaller types zero or sign extend them. System calls that use larger argument types may split the argument into multiple registers.

System calls (like `mmap()`) that have to many parameters may be implemented by passing the parameters as a pointer to a structure, but this has a measurable performance overhead, so avoid designing system calls with more than five parameters.

At the end of the day, use the types appropriate for the value you want to send. Let the libc deal with putting the data in the right places.
Reply

#4
There's no general solution. If you want to make your code ultra-multiarch you can just do something like that:

#if ARCH_WITH_32BIT_REGS
typedef uint32_t reg_size_int_t;
#elif ARCH_WITH_64BIT_REGS
typedef uint64_t reg_size_int_t;
#elif ARCH_WITH_16BIT_REGS
typedef uint16_t reg_size_int_t;
....
#endif

reg_size_int_t syscall_1( reg_size_t nr, reg_size_t arg0);
...

But for most common-used architectures size of register is equal to long.
Reply



Forum Jump:


Users browsing this thread:
1 Guest(s)

©0Day  2016 - 2023 | All Rights Reserved.  Made with    for the community. Connected through