Many Gen2 users want to have a speed. Many Gen2 users use F-unswitched loops and many Gen2 users don't like the idea of being more secure in exchange of being slightly slower. And since Gen2 is about choosing

They also have the chance to choose to be more secure or to be more fast. So let's start with what's an Stack Overflow? Please raise up. Stand up, man. Put your hand here. And keep marking the end of the line because this is...

Yeah, so first when we want to do a function call, we insert some arguments. Let's say this for example could be echo and this one could be hello world. Then we got the function, so we have to add our return address, which is where are we going to continue the execution of our code.

And finally We add some frame pointer and some local variables. The frame pointer basically points to here. To the start of the stack of the of the function that callitude. Cool, isn't it? So what's the problem?

Swift, please stop pinging me. What's the problem? The problem is that we can, for example, if we have some local variable here

that is a buffer, let's say a char vector, start writing the stuff here like the frame pointer, then the return address, then the arguments. For example, if we use gets because nobody here uses gets, do you? You better don't. Well, he does but he works in a bank. It's normal.

So, what we do here is that it puts some random trust in the local variables that we find before our buffer, puts some random trust on the frame pointer if there is, because we don't care, puts an address pointing somewhere around here, puts a lot of knobs, which is instructions that do no thing,

and finally puts our EBL code that will remove the system or do all the EBL stuff we want to. That's the classical stack overflow, but we also have the return to libc, which is mostly the same. I mean, we put some trust here, we put the address of the function we want to get called,

then we put a fake return address, because maybe we don't expect our function to return if we are using exec, and yeah, some arguments that we will pass to the function and will get passed around. This is the classical return to libc attack, which consists of returning somewhere in the middle of the library.

So, what's needed for the attacks? You need for the classic attack to be able to execute code on the stack, which is where you have your variables. You need to have access to which is the stack address, you need to have access to the return address so you can modify it and make it go to the stack.

And for that kind of attack, you need the function address you want to call and access to the return address you want to modify and work with the arguments, of course, but if you have access to the first, you probably have access to the second one.

So what's SSP? It's simple. We have this stuff here. It's called a canary. So when you modify it, you check before returning, which is the value of the canary, and if it's different, it's exactly the same as it happens on a mine. I mean, you know that the people that went to the coal mines with a canary?

Yeah, if the canary dies, there is a issue, and you better get the hell out of there before it explodes. It's the same. If this value is changed, something bad has happened, and we better kill the program before it does anything bad. So that's SSP. I mean, there is not much magic before tibia. What's the problem?

Well, there are some functions, for example in group, that try to write in the stack because they need to, because they are that strange, and then, of course, you might need to disable this function on some code. Yeah, we just have to buy some pigs. It's not pigs of, pigs use of cakes.

It's basically compiling the binary in a way where you can put the code whatever you want, okay? So instead of saying the code is always going to be here, you say the code will be somewhere around there, and if I need to reference anything in my code,

I will do it according to the address where my code is, not to the particular address it will be. And we also have Fortif source, which is basically doing some operations to detect some vulnerabilities in compile and execution time.

Many, for example, improper uses of vectors and stuff like that. If you, for example, know the size of a vector, and you know you are having an overflow because you know you are going to write five bytes to a four byte vector, you can't say it because you know it. And you will make the program, in that case, just die when that condition happens.

We also have aclr and randm-map, which is the counter side of pi and pig on the kernel side. It's basically well, let's suppose my friend PrometheanFire here eats the code. So we execute the program PrometheanFire the first time, and he's here.

And I'm the kernel, so I move him here. For the next time we are going to execute him, and since it's on different places, if you don't know where he is, you cannot go and run the code. Okay, so that kind of stack, it's approximately the same. It's

putting the stack on a random address before answering to a system call. So I'm the kernel again. This guy, as you can see, it's a stack. It's made of food, put on top of it. Okay, so the first time we have him here. The next time we have him here. So if the attacker assumes

