At Intersec, we love new technologies that can improve our working tasks, our code, and because it is fun! During Hackathon 0x09, I tested the possibility to use BPF for tracing and debugging our C codebase. What is BPF? In the beginning, BPF was a technology used for packet filtering 1. For example, when using the command tcpdump -i lo arp, BPF is used to filter ARP packets on the loopback interface.

During summer 2014 we organized our first hackathon. The rules are simple and are still up to date: The subjects are suggested by anyone in the company and there is no defined framework nor limit on what they can be although they often fall in the same categories, I’ll come back to that. Anyone can show interest in any of the proposed subjects and then work on it. In practice though, participants are mostly people from technical teams.

Introduction To investigate a bug, people will often resort to two methods once the bug has been reproduced: Add traces in the code. Use a debugger to instrument the execution of the bug. The second solution is much more powerful but also quite limited in the types of bug it can handle: If the instrumentation of the execution goes too far, it is impossible to go in reverse. A new execution is needed, with new breakpoints or watches, but also new addresses, variable values… If the reproduction is random, having to restart the process and reproduce the bug again can be very time consuming.

This post is an introduction to a useful tool here at Intersec, a tool that we call IOP: the Intersec Object Packer. IOP is our take on the IDL approach. It is a method to serialize structured data to use in our communication protocols or data storage technologies. It is used to transmit data over the network in a safe manner, to exchange data between different programming languages or to provide a generic interface to store (and load) C data on disk.

About multi-process programming In modern software engineering, you quickly reach the point where one process cannot handle all the tasks by itself. For performance, maintainability or reliability reasons you do have to write multi-process programs. One can also reach the point where he wants its softwares to speak to each-other. This situation raises the question: how will my processes “talk” to each other? If you already have written such programs in C, you are probably familiar with the network sockets concept.

We do write complex software, and like everyone doing so, we need a way to structure our source code. Our choice was to go modular. A module is a singleton that defines a feature or a set of related feature and exposes some APIs in order for other modules to access these features. Everything else, including the details of the implementation, is private. Examples of modules are the RPC layer, the threading library, the query engine of a database, the authentication engine, … Then, we can compose the various daemons of our application by including the corresponding modules and their dependencies.

Jeez! It’s been a year already! A year working at Intersec… Time goes by so quickly! A year ago, I was thinking about giving up the idea of appending “PhD” to my name: I quit the graduate program I was in after only 10 months. Before that I had been working for a year at this other company called… wait! Was it Intersec already? Oh my God! It was! Intersec? Really?

Introduction Back in 2009, Snow Leopard was quite an exciting OS X release. It didn’t focus on new user-visible features but instead introduced a handful of low level technologies. Two of those technologies Grand Central Dispatch (a.k.a. GCD) and OpenCL were designed to help developers benefit from the new computing power of modern computer architectures: multicore processors for the former and GPUs for the latter. Alongside the GCD engine came a C language extension called blocks.

This series of articles describes some of the best realisations made by Intersec R&D team during the 2-day Hackathon that took place on the 3rd and 4th of July. The goal had been set a day or two prior to the beginning of the hackathon: we were hoping to make Gerrit better at recommending relevant reviewers for a given commit. To those who haven’t heard of it, Gerrit is a web-based code review system.

Introduction The most used custom allocators at Intersec are the FIFO and the Stack allocators, detailed in a previous article. The stack allocator is extremely convenient, thanks to the t_scope macro, and the FIFO is well fitted to some of our use cases, such as inter-process communication. It is thus important for these allocators to be optimized extensively. We are two interns at Intersec, and our objective for this 6 week internship was to optimize these allocators as far as possible.