This question already has an answer here:
Implementing Linux System Call using LKM
(1 answer)
Closed 6 years ago.
So I have seen a bunch of questions about adding system calls but I can't find any examples of one using an LKM that works. I have found resources like this: http://tldp.org/LDP/lkmpg/2.6/html/
This works, in theory, but doesnt compile. Can anyone point me towards a simple example for adding a hello world system call or something. Something like this: https://tssurya.wordpress.com/2014/08/19/adding-a-hello-world-system-call-to-linux-kernel-3-16-0/ that doesn't require me to recompile my kernel?
Generally, it's strongly recommended to not implement a whole new system call.
Rather, only implement a new ioctl and likely some new block or character devices.
For how to do that, it looks like there is another question/answer already: How do I use ioctl() to manipulate my kernel module?
I don't think you can do that with a module. The definitions of the syscall go into two places which cannot really be changed at runtime (as far as I know): syscall table (which assigns numbers per architecture) and syscalls include file (installed with kernel itself, not modules). (Or at least not without messing with code rewriting at runtime.)
You'll always need to recompile the kernel in that case. But if you want to have a quick update/try cycle, you could implement a syscall that's just a stub, passing a message to the right module if it's loaded. It would allow you to change the implementation, but not the signature.
Related
This question already has answers here:
How to create a lightweight C code sandbox?
(13 answers)
Closed 9 years ago.
I'm developing a platform similar to hackerrank.com where someone can submit C code, and then that code will be compiled, and run on my server, but I want to limit the C instruction set that a person will be able to execute on my server.
For example: limit the instruction set to I/O only.
My first approach was to parse the code and look for malicious code, but that is pretty naive because it can be easily overriden (shell code, obfuscation, etc..)
My second approach (the one I think it could work) is to remove all the "unnecessary" headers, and just leave stdio.h, math.h, stdlib.h, etc... just to name a few.
But then I thought that it might be possible to limit from gcc the instruction set of C, but after reading the man entry for gcc I couldn't find anything close to what I need, so I wonder if that's even possible.
If that's not possible, what could be a safe way to solve this problem? Other than getting rid of unnecessary libraries.
Thanks!
You could limit system calls using systrace, which is available on OpenBSD. I'm sure there's an equivalent for linux and other operating systems. This would allow you to restrict syscalls to file io only and not things like sockets and forking.
As a proof-of-concept, plus a handy paranoid tool, I'm writing an OpenBSD LKM that will connect to an IRC channel, and report when hooked syscalls are executed.
This is so I can essentially have a 'live' update of filesystem changes, user logons, etc., when I'm offsite but have internet access.
I've gotten as far as connecting the socket, but am stuck at trying to perform the equivalent of a getaddrinfo or even inet_addr call with a hardcoded address.
As these are userland functions, any attempts to use them will result in undefined references - fair enough. The trouble is, after a while of Googling and grep'ing the openbsd source, I cannot find any equivalent kernel functions to do this; the best recommendation has been to reimplement them in the module.
This means I need to also implement things like islower, isxdigit and isspace (and probably others as I progress), which gets a bit much to perform something so simple; is anyone aware of a workaround or alternative for this, or am I stuck c+p code from the net files?
This is definitely better done in userspace. Regardless, OpenBSD no longer supports kernel modules.
Not that you're working on this project anymore. I just wanted to answer so that this could be closed, and so that I could clarify how to use some stdlib functions in the kernel.
In response to this:
This means I need to also implement things like islower, isxdigit and isspace (and probably others as I progress), which gets a bit much to perform something so simple; is anyone aware of a workaround or alternative for this, or am I stuck c+p code from the net files?
Some C stdlib functions are available from libkern (see libkern(9)). Others, including many of the ctype functions like islower(), are available from libsa. To use these, you need something like:
#include <lib/libkern/libkern.h>
#include <lib/libsa/stand.h>
libsa contains a handful of headers (found in /usr/src/sys/lib/libsa/), so include each one you need.
I'm currently learning about operating systems the use of traps to facilitate system calls within the Linux kernel. I've located the table of the traps in traps.c and the implementation of many of the traps within entry.S.
However, I'm instructed to find an implementation of two system calls in the Linux kernel which utilize traps to implement a system call. Although I can find the definition of the traps themselves, I'm not sure what a "call" to one of these traps within the kernel would look like. Therefore, I'm struggling to find an example of this behavior.
Before anyone asks, yes, this is homework.
As a note, I'm using Github to browse the kernel source, since kernel.org is down:
https://github.com/torvalds/linux/
For the x86 architecture the SYCALL_VECTOR (0x80) interrupt is used only for 32bit kernels. You can see the interrupt vector layout in arch/x86/include/asm/irq_vectors.h. The trap_init() function from traps.c is the one that sets the trap handler defined in entry_32.S:
set_system_trap_gate(SYSCALL_VECTOR, &system_call);
For the 64bit kernels, the new SYSENTER (Intel) or SYSCALL (AMD) intructions are used for performance reasons. The syscall_init() function from arch/x86/kernel/cpu/common.c sets up the "handler" defined in entry_64.S and bearing the same name (system_call).
For the user-space perspetive you might want to take a look at this page (a bit outdated for the function/file names).
I'm instructed to find an implementation of two system calls in the Linux kernel which utilize traps to implement a system call
Every system call utilizes a trap (interrupt 0x80 if I recall correctly) so the "kernel" bit will be turned on in PSW, and privileged operations will be available to the processor.
As you mentioned the system calls are specified in entry.S under sys_call_table: and they all start with the "sys" prefix.
you can find the system call function header in: include/linux/syscalls.h, you can find it here:
http://lxr.linux.no/#linux+v3.0.4/include/linux/syscalls.h
Use lxr (as the comment above have already mentioned) in general in order to browse the source code.
Anyhow, the function are implemented using the SYSCALL_DEFINE1 or othe versions of the macro, see
http://lxr.linux.no/#linux+v3.0.4/kernel/sys.c
If you're looking for an actual system call, not an implementation of a system call, maybe you want to check some C libraries. Why would a kernel include a system call? (I'm not talking about a system call implementation, I'm talking about e.g. an actual chdir call for example. There is a chdir system call, which is a request for changing the directory and there is a chdir system call implementation which actually changes it and must be somewhere in the kernel). Ok, maybe some kernels do include some syscalls too but that's another story :)
Anyway, if I get your question right, you're not looking for an implementation but an actual call. GNU libc is too complicated for me, but you can try browsing the dietlibc sources. Some examples:
chdir.S
syscalls.h
How does one call Go code in C from threads that weren't created by Go?
What do I assign to a C function pointer such that threads not created by Go can call that pointer and enter into Go code?
Update0
I don't want to use SWIG.
The callbacks will be coming from threads Go hasn't seen before. Neither cgo/life nor anything in pkg/runtime demonstrates this behaviour AFAICT.
You can do this, but the solution is relatively slow (about 22µs per call on my machine).
The answer is for the C code to use C thread primitives to communicate with another goroutine that will actually run the callback.
I have created a Go package that provides this functionality: rog-go.googlecode.com/hg/exp/callback.
There is an example package demonstrating its use here. The example demonstrates a call back to an arbitrary Go closure from a thread created outside of the Go runtime. Another example is here. This demonstrates a typical C callback interface and layers a Go callback on top of it.
To try out the first example:
goinstall rog-go.googlecode.com/hg/exp/example/looper
cd $GOROOT/src/pkg/rog-go.googlecode.com/hg/exp/example/looper
gotest
To try out the second example:
goinstall rog-go.googlecode.com/hg/exp/example/event
cd $GOROOT/src/pkg/rog-go.googlecode.com/hg/exp/example/event
gotest
Both examples assume that pthreads are available. Of course, this is just a stop-gap measure until cgo is fixed, but the technique for calling arbitrary Go closures in a C callback will be applicable even then.
Here is the documentation for the callback package:
PACKAGE
package callback
import "rog-go.googlecode.com/hg/exp/callback"
VARIABLES
var Func = callbackFunc
Func holds a pointer to the C callback function.
When called, it calls the provided function f in a
a Go context with the given argument.
It can be used by first converting it to a function pointer
and then calling from C.
Here is an example that sets up the callback function:
//static void (*callback)(void (*f)(void*), void *arg);
//void setCallback(void *c){
// callback = c;
//}
import "C"
import "rog-go.googlecode.com/hg/exp/callback"
func init() {
C.setCallback(callback.Func)
}
I'll assume you mean from C code compiled with gcc?
IIRC, this either can't be done or can't easily be done using 6g+cgo and friends. Go uses a different calling convention (as well as the segmented stacks and such).
However, you can write C code for [685]c (or even [685]a) and call into go easily using package·function() (you can even call methods IIRC). See the Source of the runtime package for examples.
Update:
Coming back to this question after the update, and giving it some more thought. This can't be done in a standard fashion using 6c or cgo. Especially because the threads are not started by the go runtime, the current implementation would fail. The scheduler would suddenly have a thread under its control that it does not know about; additionally, that thread would be missing some thread-local variables the go runtime uses for managing stacks and some other things. Also, if the go function returns a value (or several) the C code can't access it on the currently supported platforms, as go returns values on the stack (you could access them with assembly though). With these things in mind, I do believe you could still do this using channels. It would require your C code to be a little too intimate with the inner workings of the go runtime, but it would work for a given implementation. While using channels may not be the solution you're looking for, it could possibly fit more nicely with the concepts of Go than callbacks. If your C code reimplemented at least the sending methods in The channel implementation (that code is written for 6c, so it would have to be adapted for gcc most likely, and it calls the go runtime, which we've determined can't be done from a non-go thread), you should be able to lock the channel and push a value to it. The go scheduler can continue to manage it's own threads, but now it can receive data from other threads started in C.
Admittedly, it's a hack; I haven't looked close enough, but it would probably take a few other hacks to get it working (I believe the channels themselves maintain a list of the goroutines that are waiting on them [EDIT: confirmed: runtime·ready(gp);], so you'd need something in your go code to wake up the receiving channel or to warranty the go code won't receive on the channel until you've already pushed a value). However, I can't see any reason this can't work, whereas there are definite reasons that running code generated by 6g on a thread created in C can't.
My original answer still holds though: barring an addition to the language or runtime, this can't yet be done the way you'd like (I'd love to be proven wrong here).
You can find a real-world application of rog's callback package in these bindings for the PortAudio audio I/O library: http://code.google.com/p/portaudio-go/. Might make it easier to understand..
(Thanks for implementing that, rog. It's just what I needed!)
I have a function which is called explicitly by 4 other functions in my code base. Then in turn each of these functions is called by at least 10 other functions throughout my code. I know that I could, by hand, trace one of these function calls to the main function of my program (which has 30 function calls) but it seems like this would be a better job for the computer. I just want to know which of the functions in main() is calling this buried function.
Does anyone know of any software that could help?
Also, using a debugger is out of the question. That would have been too easy. The software only runs on a hand held device.
doxygen, correctly configured, is able to output an HTML document with navigable caller list and called-by list for every function in your code. You can generate call graphs as well.
Comment it out (or better, comment out its prototype) and try to compile your program. You should see, where it is referenced.
If your platform has an API to capture backtraces, I would just instrument up the function to use those and log them to a file for later analysis. There's no guarantee that this will find all callers (or callers-of-...-of-callers), but if you exercise all of the programs features while logging like this, you should find "most" of them. For relatively simple programs, it is possible to find all callers this way.
Alternatively, many sampling tools can get you this information.
However, I have a suspicion that you may be on a platform that doesn't have a lot of these features, so a static source-analysis tool (like mouviciel suggested) is likely your best option. Assuming that you can make it work for you, this has the added benefit that it should find all callers, not just most of them.
http://cscope.sourceforge.net/ I think this also can be useful.
I second mouviciel's suggestion of using doxygen for getting this info. The downside is that doxygen is working on the source code. You can only see what functions CAN POTENTIALLY call your function, not the ones that are ACTUALLY CALLING your function. If you are using Linux and you can change the source code of the function in question, you can obtain this info using the backtrace() and the backtrace_symbols() functions.