he's going to be here, because he cannot know where he's going to be, the time when he is not here, which is the most likely of times, you will say, oh, I want to execute code here. Wait, there is nothing. I cannot. We also have non-executable memory. Well,

this is quite simple. I mean, we know this is our code. So I pick a pen and say to the processor nx. You cannot execute this little piece of here, this data. Because everybody knows

this is what executes the stuff, and this is what the data is held. So basically, you just mark some places where you don't have code, as places that cannot be executed. And you can do also, by its best timing, you can also mark places where you have code, as places that won't be brought in.

And that's what comes to our next stuff. It's in-protect restrictions. We don't allow users to write and execute memory at the same time. I mean, if we know this is what does the stuff, we are not going to allow anybody to modify our math here in order to do different stuff

than what we want him to do. Yeah, this has a lot of problems, and somebody of you is going to tell me, what happens with it? We need to write and then execute data. Well, yeah, we know it, and you can disable this stuff on a binary basis. I mean, for example, on Firefox you can disable n-protect if you know you are going to need write and execute

permissions at the same time. So we also can remove the addresses on this maps and stat. If anybody of you has a Linux computer alone, you can check in bar proc, bar 1 for example, bar

stat or bar maps. There is information about where in memory is everything. I mean, basically, I'm a stat, and I'm saying that now Promising on Fire is here. Now he's here. Now he's here. So, well, now he's here. Now he's here. Perfect.

So if the attacker can read that information, then he can try to exploit his process. So we just remove that information. We put zeros instead. So when you read that one, you will find that Promising on Fire is here. No matter what happens. Yeah.

So we also restrict access to bar proc only to the owner of the process. Why is that? Well, if you are the owner, if you don't have the owner, you don't have any reason to access any information there. I mean, bar proc information is things like how to debug the process,

the things you saw on maps, statistics. And if you are not root, you shouldn't have access to that information if you are not the owner of the process. We also have a thing. It's called brute force deterrence. So, I have a shield called Promising on Fire.

I know we don't look alike. Suppose for a second it's a clone of mine, because I have done a fork. somebody, some bad person over there exploits him. And because of the misses we have explained, the exploit didn't work. But then he requests me another clone. So I make another clone of me. Yeah, another Promising on Fire.

And since it's going to have exactly the same information, you could try for example to detect the values of the canary. I mean, you could keep doing tries until eventually you manage to find the value. Or indeed you can do a thing that is collecting incremental access. You keep guessing one byte at a time, by sending a buffer that is one byte longer, one byte longer,

until eventually you get a proper access. So, the problem is that since he's always a clone, he's always the same program with the same information, if something bad happens, we need to prevent that. Or at least make it a little bit difficult.

So what we do, it's the kernel, when I want to fork after he has dead, so I fork, you attack, he dies, I say I want to fork again, the kernel tells me, hey, hey, hey, hey, hey, hey, wait a little bit, and then you fork.

So basically we convert what could be used for example as an attack to get complete control of the program in a denial of service attack. Yes, before I continue with the talk, I want to make this quite clear. We have no magic palette. I mean, we have no way of making the attack fail always.

But we have ways of making the attack at least less handful. I mean, I suppose every of you, all of you agree with me that it's better to have a service that is not running, to have a service that it's being, it's already controlled by the attacker,

and executing whichever code you're talking to do. Please answer. It's a question. It's an open question. Don't you think so? Yeah, okay. So we also have re-row and bind now. It's basically that if we know for example

that this arm of Promethean Fire is going to stay on the same place every time we execute Promethean Fire, that sounded a little bit bad, okay, so we are going to mark this arm as read-only so it won't move and it won't be able to be changed.

So all the constants that you have in your program are the references to things that are in libraries. All that is going to be marked as read-only with our linker. And we are also going to force loading half the libraries at runtime. So if he for example needs something in me, and he has a reference here pointing to me, let's say, Sam,

