Live data from Hacker News

Kernel module for advanced rickrolling replaces open() call

github.com

61–67 of 67 posts

Re: Kernel module for advanced rickrolling replaces open() call

#62
post #59

Earlier quoted context omitted.

Doesn't pretty much everything call into libc to open() things rather than invoke the syscall directly?

No. Assembly code invokes kernel syscalls by invoking an interrupt or using a syscall opcode. No libc or function calls involved, so LD_PRELOAD can't hook in. You might even have several libc's in your system. You might have a uClibc + Busybox based initrd and a full glibc based root system. Btw. how does LD_PRELOAD act together static binaries?

I know apps can invoke kernel syscalls directly, and I'm sure you could name a handful of apps that do this all time. But are you really doing that in your mp3 player?

Re: Kernel module for advanced rickrolling replaces open() call

#63
post #59

Earlier quoted context omitted.

Doesn't pretty much everything call into libc to open() things rather than invoke the syscall directly?

No. Assembly code invokes kernel syscalls by invoking an interrupt or using a syscall opcode. No libc or function calls involved, so LD_PRELOAD can't hook in. You might even have several libc's in your system. You might have a uClibc + Busybox based initrd and a full glibc based root system. Btw. how does LD_PRELOAD act together static binaries?

Since static binaries don't use shared libraries, LD_PRELOAD has no effect - it is the same as with assembly code you mentioned.

Re: Kernel module for advanced rickrolling replaces open() call

#64
post #58

Earlier quoted context omitted.

You should never ever admit that you didn't think of security when writing code, especially in the kernel space :) I think that instead of the strlen pull request you accepted, you should use getname/strncpy_from_user like the open() syscall does instead of strlen+memcpy. Also, while you're here, could you explain what is the purpose of disabling memory write protection? Is it to allow writing to the syscall table? Y…

> You should never ever admit that you didn't think of security when writing code For a joke weekend project that you never intended anyone to see / use seriously? Sorry, no. I would never waste time making something secure that I did for funzies that I'll likely never touch again. If I happen to come across or realize a security issue as I'm writing it I might make a comment there in the source or in the README. Oth…

Did you notice the smiley at the end of that line? I intended that to mean that I'm not really serious.

Re: Kernel module for advanced rickrolling replaces open() call

#66

Earlier quoted context omitted.

Section 2 of the unix manual is for syscalls. Section 3 is for C library functions. http://en.wikipedia.org/wiki/Man_page#Manual_sections If libc implements it, then it is by definition in section 3. EDIT: (signing out of this sub-thread)

Sorry, you're just wrong. Have you ever called a system call by hand using assembly? Have you ever looked at glibc's source? Habe you ever looked at the kernel's close() syscall?

libc implements a function called open. Its documentation appears in section 3 of the UNIX manual. Because of that, we call it open(3). Linux implements a system call called open. Its documentation appears in section 2 of the UNIX manual. Because of that, we call it open(2). From assembly, you manually call open(2). From a C program linked against libc, you typically open(3). open(3) can be hooked, because it's just a regular function. open(2) is not a function, and so cannot be hooked like a function.
Post reply on HN