Hello everyone. So, today we will go through LVM and its place within the free basic ecosystem. So, I'm David Carlier. I contribute to various open source projects, but more or less related to the business world.

Can be video games, can be enterprise-oriented software. More related to the topic of the day, I'm an LVM Committer since May 2018.

So, what is LVM? LVM is a compound of toolset and frontends. Frontends which are able to generate what we call LVM IR. IR stands for automated representations, kind of high-level assembly, but much more architecture-independent.

So, if we take as an example Clang or Clang++ frontends from your source code, the lecture will generate symbols which will be sent to the same R to generate the AST, which is abstract syntax tree,

and then to the code Gen to generate the LVM IR. So, with LVM, we have also tools. You can build nice just-in-time compilers. You can extend LVM itself.

For instance, you can make what we call module pass, which is an expression on the compilation unit perspective, and then function pass, basic block pass, and so on.

When you can do circum check-in, you can add some structure, remove some structure, if you like. It's the compilation times pass, right? You have, in addition, the possibility to do some static code analysis.

We have what we call sanitizers. We'll go through later. All of these are available in FreeBSD since 9.10-ish. First, it was just an option parallel to the old GCC 4.2.

It was first needed to replace the old 4.2, which was the last GPL 2 version. So, it was quite a blocker because, from this, you can't do C++11 and so forth. You can't do only C99. So, it was time to replace this for the system.

So, then it became a full part of the system since FreeBSD 10. I mean, it's used to build the kernel, the other one. Most of the ports.

So, yes, the FreeBSD code base needed a lot of changes to fit clang criteria. Yes, a lot of changes to fit more modern style and so on.

So, and then, as the time goes, more and more architecture was supported. AMD64, ARM, until now, maybe only SPARC64 remains a bit behind the rest, but that's already a nice progress.

So, yes, here we go. Sanitizers, what are these? It's not really to clean up things, unlike the name I say.

It's more to detect, at runtime, some type of bugs. So, it's kind of complete pretty much well the static code analysis part. So, sanitizer gives many different runtime libraries to detect some type of bug for memory, for rest condition, for several kinds of overflow.

For instance, we have memory sanitizer. It's mainly about unicellular variables. Address sanitizer. It's more for doubler-free.

It's like overflow. For only, also, in addition, the leak sanitizer, which is pretty effective and also have much less performance drop compared to tools like Valgrind, for example, which can be 20 times slower.

Whereas with address sanitizer, it's five times slower sometimes. So, yeah, it's pretty much. We have undefined behavior sanitizer. It's kind of small, swift knife sanitizer. That means there is no shadow memory mapping, unlike address sanitizer or memory sanitizer.

So, it was, for instance, possible to port it to OpenBSD for this reason. It's kind of small sanitizer. It's only for intergovernmental flow with aligned pointers, and the performance drop is pretty small compared to the right.

You can combine it with other sanitizer. Whereas memory sanitizer and address sanitizer, you can't use them at the same time. They are mutually exclusive. We have a nice waste condition detection called threat sanitizer.

So, all of them are supported by FreeBSD. In addition, we have components like deep-fuzzer to do some fuzzing and X-ray instrumentation to do some performance benchmarking.

Right? So, for example, this very basic code, address sanitizer is perfectly capable to catch the first error.

The double free is perfectly capable to catch it. So, use actual free as well.

As you can see, it detects the first heap overflow, as you can see. It displays a line.

Memory sanitizer as well is capable to catch this initialized variable, which can go under the radar very well in production.

It works in production environment, but it's not correct code, obviously. As well, threat sanitizer is perfectly capable to catch this obvious waste condition.

Like this. Again, it shows you where the problem lies.

Ah, sorry. So, here, memory sanitizer was able to catch the initialized variable very well.

A different behavior sanitizer is capable to catch those two obvious errors. The alignment issue and then the integral overflow should be low, as you can see.

So, here, to show you the flag to pass to the frontends. So, memory sanitizer is memory, address sanitizer is address, threat sanitizer is address, and different behavior.

So, we mentioned earlier the leap phaser component. But what is phasing all about in the first place? It's a testing technique to catch certain type of bugs with software, mainly libraries, I might say, which relies on XML inputs.

Can be just reading a config file, can be listed in a socket, whatever you like. If we take an example, an image picture pressure, if you want to fuzz the picture format detection, if you want to fuzz how it detects PNG, JPEG, and so on.

So, the leap phaser will use inputs which we can call corpuses in the fuzzing vocabulary. So, those corpuses don't have to be full picture, can be just the first bytes of the picture format.