since there is two ways of loading libraries. One thing is that he can have the reference saying, not pointing to me, and then they load me, he points. Or you can, as soon as you execute him, load also the library, so you can make this point here and

mark it as read-only. It's quite simple indeed, I mean... Now we have race conditions! Prepare! Come here! So this works as follows. Matthew, please give a few steps and tell to the public hello. You need to give the few steps from here on the screen.

Go back, two steps... Wait! No, no, no, no, no, no, you're going to execute this evil stuff that I have to pass you around. That's basically a race condition. I mean, it means that I got

to the place where you are going to listen to me earlier than him. So instead of hello, I told you two everythings. For that we have a thing called restrictions on linking and... It's a really ugly name. It's quite simple, I mean... If you have things on bar TMP, which is usually a word writeable directory, you won't be able to execute them, well, that's TP.

And you won't be able to use P for some data, unless you own the process. I mean, if the process and the FIFO owner match, then you can use that FIFO, otherwise you can't. That way you prevent an evil user to put a FIFO there that shouldn't be there.

We do the same with symbolic links in temp, so... It's mostly the same idea. Then you have user-spaced referencing. Okay, get on that chair. No, no, up. As you can see, here's the high one. There's no code, kernel.

And he has this module that says you have to execute code there. So, run that module. Yeah, you see, there is nothing there, the kernel fails, it's an oops, oops, something went wrong, and nothing is executed.

What happens if the user says, hmm, let's put some code here. Execute! Oh, I want you to remove the whole system, please. You see the idea? It's quite simple. The idea is that since he's referencing to something that the user can control,

the user can take over the system and exploit that vulnerability. So for that we have a thing called youthRef, that is basically a check before we execute a function pointer to ensure it's pointing somewhere else. That, I mean, to ensure it's pointing to non-user space, to kernel space.

So you basically prevent the kernel from doing the stuff he is supposed to. Basically what we do is actually making sure that this place here, that is the user space, has never anything unless you load it, because you need to access it, and then you load it again.

So, we also have the kern-exec-gcc plugin. Let's say it's basically some kind of magic staff, because otherwise the task would take too long. That modifies the code before compiling, to get the code to work better with preventing execution attempts in kernel space.

And of course we have the classical minimum map address. This is already on normal Linux. But we have it since earlier, which is basically telling that the process cannot map anything in that particular point that we know it's going to cause problems,

unless you explicitly allow the process to do so. There is a permission that allows the process to do this kind of mappings. Okay, information leaks. That's the easiest thing in the world. See. Hey, what's your name? No, I can't read that.

Let's suppose that I'm not supposed to know his name. Hey, what's your name? No, don't tell it. Hey, what's your name? Oh, there's no time for worrying. Cool. Hey, can you show me your ID card? No need to, but you understand the idea. Oh, no, I know your name.

That's an information leak. It's when you can access some information you aren't supposed to, just by using hack-creative way of getting access to it. And we also have data rewriting. It's basically something similar to what happened with the stats we saw earlier. I mean, let's suppose that our friend Matt here

wants to ask me if one user is authenticated. So I'm going to say zero, we are going to do some execution here, and at the same time Matt is going to accidentally, because of an overflow or something, change that to one and then ask me.

Are you authenticated? It seems fun. Yes, I am. So the idea is that basically there are times in which you can rewrite data that you are not supposed to rewrite, which can be used for some exploits. So for that we have things like the reference counter overflow protection, another early name.

But the idea is more simple than it seems. It means that I'm a chunk of memory. So you point to me because I am reserved. I am reserved again. You point to me again. No, with the other hand. And I am reserved again, and you don't have no more hands, so you've got an overflow, and you point me with zero hands.

Oh, I'm free. I thought I am reserved, because somebody is going to use me. What we do is that instead we work as follows. I am reserved, point to me. I am reserved, point to me again. I am reserved. Oh, wait, two. Okay, I cannot be freed. I cannot do anything. It's going to stay at two forever.

