Change linux system call number

Question

I wanted to create my own native kernel with another syscall table. (same system calls, but in different positions / numbers)

I worked on kernel 3.2.29.

Changing the kernel was pretty simple:

1) syscall position change in arch / x86 / kernel / syscall_table_32.S

2) change the syscall macro number in arch / x86 / include / asm / unistd_32.h

3) compilation and installation of a new kernel

I switched system calls around: sys_open took the place and sys_read number, and vice versa.

I decided that if I compiled glibc with modified kernel headers, I might have a working system, but, unfortunately, this was not enough and my system would not boot.

Am I missing something? What else do I need to do to have a running system?

---

I have taken the following steps:

1) creating and installing a kernel as described in my question

2) extracting new kernel headers using make headers_install INSTALL_HDR_PATH=[path]

3) building glibc with the parameter --with-headers=[path/include]

4) I used live cd to access the file system from the outside to install a new glibc using make install install_root=[the original file system] (so that the system does not interrupt during installation)

I hope the new glibc was created correctly, but I'm not sure.

After that, when the system boots up, loading stops on the shell screen (initrafms): I think I need to rebuild initrd , but how to compile it according to the new syscall table?

Answer 1

You will have to rebuild everything. Even if all of your binaries are dynamically linked, it is possible that the old system calls were embedded in the binary, because many of the C functions are just return syscall(__NR_somecall,...) .

You can do it manually, but it can be difficult to keep straightforward tools unless you use a cross-compiled toolchain such as buildroot, native or similar. Choose the option that suits you (I prefer Aboriginal Rob Landley - http://landley.net/aboriginal/ )

Then, so that your initrd simply extends the old one using {z, bz, xz} cat oldinit.rd | Cpio -id; rm oldinit.rd. Replace the old kernel modules, libs and binaries with the new one and cpio and compile it (cpio needs the -H newc option) ... or now you can rebuild your kernel and point initramfs to this directory, but we don’t recommend that if your initrd may need to change frequently, for example, if, for example, you tested the entire new syscall structure and need to debug a lot.

Answer 2

Knocking down system call numbers will really hurt. You will at least need to rebuild all the statically linked binaries on your system and initrd (if you use them).

Answer 3

You did not say at what point the download failed, but even if the kernel appears, it is likely that critical programs contained in a compressed ramdisk initrd will fail because they have the original hard-coded system call numbers. You will also need to rebuild and repackage them.

You can first replace init with a static program like hello-world to make sure your kernel can support user space at all; then take a look at the details regarding matching the complexity of today's linux user space.

Answer 4

you had to learn to read the mess of the pansy cake and show us what panicked panache is. Without this information, people are unlikely to help you or provide you with a useful suggestion.