Then, the leap phaser will take those corpuses, will proceed to do some transformation which we call mutations. It will insert some random bytes to some random offset, remove some other bytes, eventually.

In order to trigger segmentation fault, this error, whatever. Those mutations will be then stored so they can be reused once you fix your bugs. So, fuzzing is meant to be run long enough, I mean hours at least, if not

days, if not weeks, if necessary, in order to cover the code as much as possible. So, as you can see, that completes pretty well the test we all know. But leap phasing is nice, but there are some culprits.

I mean, as I said, it fits better with libraries because with monolithic applications, for instance, if you want to fuzz nginx, that can become very difficult. It's a software relying on events, and leap phaser runs the code several times.

That can contradict pretty well, pretty much, the application workflow for this case. You might need to do a lot of changes in order to fit leap phaser needs.

So, here, to display how leap phaser works, you have your fuzz bin array, you have one or several core purposes.

We have also, as an option, it supports dictionary. Dictionary is a sort of way to guide the fuzzing.

Sometimes you may want to avoid too much pointless randomness. Let's take, as an example, you want to fuzz a HTTP server. You may not want to fuzz keywords like GET, PUT, DALET, and so on. Just maybe some part of the client request.

So, dictionary is a good way to guide a little bit, to make more sense of the fuzzing. And then, with the corpus and then eventually the dictionary, the inputs will undergo some mutation,

and those mutations will be then stored in the same place as the original inputs.

So, how in practice work leap phaser? You need to at least implement LVM fuzzer test when inputs, which take as an argument the mutated data.

So, it's a C function, right? And then you do what you have to do with this. So, for instance, there is an obvious overflow here. So, that's why I recommend to combine fuzzer with at least a sanitizer, like a sanitizer, for instance.

Once you compile your first bin array, you will see.

So, I type this, and then it comes with several options.

It shows how much fun it will do, the memory usage limit, if you want to do some parallel jobs.

What you can do as well is the max length of inputs, the initial seed for randomness. There are plenty.

Again, on FreeBaseD, the leak detection is not supported, but there are many. So, then you have to create a meaningful corpus folder.

Ah, sorry. For instance, I asked him to run time with this input folder,

and then it was able to catch the overflow. So, it created a crash file.

So, yet, normally, it should create some mutated data with a Nash code, and then the transform inputs.

There it is. So, we have now XQuery cementation.

As I said earlier, it's for doing performance benchmarking. For example, you are doing a new version of your software for your company,

and then a customer of yours calls you to tell you that this new release had severe performance drops compared to the previous version. So, XQuery cementation allows you, at least will help you, to find out where the bottlenecks really lie.

So, XQuery cementation will, when you compile your binary with XQuery cementation, will put some instrumentation hook in each function entry and each function excite for the instrumenting function because you can choose which function you want to instrument and which function you don't want to.

For instance, the more function you instrument, the slower the binary will get. So, you have to choose carefully which part of the code you want to instrument.

In order to do this, you need to add those attributes. So, you want to instrument always those two. You can also say you don't want to write these attributes.

To discard the function, you want to avoid to instrument.

So, by default, once you run your updated binary, it will create a file, but you can change the file naming. By default, it's x-ray log, the name of the application, and then hash, right?

And then, with LLVM X-ray, you can find out, you can do some accounting.

That means showing where your application spends most of the time. You can order because it will generate kind of CSV-like presentation.

So, it says here the first version of the Fibonacci function is the bottleneck in this case, right? So, that's nice adding some attributes.

In practical, I might say you may not want to touch your code too much to that degree, at least when it's your corporate work. So, fortunately, there is another solution. It's via an XADAR configuration file as follows.

You can say, please always instrument those two, and you can say like these two. Never instrument this one, please. And then, you can pass this config file as follows.

Same thing, it generates the same binary.

So, to summarize, here is your binary compiled with X-ray instrumentation.

So, I mentioned an instrumentation hook, but they are empty until you run the binary. And then, it will fill with timer. So, in the beginning of each function, the xi point of each function in order to generate the delta.

So, with LLVM X-ray graph, you can generate the code graph, and then from this, you can generate SVG, for example.

So, X-ray instrumentation works well with multi-thread case, but you have the possibility to aggregate data because it can become very verbose, obviously.

So, you can aggregate, you can tell to aggregate the data in one point. So, yes, that will be all.

Fortunately, my FreeBSD machine had crashed yesterday, so I couldn't use it. If you have any concern, question?