So it's as you can see, the ideas behind hardening are quite simple, and most of them you probably cannot actually apply to your programs if you need them. There is not much more magic before testing, except that what could be a data rewriting access or

an information leak will instead be converted to a simple memory leak, which is bad, but it's not as bad. We also can limit comparisons on user copy, which we also do. It's simple. It's that when, get on the chair.

Thank you. Here's the kernel. It wants to access user space, and it says, oh, wait, since I'm using user ref, I have to use a function that says user ref will work. You're the ref that I want to access that user space. So you do so, and you try to access to my information, and I tell you, yes, right here, right here,

and that the owner of the process you put zero here, too, because it's longer, and I am passing you a longer buffer. That's the idea of how the vulnerability works, and what we do is that always we are going to do right here, right here, and when I say right here, since we are going to check that it's out of bones,

he won't allow me to do so. We try to generate these bones automatically, but most of them have to be made by hand, and this patch here accounts for, I think it was at least 80% of the code in the hardware kernel.

Wasn't it, Tori? I think it was at least 80 or something like that. So, the constify-ggc plugin. It's simple. This is basically, if we know something is not going to be modified, or we think so, we mark it as constant, so it's going to be read-only. That way it cannot be rewritten.

And memory, and it saves them. Well, it's simple. Get up. He is the all-powerful kernel. So, I'm a process. I end up accessing I tell him, execute another process. I start existing. Oh wait, here is some interesting information. It's the password from the other process.

So what we do, basically, it's erase memory pages when they are freed, and there is two reasons for that. The first one is preventing process from retrieving data of other processes.

And the second reason is that in that way you reduce to the minimum the life of the important data in the memory space. I suppose you have heard of call boot attacks, maybe. It's picking the memory of a computer that has been used to down and reading the information in it. We also do the same with the kernel stack.

It's exactly the same. I mean, before we write it from a syscall, we erase everything. So in case you can read information from the kernel stack from other calls, you cannot use it. And we have a plugin that is called stack leak, which basically sets an upper bound on the usage of the stack.

So you don't have to clean everything. You only have to clean that little part of the stack. Okay, the last another kind of attack is information compilation. It could work as follows. Hey Matt, give me your date of birth.

No. Yeah, okay. No, yes, give me the name of your first pet. I think you are seeing what I am trying to get. So today, with that information, I can then try to prepare my attacks. In this case, for example, if I was trying to take over a match identity.

Well, what we do is in the first site, you cannot use the mask. The mask is basically a buffer of messages from the kernel. And messages from the kernel should then be accessed by normal users. So only root can access them on a hard disk system. We also hide the symbols of the kernel, so you cannot know which functions do you have in your kernel.

So you cannot know which modules do you have loaded and if it has vulnerabilities or not. We also hide the process in the kernel because if you have a process that is doing encryption, for example, you know that encryption is already there. And if there is a kernel back affecting encryption, you can exploit it.

We also add some restrictions on barprog, so you cannot access kernel information that is there if you are not root. And we also add restrictions to sysfs and debugfs, which have even more kernel information and more system information.

And yeah, we deny petrace on non-relatable... I hate how that sounds, but it is simple. No, my friend here is going to be a vulnerable version of Zoo, which is used to get root privileges.

So, since I cannot read his code, I'm going to do this. I'm going to execute it with a petrace, which means I'm debugging the process. So I won't be able to exploit Zoo, but then I'm going to see, hmm, I'm your debugger, so which is your code here? And which is your code here? And which is your code here?

Because I'm your debugger, I need to know it. So, in a system like Gentoo, where almost each user might use different C flags, different versions of compilers and libraries, which makes in turn that the place of a stuff is different always. This kind of binaries are marked as non-relatable, so you cannot get that information.

And what we do is prevent this kind of exploit that we have commented to use by not allowing you to debug processes that are supposed to be run by a different user, or a different group. And well, now we have kernel root, kids. Get on the chair.

