GITHUB POCO C++ libraries

The POCO C++ Libraries are powerful cross-platform C++ libraries for building network- and internet-based applications that run on desktop, server, mobile, IoT, and embedded systems.

Github source

Programming: Find location of Stack, Heap and current memory

 Simple code:

#include <stdio.h>

#include <stdlib.h>

int main(int argc, char *argv[]) {

    printf("location of code : %p\n", main);

    printf("location of heap : %p\n", malloc(100e6));

    int x = 3;

    printf("location of stack: %p\n", &x);

    return 0;

}

Note that %p prints the address of the pointer. 

Linux: Comparison of netlink vs ioctl mechnaisms for configuration control in kernel space

Why bother?

If you are writing a new kernel module or adding configurability to an existing one, typically you need some means by which you can communicate with the kernel module from user space.

Tradeoff - IOCTL vs Netlink sockets

I came across this discussion on an internet message board and had saved it for offline reading. Unfortunately, I am not able to find the website to refer it. If you find it please send me a note. Here are the key points that were made for the comparison:

• Polling vs direct: Kernel services can send information directly to user applications over Netlink, while you’d have explicitly poll the kernel with ioctl functions, a relatively expensive operation.

• Synchronous vs offline: Netlink communication is fairly asynchronous, with each side receiving messages at some point after the other side sends them. ioctls are purely synchronous: “Hey kernel, WAKE UP and do this now”

• Multicast support: Netlink supports multicast communications between the kernel and multiple user-space processes, while ioctls are strictly one-to-one.

• Reliability: Netlink messages can be lost for various reasons (e.g. out of memory), while ioctls are generally more reliable due to their immediate-processing nature.

• OS support: Netlink is effectively Linux-only; there’s an RFC that extends its utility to the software-defined networking (SDN) world, but I don’t know of anyone who’s actually implemented it for widespread adoption. In contrast, code written to use common ioctls (e.g. the terminal I/O series) is largely portable across platforms.

You will find multiple discussions on the internet which might have more comparisons, but the above ones concisely capture the most important aspects.

Pro tip:
At a high level - use these simple guide-lines.
For sending control info: ioctl should be your first choice, unless there’s an overriding reason, due to its immediacy and reliable delivery.
For sending data: For occasional data passing, ioctl should work fine. For bulk data, and especially if you’re look at asynchronous operation, Netlink is preferred.

Linux: Applications of kdump or kexec

Why use kdump

You are designing an embedded linux system and you want to ensure that - in general there are no or few crashes. However, it is especially important that when crashes do occur, we are able to collect all the possible dumps.

In the case of kernel crashes, it is especially important to get the entire gdb-like dump to ensure we can check the state of the memory/variables when the issue happens.

How does kdump work - A high level view

It is important to note that in the above sequence, when the crash happens, the crash/capture kernel boots in the context of the main kernel. Since it uses the same file system, we use the same init.d. In the init.d we check which kernel context we are running in e.g. -s vmcore FS to do the dump.
To setup the crash kernel, it is typically passed using command line parameters in the uboot:

crashkernel=256M@1892M ckernel=1

ProTip1: Setting up the crash kernel requires a good knowledge of how the platform is laid out and the memory organization. Sending incorrect parameters, can and likely will cause a lot of unexpected behavior.
ProTip2: Use other advanced options like -pic to give position indepenent code and also ask the SW not to reset the irq lines/controllers.

Reference

1. Kernel documentation on kdump
2. Red hat kdump crash recovery

Linux: Track a packet through the system

Problem statement: You want to debug and track a single packet through the entire system and understand delays etc?

Solution: This is a simple trick that can help in the debugging.

1. Insert a sequence number in the skb so that it is accessible from all layers.
2. Print timestamp for this one across all layers.
3. Using this to track and print packets irrespective of protocol headers and sequences inside.

This way the packet can now be tracked through the entire system.

Linux: Kernel Stack Corruption

What do you do when you see a crash trace like this one?

-- snip --
task: ffffffc07d4d8000 ti: ffffffc07d4d4000 task.ti
PC is at 0xc72kf
LR is at 0xc72kf
pc : [<00000000000c70c0>] lr : [<00000000000c70c0>]
sp : ffffffc07d4d7920
x29: ffffffc07d4d7720 x28: ffffffc07d4d7a58
x27: 0000000000000001 x26: ffffffc07d477780
x25: 0000000000000001 x24: ffffffc00088f000
--snip--
 [<00000000000c70c0>] (suspected corrupt symbol)

