Posts

• Aug 5, 2020

  Generic containers in C - Implementation

  Every non-trivial code, even C code, has to deal with data containers. While arrays are sufficient in lots of cases, memory usage or algorithmic complexity constraints may impose more clever choices. The lack of containers in C standard library is a classical reproach made to the C language, however, many container implementations are already shipped with the glibc, making them, if not standard, at least widely available.
  This post is starting a new series, aiming at presenting the container implementations available, show them at work and discuss of some pros and cons of using them.

• Jan 29, 2019

  Enums in C

  Working with enums in C is frequently considered as easy, but a lot of code dealing with them is at best written poorly or worst, in a dangerous or even incorrect way.

• May 2, 2017

  __attribute((cleanup([...]))) for automatic resource management

  For a C developer, proper handling of resources lifecycle, like freing allocated memory, or closing files properly is a vital task, but which can prove to be tedious depending on the situation. This article will cover briefly one of the techniques, that GCC (and clang) makes easy to implement, by mean of the cleanup variable attribute.

• Mar 17, 2017

  Argz / envz - simple configuration file format

  Reading the glibc manual can reveal some hidden gems which can prove useful from times to times. One I recently stumbled across resides in the argz.h and envz.h headers. In this article, I will present a simple, but quite common use case, which is reading and writing a simple configuration file, consisting of key / value pairs.

• Oct 26, 2015

  Namespaces, AppArmor and overlayfs - Part 3 / 3

  Now our rootfs has it’s file system which we’ll be able to restore to it’s initial state with some umounts and rms. It can also be shared between multiple instances. What’s more it is quite isolated from the rest of the system. But the first things a firmware’s pid 1 will do, will be to mount /proc, /sys and /dev and by doing so, will gain access to potentially harmful global resources.
  One of (the many) solutions involves a linux security module, such as SELinux or AppArmor. I choose to use the latter, first of all, because of it’s shell like glob syntax which is (sort of) human readable. This post, last of the series, will present the way one can implement it “by hands”, as I did in firmwared.

• Oct 18, 2015

  Namespaces, AppArmor and overlayfs - Part 2 / 3

  Now that the firmware can be instantiated in it’s own namespace, in it’s own root, we would like to be able to run multiple instances in parallel, without having one modifying the file system of the other. If possible, it would be great if we could keep the original firmware pristine and have the diff between it before and after the run, easily identifiable. This problem can be solved with union file systems in general and OverlayFS in particular, which is the object of this post.

• Oct 18, 2015

  Namespaces, AppArmor and overlayfs - Part 1 / 3

  The purpose of firmwared, is to make a specially compiled firmware, (for a drone, for example) modified as little as possible, run on a desktop PC. But if one wants to run a firmware’s pid 1 (in our case, boxinit, an android init’s fork), he has to run it as root. Then the problem is: how to protect the host PC from potentially harmful behavior of the firmware ?
  In this series of three blog posts, I will present the approach I have taken in firmwared, to attempt to solve this problem.

subscribe via RSS