This is our kernel. Let's suppose I'm root now, I have managed to get an attack, and I'm going to, let's say, oh, I'm going to insert here a module that will record everything you say, and send it to me. If I hide the module, let's suppose I put it here, then it's a root hit. That's basically the idea.

It's a hidden module on a running process that you don't know it's there. So, you can get down. We have ways to prevent at least insertion. On the first way, we don't allow random access to physical memory.

Yeah, somebody's going to say for the next one. Yeah, we also disallow privileged IO. XOR, XOR, it works bad, and you cannot use it. Well, actually, some versions of XOR work when you disable privileged IO. For example, with the random module. But, even if that's the case, you can just disable that feature on your kernel, as in disable this kind of

system calls. So it will work. I, for example, have disabled privileged IO in this kernel, because otherwise I couldn't be able to be given this presentation. Well, unless you like a text console, that is. And yeah, we have other attacks. It seems that outside of our control, we don't know they are there.

Like, for example, there is this VM86 mode that is known, for example, for that famous bug in Windows that was running in every version in Windows science 3.1.2. I'm not sure if it was XP or Vista. Yes!

So, it's simple. We won't allow you to use this mode. And that way, we prevent this kind of issues, because let's get realistic. Nobody uses it! I mean, nobody uses this mode. So why must this be here? We also have a hardened module, autoloading, so the idea is that an unprivileged process cannot request the kernel to load a module, because he needs a feature that is supposed to be there. So if, for example,

let's say, a carnet, it's an invention. I mean, there doesn't exist anything like that, which is a cool new protocol that can do everything, and that is full of exploits.

It's a bilevel for your kernel, but it's not load. And you say, hey, I need a carnet socket! The carnet is going to tell you, no, the module is not load. You don't have privileges. I know, I want to pass for you. And since the module won't be load, then the boogie code won't be there. And we have also chroot jail restrictions.

Hands up if you have ever used BSD. Okay, not that many, cool. Hands up if you at least know what is a chroot. Wow! That's good.

So yeah, the chroot is basically that we set a different root directory for a particular program. And that's, you set a lot in security, because by setting a different root directory, you limit the damage that you can do to whatever is inside that root directory. At least in theory, actually, it's not like that. You can get out of the chroot and do a lot of heavy things, but in theory

it works like that. So what we do is first that in hardnet systems you cannot get out of the chroot. We restrict some behavior that would allow you to do so. And the second thing is that we won't allow access to you to anything that is outside of the chroot. Yeah, thank you for giving me the times, because...

Oh, 10 minutes, cool. We are on time then. So another thing we did, it's also move street info outside of the stack. Yeah, that was done by Pax. It's also done by Pipax, sorry. It's the Pax team. It's funny, he uses the Nick Pax team, but it's made of only one person, which is Pipax.

Yeah, exactly. I suppose he was expecting to have more people on his side when he started the project. It makes sense. So, the idea is that all the information of who owns a process and stuff like that is not on the stack anymore, so you cannot overwrite it just by accessing the stack.

It's somewhere in memory, and all you have is a pointer to that information in the stack. So it's harder to, for example, use the kind of exploit that is known by everybody like, yeah, I wrote a user ID, I put zero, and I get root access to the system.

We also have a consistent multi-thread privilege enforcement. If you use TLC, you don't care about that. But if you use normal libc, like you use libc, then you need this in order to ensure that when you do a clone call, all the threads will have the same privileges.

Yeah, we have the Intel Overflow GCC plugin. It's a work that tries to get to know when overflows are going to happen or likely to happen. And when it detects that, well, it tries to prevent this kind of overflows, like the memory leaks which fly in a thread layer, by

limiting it and marking things and things that, well, it works quite well, but yeah, we have also a TLC exploit response. It's simple. I'm a table user. I'm going to poke the kernel. Poke, poke, poke, poke, poke, poke. What? He said stop. No, I'm not allowed to do anything else.

