I am beginning with XDP and BPF maps.
I understand that to access a BPF map from userspace, we use bpf_* syscalls. For example, bpf_map_lookup_elem() is used to lookup an element of a BPF map in the userspace program. However, I noticed that the same syscalls are also used to access maps in the XDP programs loaded on the kernel (ref. here).
I assumed such programs should be running in the kernel space, and hence is there some other way these BPF maps should be accessed from the kernel space? Or is the XDP loaded program also part of the userspace but only running within the kernel?
To lookup map elements from userspace, you should use the bpf(2) syscall, with command BPF_MAP_LOOKUP_ELEM. The main userspace library for BPF does expose this syscall command as bpf_map_lookup_elem().
To lookup map elements from BPF programs, you indeed need to use the bpf_map_lookup_elem BPF helper. In a nutshell, BPF helpers are kernel functions you can call from the BPF bytecode with instruction call.
Despite having the same name, they are however different things: the first is a library function, while the second is a BPF helper.
Related
Is it possible to write an eBPF program, that can dynamically call an external library? I.e. assume that this specific library is present on the host that runs the eBPF code.
Right now I don't care if the program is passing verification, but rather if it is possible to express this in the bytecode. It should be assumed that the external function is not embedded in the ELF binary.
No, this is not possible at the moment.
Once loaded and attached, eBPF programs can call:
eBPF functions from the same program (eBPF-to-eBPF function calls)
other eBPF programs, under certain conditions, through tail calls
other eBPF programs of type BPF_PROG_TYPE_EXT
kernel function helpers (library of functions defined in the kernel)
random kernel functions, if they are explicitly marked as callable (should be in Linux 5.13)
It cannot call functions from user space libraries.
I'm using User Mode Linux and I'm redefining some I/O memory related functions. The idea it's that any function that is called from a list of our own kernel modules will be handled differently from the rest of the modules.
Is that possible to know whichy module is calling (kernel module name would be enough) a function like writel?
Libunwind defines a portable and efficient C programming interface (API) to determine the call-chain of a program (http://savannah.nongnu.org/projects/libunwind).
/proc/modules file displays a list of all modules loaded into the kernel along with their sizes and memory offsets.
We use Linux system calls like fork(), pthread(), signal() and so on in C or C++ programs and compile the program to generate executable file (a.out). Now my doubt is whether the file a.out contain the object code of all linux system calls used, or whether the executable contain only the calls to system functions and the system call functions are linked during runtime? Suppose if I move my a.out file to some other Linux operating system which implements system calls in different syntax and try to compile it there will it work?
My doubt is whether system call function definitions part of a.out file?
User space binaries don't contain implementations of system calls. That would mean that any user could inject any code into kernel and take over system.
Instead they need to switch to kernel mode, by using processor interrupt or special instruction. Then processor can execute system call implementation from the kernel.
User space library, such as libc, is usually used, which provides stubs, which convert arguments of a syscall to a proper protocol and trigger jump to kernel mode. It is usually linked dynamically, so these stubs also don't appear in executable file.
I developed a kernel module and some functions on it. Now i need to develop a program in the user space and call some functions which are in the kernel module.
I also need to access some global variable that are in the kernel module on my program at the user space.
There is complete overview of linux-kernel module and user-space program interacting http://wiki.tldp.org/kernel_user_space_howto "Kernel Space, User Space Interfaces" by Ariane Keller (it is from 2008-09-28, but about 2.6 kernels; only major new way is relayfs)
No ordinary function call from user space to kernel space is listed, only syscall (adding new syscall is not easy) and upcall (call in inverse direction).
One of easiest interface is ioctl; but you can't start to use ioctl before creating procfs, sysfs or similiar file.
Other is sysctl; but sysctl is more eligible to reading/writing to global variable. (It is hard to pass several parameters via sysctl interface).
You seem to be missing the point of kernel and userland separation. If your user program could modify data inside the kernel directly, that would quickly lead to disaster.
There's only one conventional way for a user program to explicitly request services from the kernel - make a system call.
There are also traps and some Linux-specific userland-kernel communication mechanisms, but those are not relevant here.
As other posters have mentioned, there is a clear distinction between kernel and user space. So no you can't call a kernel function directly from user space. I think the easiest way to send messages between userspace and kernel space is via netlink sockets. A netlink socket allows you to easily pass arbitrary data structures between user level and kernel level.
Yes ioctl, system calls are viable alternatives, they are not as flexible as the netlink socket for passing arbitrary information.
You'll need to install a new kernel to make use of the new call unless you already have some mechanism to update the kernel ... http://www.cyberciti.biz/tips/how-to-patch-running-linux-kernel.html
What is /proc/ksyms and /proc/kallsyms, and why is it mapped into a processes address space? What purpose does it serve? Is it used in context switching of the kernel during a system call?
The Solaris manpage for ksyms(7d) explains this. The data is informative-only, the kernel exposes its currently-used symbol table to kernel debuggers and/or the kernel module loader this way, through /dev/ksyms.
Linux does the same through /proc/kallsyms; /proc/ksyms - if present - is a "traditional" file presenting a subset of the same data (i.e. it's deprecated).
The difference, as usual for Linux/Solaris, is that the Linux version presents text while the Solaris one is binary. You can run nm /dev/ksyms on the Solaris one to get the same type of output you get from cat /proc/kallsyms on Linux.