Enabling and disabling system calls - Linux

This is a discussion on Enabling and disabling system calls - Linux ; Hello, In my current research about how to write system calls I found myself stuck again. After reading a little bit about the kernel, and the actual code I found out how to make the system calls (or at least ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Enabling and disabling system calls

  1. Enabling and disabling system calls

    Hello,

    In my current research about how to write system calls I found myself
    stuck again. After reading a little bit about the kernel, and the
    actual code I found out how to make the system calls (or at least one
    way to do it).

    What I do is that I edit the syscall_table.S, located at
    arch/i386/kernel (all paths I'm going to say is relative to the kernel
    root), and write ``.long sys_mysyscall'' at the end of the table. I then
    create a mysyscall.c on that same directory, where I define my system
    call. I add it to the Makefile on the obj-y variable. After that I add
    __NR_mysycall defined as a new number and I increment NR_syscalls on
    unistd.h. Then I compile the kernel and my system call seems to work.

    I understand how to create a new entry to Kconfig that would make my
    system call be compiled into the kernel or not. I know even how to make
    the Makefile not compile the mysyscall.c if the option is not selected.
    But my problem is that the system call is still declared on the
    syscall_table.S file. Is there another place to declare my system call?
    Am I missing something?

    Thank you for your attention,
    Rafael

  2. Re: Enabling and disabling system calls

    Rafael Almeida wrote:
    > I understand how to create a new entry to Kconfig that would make my
    > system call be compiled into the kernel or not. I know even how to make
    > the Makefile not compile the mysyscall.c if the option is not selected.


    Okay, so you presumably have some CONFIG_MYSYSCALL symbol, right? In
    the Makefile, instead of using obj-y, you use obj-$(CONFIG_MYSYSCALL).

    > But my problem is that the system call is still declared on the
    > syscall_table.S file.


    You can use #ifdef CONFIG_MYSYSCALL to conditionalize the definition of
    _NR_syscall, and conditionally define the table entry.

    Is that what you are asking? Or are you asking how the compiler in user
    space can see a declaration of the system call so that an application
    can be compiled and linked to use it?

    > Am I missing something?


    Yes, that people should not be randomly adding system calls to the
    kernel. It's not easy to do for a good reason.

    There is no completely reliable way for a user space application to
    tell whether it's talking to the same nonstandard system call that it
    /thinks/ it is talking to.

    In the next version of the kernel, the number that you picked might be
    taken over. So now your user-space application has to detect which
    kernel it is running on and use different numbers.

    Another issue is that the assembly language sycall_table is machine
    dependent. You have only added your system call for one architecture.
    If the kernel is compiled for a different architecture, your system
    call won't be wired in.

    So it's best not to extend the kernel this way---unless you take on the
    chore of maintaining your own Linux distribution. Instead, consider,
    for instance, making a character device. Then you can have your own
    ioctls which easily port from one kernel version to the next without
    conflicting with anything and having to be renumbered. The kernel
    doesn't even have to be recompiled, since your device can build outside
    of the tree as a loadable module.


  3. Re: Enabling and disabling system calls

    On Tue, 30 Oct 2006, Kaz Kylheku wrote:

    > > But my problem is that the system call is still declared on the
    > > syscall_table.S file.

    >
    > You can use #ifdef CONFIG_MYSYSCALL to conditionalize the definition of
    > _NR_syscall, and conditionally define the table entry.
    >
    > Is that what you are asking? Or are you asking how the compiler in user
    > space can see a declaration of the system call so that an application
    > can be compiled and linked to use it?


    I thought it wasn't possible to add #ifdefs on the table entry because
    it's assembly code, so it wouldn't be passed through the cpp.

    As I understand there's a macro (ENOSYS) that will let the user space
    code to know whether the system call is implemented or not. So, as long
    as the user space code checks that it should be ok.

    > Yes, that people should not be randomly adding system calls to the
    > kernel. It's not easy to do for a good reason.
    >
    > There is no completely reliable way for a user space application to
    > tell whether it's talking to the same nonstandard system call that it
    > /thinks/ it is talking to.
    >
    > In the next version of the kernel, the number that you picked might be
    > taken over. So now your user-space application has to detect which
    > kernel it is running on and use different numbers.
    >
    > Another issue is that the assembly language sycall_table is machine
    > dependent. You have only added your system call for one architecture.
    > If the kernel is compiled for a different architecture, your system
    > call won't be wired in.
    >
    > So it's best not to extend the kernel this way---unless you take on the
    > chore of maintaining your own Linux distribution. Instead, consider,
    > for instance, making a character device. Then you can have your own
    > ioctls which easily port from one kernel version to the next without
    > conflicting with anything and having to be renumbered. The kernel
    > doesn't even have to be recompiled, since your device can build outside
    > of the tree as a loadable module.


    Yes, you are right. I'm not sure on how to make a character device just
    yet, but from what you said that's clearly the best way to extend the
    kernel. However, what I'm trying to achive is a better understanding of
    the kernel code as a whole. So I started a little project for my OS class
    where me and my friends try to make new system calls that will work much
    like http://sandbox.sourceforge.net. We'll have to modify some of the
    kernel's current system calls and a little of its structure. Therefore I
    don't think a character device would be enough to achive that, and a
    kernel patch is inevitable.

    This is more of a particular insight, but I'm finding this class really
    nice, and I intend to help or even develop real projects in the future.
    So I find that the thing I'm doing right now will give me good knowledge
    of how the kernel works internally, as I'll be modifying the existing code
    and not simple writting only new code to extend it (which is probably the
    best idea when you want to make something new and not only learn).


    Thank you for your help,
    Rafael

  4. Re: Enabling and disabling system calls

    Rafael Cunha de Almeida wrote:
    > I thought it wasn't possible to add #ifdefs on the table entry because
    > it's assembly code, so it wouldn't be passed through the cpp.


    It is passed through the preprocessor. That is how the ENTRY() macro
    is expanded in arch/i386/kernel/syscall_table.S. (I'm looking at
    2.6.17). In many other .S files, there are even preprocessing
    directives such as #include.

    If you want to add a test for a CONFIG_* symbol in a .S file, don't
    forget to add #include at the top.

    > As I understand there's a macro (ENOSYS) that will let the user space
    > code to know whether the system call is implemented or not. So, as long
    > as the user space code checks that it should be ok.


    That's the good case. However, I was thinking of the case when there is
    a system call implemented, but is not the intended one.

    User space is blindly calling a function by its position in a table.

    Someone could compile the program for a kernel which has that system
    call number, but it's not your system call.


+ Reply to Thread