Until, of course, we restart the kernel. The kernel will know that I was poking him and I start again. Poke, poke, poke. Exactly. We also disallow code execution on non-trusted folders, if you want, that is. It's basically that

users can only use code that is in root owner directories. If you want that feature, I mean, you can log to only a particular set of the users. And the idea is that, of course, if you cannot insert code, you cannot insert exploits.

And we have an extended feature of this that is used to prevent race conditions and that can cause a few heavy headaches, since it will disallow you to execute code in directories that can be whitened, that are not owned by yourself.

Speak a little bit louder.

Somebody, please go and hand him the microphone, because otherwise I'm... See, that's why I have volunteers. This may be a dummy question, but what happens if you mount a directory with binding options to make a

fake mount? I mean, just binding a directory to another? Do you mean inside of a CX root or here? Yes, because you are speaking about not executing code in a non-trusted directory, but what if you mount a directory using bind option, a directory to another? Well, if you mount a directory, the first thing you should take into account is that usually to mount the stuff,

you need to be root. And if that's not the case, because you are on a normal user system, like that one that you can just plug a USB system, a USB device, then yes, if the executable is owned by root, it will be executable by everybody in this case,

if the permissions allow it. No! Well, if you do a bind mode, it still retains the inodes of all files,

so the ownership of the files is still preserved, in which case the directories as well are also preserved in the ownership. So most of the time you don't have an issue, only on a specific mount point, because that is a different one, and for that you indeed need root access, so because you cannot bind as a user a bind mount, you cannot do the bind mount as a user,

we still have some protection to the TPE. Excuse me? So does the restriction apply to root user as well? The restriction applies on kernel space.

It's applied by the kernel to every process you are running. Yes, so... I see what's the problem. Okay, now I understand you. You were thinking that we were explaining restrictions on CHroot systems. Is that it? No, but I may not have understood this point, but...

Okay, well, I'll give you an idea. Yeah, I'll see you later. No problem. Yeah, okay. We can talk about that later on the roundtable indeed. Because we are already short on time. And yeah, we have been traced the trends of our non-ch children processes. It's basically that if you are not the parent of a process, you cannot debug it.

So you cannot modify its execution. I think for example Firefox trying to debug the GPG agent in order to get access to your GPG keys. And we also enforce the number of process scenarios on exec, which means that... Come here. Come here, come here.

If I make a clone and make it execute through, for example, the clone will still be there, but won't come to me. So if we disallow execs in the case that you have reached your process limit, the clone will still be mine. So it won't be allowed to make newer clones that are owned by a different user.

That's it. We also have a black calling and lazy... that sounds hot. It's basically some that on the network stack we modify some behavior.

So... First thing, if you send us a packet that we don't know what we do with, we just discard it. We don't care about that. And the second thing is that we won't wait for the last AC key when we have sent a thin packet, like I want to end the communication with you. And I have to wait for him to say me, yes, I know that you want to end the communication with me.

So if we are discarding packets instead, if he says this and there is nobody listening, we don't care about that because we are going to discard the packet anyway. So... basically we prevent this kind of exploit by discarding packets we don't know what to do with.

And finally we have protections after the attack. I'm going to go fast over this. We can prevent the users from opening sockets, particular users. We can audit what the users do on the kernel. We have mandatory access control like Selenus, which is developed by Swift over there,

in our site of Selenus, I mean. That prevents you from doing stuff, even if you are rude. And we also can mark partitions as read-only forever during the whole execution of the process, and don't allow the mounting of new partitions.

And I'm going to go fast over what we did last year. This is the part of the talk that if you went on last year, you might be interested in knowing. First, we have extended attributes for pax marks. It means that when you want to say a process, hey, I want to do this,

I need, for example, that you disable and protect. Until now you had to modify the execute table in order for the kernel to know that. Now you can just put an extended attribute to the execute table, telling, well, this person doesn't need mprotect. They are using

