41–50 of 67 posts
Earlier quoted context omitted.
Maybe because the author prefers to play with kernel. Other option is create a wrapper library and enforce it's usage with LD_PRELOAD.
Using LD_PRELOAD you cannot hook a syscall like open().
Earlier quoted context omitted.
BTW: write_cr0(read_cr0() | 0x10000) is a absolute no-go. It's a nice and funny kernel module but it dooms the kernel's security.
If we could take CR0 et al manipulations away from module authors, we'd do it long ago. Sigh...
Earlier quoted context omitted.
Using LD_PRELOAD you cannot hook a syscall like open().
Doesn't pretty much everything call into libc to open() things rather than invoke the syscall directly?
Earlier quoted context omitted.
[deleted]
Eh, the code does look for the string terminator. It calls strlen, which indexes the char* until it finds a NULL byte. If the string doesn't have a NULL byte then strlen will happily continue reading past the boundary until it either segfaults or finds a NULL byte.
Earlier quoted context omitted.
Doesn't pretty much everything call into libc to open() things rather than invoke the syscall directly?
With LD_PRELOAD you can hook any _function_ call. A syscall is something different. It depends how the syscall wrapper within the libc is coded. Some can be hooked...
This is great, for the fun of course, but also and mainly because it is a simple example of a working kernel module, which is not something one can see very often.
What are you talking about? The linux sources are full of simple examples of working kernel modules.
Earlier quoted context omitted.
With LD_PRELOAD you can hook any _function_ call. A syscall is something different. It depends how the syscall wrapper within the libc is coded. Some can be hooked...
But open(3) is a function call, so it can be hooked.
Earlier quoted context omitted.
But open(3) is a function call, so it can be hooked.
It's open(2). Yes, here on my x86_64 it can be hooked. But I've seen lots of setups where this was not doable. As I said it depends how the libc's wrapper is written.
So an app calls the open() function. This results in an unresolved symbol which the run-time linker matches up with the open() exported by glibc. glibc then does the open() syscall.
Earlier quoted context omitted.
It's open(2). Yes, here on my x86_64 it can be hooked. But I've seen lots of setups where this was not doable. As I said it depends how the libc's wrapper is written.
On Linux, there's typically both an open(3) and an open(2). The former is implemented by glibc and calls the latter which is implemented by the kernel. So an app calls the open() function. This results in an unresolved symbol which the run-time linker matches up with the open() exported by glibc. glibc then does the open() syscall.
Earlier quoted context omitted.
On Linux, there's typically both an open(3) and an open(2). The former is implemented by glibc and calls the latter which is implemented by the kernel. So an app calls the open() function. This results in an unresolved symbol which the run-time linker matches up with the open() exported by glibc. glibc then does the open() syscall.
open(2) is the wrapper within the libc. There is no open(3) on Linux.
If libc implements it, then it is by definition in section 3.
EDIT: (signing out of this sub-thread)