Since the blog was migrated (in fact,
the entire server), I was wondering what to do with the previous content
(especially the redmine installation, and the public git).
I don’t like the idea of installing a new redmine server (and dynamic
content), so I’ve decided to throw away all the previous content and public only
the new, static, content. This also makes the installation easier, because the
LXC containing the web server is read-only :)
Some of the active projects are now published on github:
In the previous examples, we’ve seen how to build OCaml applications to read,
manipulate and write LLVM bitcode.
To be able to generate realistic code, we now need to add a few more things.
This part explains how to create bitcode with a correctly specified target
triple, how to verify bitcode, and write a hello world application.
Target Triple and Data Layout
While LLVMIR is (or should be) target independent, there are a few things that
are not. For example, the support for some instructions, the padding and
alignment inside structures, the endianness, the size of pointers, etc.
All these things are specified in two attributes of modules: the target triple,
and the data layout.
In the current (3.5) version of LLVM, these two attributes are optional.
However, they could become mandatory in the future, so it is best specifying them.
Note: in my personal opinion, specifying that inside the module is clearly
redundant with the -march= option of llc. Most of this could have been
handled by compiler flags, instead of creating situations where one can ...
The previous articles explain how to build applications using the OCaml-LLVM
bindings, and how to use the API to manipulate the LLVM objects. This was the
“read-only” part of the tutorial, which can be used to analyze LLVMIR.
This part explains how to create LLVMIR, and write a simple application from
scratch, and see how to build and run it.
In the previous tutorial, we’ve seen how to use ocamlbuild and make to build
a simple application. In this part, we’ll start exploring the API, and see how
to access values and attributes of LLVM objects.
The base of the code is the same as in part 1: it reads an existing LLVM bitcode
file, for example one generated by clang.
As in previous tutorial part, knowing the LLVM C++ API is not required (but can help).
The top-level container is a module (llmodule). The module contains global
variables, types and functions, which in turn contains basic blocks, and basic blocks
In the OCaml bindings, all objects (variables, functions, instructions) are
instances of the opaque type llvalue.
A value has a type, a name, a definition, a list of users, and other things like
attributes (for ex. visibility or linkage options) or aliases.
Each value has a type (lltype), which is a composite object to define the type
of a value and its arguments. To match the real type, it needs to be converted
to a TypeKind.t:
This is the first part of a tutorial series, on how to use the OCaml bindings
Why use OCaml bindings ? Because you can avoid using the C++ API, spending huge
amounts of time compiling Clang sources, then your plugin, then debugging the
segfaults again and again. The bindings are stable, cover most of the API, and
are quite simple to use, thanks to the Debian packages.
This tutorial is written based on a Debian Sid, things may differ but should
stay similar on other distributions.
The objectives of this first part are:
install the required packages
setup a build environment for ocamlbuild
build a simple application that reads an LLVM bitcode file and prints it
The required packages are:
the LLVM and OCaml compilers (llvm-3.5, ocaml)
The current LLVM version is 3.6, however the OCaml bindings are currently
disabled (See Debian bug
#783919), because of
changes in the required dependencies.
Here are the materials for the talk PICON : Control Flow Integrity on LLVM IR,
given during SSTIC 2015. While SSTIC is a
french-speaking conference, I publish here in English because my other posts
also are in English.
Here is the summary, from the website:
Control flow integrity has been a well explored field of software security for
more than a decade.
However, most of the proposed approaches are stalled in a
proof of concept state - when the implementation is publicly available - or have
been designed with a minimal performance overhead as their primary objective,
Currently, none of the proposed approaches can be used to
fully protect real-world programs compiled with most common compilers (e.g. GCC,
In this paper we describe a control flow integrity enforcement
mechanism whose main objective is security. Our approach is based on
compile-time code instrumentation, making the program communicate with its
external execution monitor. The program is terminated by the monitor as soon as
a control flow integrity violation is detected.
Our approach is implemented as
an LLVM plugin and is working on LLVM’s Intermediate Representation.
It’s been a long time since the last post, so this is a kind of “I’m alive”
This blog has been migrated (as well as the entire server) to a static site
generator, pelican. The theme is a custom one,
inspired from pelican-boostrap. Why a static content generator ? Because
browsing is fast, because it’s easy to create a read-only container to host
pages, and because thanks to that I can avoid having PHP running.
As the migration was both an automatic and manual process, don’t be surprised
if things are broken, I will repair everything (don’t hesitate to give feedback).
In fact, the entire server has been migrated, and it took some time before
getting things to work again.
What will be published ? Same kind as before, random posts on technical stuff,
an OCaml-LLVM tutorial, thoughts on TLS, and maybe some sysadmin points one the installation of
Compiling a grsec kernel on a
laptop/workstation is a good way to add protection against wide classes
of attacks. However, while the options may be easy to choose on a
server, this may be difficult because a typical desktop needs more
privileges. Here are a few points:
Xorg (wants privileged I/O, unless you use KMS) conflicts with
PAX_NOEXEC and GRKERNSEC_IO
power management: applets to display the battery level want
(non-root) read permission on /sys, this will conflict with
GRKERNSEC_SYSFS_RESTRICT. You can enable SYSFS_DEPRECATED as a workaround.
power management: ACPI is required for a laptop (if you want to be
able to use suspend/resume, control fan speed, etc.)
power management: suspend/restore conflicts with some options
(PAX_MEMORY_UDEREF and PAX_KERNEXEC)
virtualization: PAX_KERNEXEC conflicts with kvm/vmx
If you have other points to add/corrections, just send them to me !
Now, another problem I have is that I must use the proprietary kernel.
Not that I really want to, but it is the only driver with proper support
for my graphics card (GT555M), since the nouveau driver has some
problems here: breaks suspend to ram/disk, sucks battery (I have 2h30 of
autonomy with nouveau, and about 5 with Nvidia ...
To work, Suricata needs some rules. The package
"snort-rules-default" provides some rules for Snort, but since
Suricata is compatible these rules will work.
However, these rules have some problems: they are outdated (and updated
only very rarely), and they are not written for Suricata (and cannot use
the specific keywords). Emerging
Threats provides some
rules (both open source and Pro). We will now configure Oinkmaster and
Suricata to be able to automatically update the signatures.
a tool to help you manage your signatures. While it is primarily
designed for Snort, it also works for Suricata.
If you have installed Suricata using the default configuration, then
Oinkmaster should be installed (it is recommended by the package). If