pax markings, so it means that the owner of the process can modify the pax mark. We also have redep pax. It's a tool that if you mark a library, as for example, everything that links against this library will need mprotect or disabled. I mean, we need to be able to write and execute at the same time.

It will detect what links with that library and fix the inconsistencies, so every process that links with that library, we will be able to write and execute information. We also have clearer kernel profiles. I mean, now when you configure the kernel, you said that if you are using a server or a desktop,

if you are visualizing hash costs, guests, or not virtualizing at all, and if you want performance or security. And we have fast virtualization, finally! We have to thank that guy over there who made most of the tests, actually. It means that now you can use coordinate systems with KVM, and they will work.

Mostly. Yeah, on newer systems. We also have upstream some libffi patches. Sorry, man, I said to do that. Which means that with newer versions of libffi, you can use coordinate systems.

And we have this cool new, I suppose you have heard about BPF, it's used by Widesar to execute the filtering stuff, I know, the filtering stuff on the kernel. So, BPF is basically can be used to feed values that interest, to execute code by jumping

somewhere in the middle. And yeah, we prevent that by putting the constants on different places every time you use BPF. And what's the future? Well, we want hardening, more hardening supported to upstream. Sorry, it's working on getting the hardening stuff we have in GCC, on

upstream GCC. We are working to have the last versions of the tool change packages, again, sorry, there is to be done. We have started a project on integrity measurement, which is made by Swift. So you have questions, go to him now in the last part of the round table. And we are working on updating the profiles by to the last version, that is sitting on zero

and it will be done in six months or something like that, if there is no problems. Gluenis is working on that. So thanks for everything. Questions, any fast questions? Cool.

So, well, yeah. I have a question. In the, I've been a Gentoo user for a few years now, but never installed a hardened profile. I seem to remember that using a hardened profile was

before, a few years ago, was not encouraged much because it might break stuff. But in the last few years I've seen some things on planet Gentoo that says that it's coming to a state where it is usable by, in normal systems.

Well, when I started with Gentoo hardened, I was a normal user. I mean, yeah, it's true. This is a desktop system and it's running Gentoo hardened. There are some issues still, like for example,

there is problems with binary stuff and you need to use the depth packs if you are using a radium kernel like us to put the proper markings on binaries using OpenCL and stuff like that. But mostly it works out by default and especially on servers,

it usually works out by default. And if you have any problem, please come to our chat channel and we will try to help you as much as we can. So for a normal default user who wouldn't mind meddling with some stuff, you would recommend that they install hardened by default. Yes, I recommend you to start, well, if you have used a Gentoo before, which is your case,

I recommend you to try HarderNet at least. And if you find it's okay for you and it fits your requirements, then use it. Okay. I mean, I won't recommend you to use HarderNet because if for any reason you have a strange hardware and we have a problem with that particular hardware or a really strange setup,

we are Gentoo people, we know what the strange setups are, everybody has one. So in that case, I cannot say you use HarderNet, but in general it works well. Okay, thank you. So we are done, I suppose, we have no more time. We are going to do now the roundtable, the test that we sit around, we talk about HarderNet for half an hour.

So sorry, Con. And yeah, you are welcome to join us and ask whatever questions you have. If you are not a Gentoo user, you are still welcome to come and ask any questions you have on HarderNet or whatever, or how we do stuff.

usually, yeah, the impact is usually less than 10%.

You were the one doing the benchmarks. So the question is... He asked which is the impact on performance for KVM. So the performance impact on KVM is, I'd say, less than 5%. It's very, very, very small.

Are you saying host or the guest level? No, I'd say if you lose 5%...

Can you repeat the question? Is the performance... Do you lose 10% from being hardened, on top of losing 5% from being in KVM as well? No, it's less. It's not all the... It's usually why it's smaller.

I mean... 10% is what we go to the worst cases. Right, you have a very worst case, like if you design code to hit all the slowness. So, any other questions? Let's go then to the roundtable. I think there are... I appreciate if you don't record the roundtable, so people don't feel compelled to speak.