Linux: Why do we need an idle task?

There are two main reasons for having the idle task in the Linux kernel design:

• Historical reason: In the older days, CPUs were not capable of idling in a lower power state, so they would constantly execute the no-operation (nop^[1]) instruction. Now, with the advances in the CPU design, most processors will leverage a variant of the halt (HLT^[2]) instruction that will allow them to go to a lower power mode.
• Convenience: Instead of coding up and handling a special case for what to do when none of the processes are runnable i.e. the run queue is empty, we instead schedule the idle task, which is always runnable.

---

1. No operation code ↩
2. Halt instruction for 8086 based archs. ↩

Linux: No entries seen in /proc/modules on loading new kernel

Issue: No entries are seen in /proc/modules on loading a new kernel (typically built from scratch¹).
Solution: The solution is pretty simple. This is happening because the kernel has not loaded the module for which you would like to see the symbols. You can double confirm this by running:

$lsmod  > modulelist.txt
$cat modulelist.txt

If you do not see your module here, set the following while rebuilding your kernel:

make LSMOD="modulelist.txt" localmodconfig

Using this, reboot into your new kernel and your module should get loaded.

---

1. Quick ref on rebuilding kernel from source↩︎

Different ways to print Linux kernel symbols instead of addresses

Cheatsheet:

%pF versatile_init+0x0/0x110

%pf versatile_init

%pS versatile_init+0x0/0x110

%pSR versatile_init+0x9/0x110

(with __builtin_extract_return_addr() translation)

%ps versatile_init

%pB prev_fn_of_versatile_init+0x88/0x88

Linux: Implementing tftpboot with Linux u-boot

If your u-boot is not running tftpboot, for any reason as is the case with my board, you can always fool it into doing tftpboot for you by leveraging the run support in the u-boot bootloader.

U-boot is a very popular bootloader and you can learn more about it here: http://www.denx.de/wiki/U-Boot

Here is the trick to implement it:

setenv bootcmd 'dhcp; run cmd'
setenv cmd 'tftp LOADADDR PATH_TO_TFTPIMAGE'

 In the above set of commands you will have to replace LOADADDR with the correct address in memory where you want to load the image. The PATH_TO_TFTPIMAGE is the path to the image on the tftpserver.

Why Linux Kernel KASLR is not very effective

Recently, with more time on hand  I am reading about security in the Linux kernel. A common mode of attack on any program is using buffer overflow to implement return oriented programming (ROP) blobs. Return oriented programming is a mechanism of overwriting return addresses in a library to implement code blobs (or gadgets) that will perform the desired functionality.

Linux: How does the kernel invoke the correct driver for the corresponding /dev file ops?

To answer this question, I am picking snippets of texts from different blogs that I read online.

"When devfs is not being used, adding a new driver to the system means assigning a major number to it. The assignment should be made at driver (module) initialization by calling the following function, defined in <linux/fs.h>:

int register_chrdev(unsigned int major, const char *name,

struct file_operations *fops);

The return value indicates success or failure of the operation. A negative return code signals an error; a 0 or positive return code reports successful completion. The major argument is the major number being requested, name is the name of your device, which will appear in /proc/devices, and fops is the pointer to an array of function pointers" [1]

Thus, this will result in the registration of the device driver with a major number with the kernel. 

"Once the driver has been registered in the kernel table, its operations are associated with the given major number. Whenever an operation is performed on a character device file associated with that major number, the kernel finds and invokes the proper function  from the  file_operations structure. For this reason, the pointer passed to register_chrdev should point to a global structure within the driver, not to one local to the module’s initialization function."

Linux: Compare if two files are the same

Quick script I wrote in my .bashrc to check if two files are the same:

#md5sum

function md5comp()

{

    a=$(md5sum $1 | awk '{print $1}')

    b=$(md5sum $2 | awk '{print $1}')

    echo "Comparing $1 and $2"

    [ "$a" = "$b" ] && echo  "Equal" || echo "Not Equal"

}

Linux: Sleeping while atomic during kmalloc solved

So you ran into a crash where the kernel complains that you were sleeping while atomic.

You were either able to run objdump or gdb and track down that the crash is caused due

to a kmalloc? How is that possible?

Did you make recent changes which included putting in a kmalloc?