My BSD sucks less than yours
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Daroussin, Baptiste
Jacoutot, Antoine
Instead of speaking about successful parts of the projects, this talk willfocus on the weakness of both OpenBSD and FreeBSD, exploring conceptualdifferences between them and also exploring directions where motivatedcontributors can start working on to improve the projects. While being generalpurpose operating systems we will see that one size doesn't fit all and howone or the other may be a better solution to a particular problem. Trolls areto be left at the door.
 40 seconds. No, because the recording starts exactly. I think I know. This is something experimental. Yeah, that's sort of a talk. It's not for you, Tom. Yeah, it's not for you, Tom. It's a thing. Anyway, welcome everyone. Thank you for attending this thing. My name is Antoine Jacoteau. I've been an open BSD developer for 11 years or so. And yeah, I think that's pretty much SunZero. I'm Baptiste Darussin. I'm a free BSD developer, member of the core team. And I've been in the project since almost eight years now. And we're here to speak about things. Yeah. So just a quick disclaimer before we start. We're going to talk about a lot of different topics. But of course, first, we're not experts at everything. And second, each topic that we're going to talk about could have their own one-hour talk. So there are a lot of stuff we're not going to go deep into. So sorry about that. And well, first let's start with how we came up with the idea of this talk. It was pretty funny actually. It was like, I don't know, it was summertime. It was afternoon. We were having herbal teas, farm cakes, something like that. Yeah, exactly. We were having interactions talking about something like the ponies, unicorns, the first stars. Yeah, book emperors, blah, blah, blah. The usual meeting you can have. Yeah, exactly. We had a lot of physiological discussion with Baptiste. So that was it. It was summer afternoon. Well, no, you can tell them. Yeah, okay, okay. We'll make it in. It was like 2 a.m. It was in a pub somewhere in our mango area. We were having our 10th pint of what was it, like crappy beer, like Duvel or something? No, no, no. It's a little indulgent. Oh, sorry, sorry. So I was, what was it? It was crappy beer. I was a hannigan. A hannigan, sorry. So we're having our 10th pint of hannigan. And I was like, Baptiste, this beer doesn't have any flavor anymore. It's like, I can't feel the taste. Yeah, yeah, and that's why you hit me. My God, you guys, you suck. You don't have flavor packages. Let's get ready to rumble. So, talking about flavor. Flavor in packages on OpenBSD is actually a very interesting concept. I'm not aware of any other UNIX package manager that actually implemented. That doesn't mean they aren't, and shows that I don't know any. What the Flavor package does is that it allows you to provide packages compiled with a different set of options. So that's very convenient from a dependency point of view. Since, according to the options that you want to compile the package with, the final binary will change, since you will end up linking to different libraries, et cetera. So to give you an example, let's say you want to compile Sendmail, and you want to give it support for SASL or LDAP, and things like that. So of course, if you compile against LDAP, your package will link against LDAP. Maybe it's something you want. Maybe it's something you don't want. And the thing is that on OpenBSD, we really want the user to use packages and not compile things. So Flavor lets you basically create a package with a pretty fine set of options. So we actually have several Sendmail packages that you can choose from when you install it, that they all conflict with each other, of course. And that's actually pretty convenient from a dependency point of view. It's different from what sub-packages, sub-package is when you build one big package that's too split. So that's typically used for things like PHP, for example. On OpenBSD, we build PHP with support for all modules. And at the end of the packaging, we actually speed the package so you have PHP IMA, PHP MySQL, PHP, blah, blah, blah, stuff like that. Yeah, on FreeBSD, it's true that we don't have the favors. Actually, we have kind of, I would say, shitty sub-package system where you're just hacking so that you get actually a sub-package. So for the case of PHP, it's basically the same as OpenBSD, and then you get PHP-IMAP, whatever. But it's true that some situations like for LibelDAP where you probably want to enable or disable Sazos, depending on what you need, right now we have two packages, both conflict together, but imagine someone is depending on LDAP and doesn't care if it's Sazos or not. What we have defined as a default is a default. So if you install, I don't know, LibelDAP Sazos, and you, some may depend on LibelDAP, then it will remove some mail, which is probably a good idea to remove some mail anyway. But we have work in progress in that direction. We are working a lot on that. The problem is we have a lot of old tools that deals with the port street, port master, port upgrade, and things like that. That depends on having a unique origin per package, and if you go to flavors, if you go to sub-packages, then you break that paradigm. So that's why it took so long to come down. But we have decided that, okay, fix those tools. Let's make this happen and see if someone cares about those tools. They will have to fix it, and we'll be happy to keep those tools if it's fixed. Okay. So like I said, I need Sazos support in opening LDAP on previous deal. Yeah. So I actually made it to bid on myself, right? No, actually we have a package for it. Oh, okay. But then what happens if I run like package update and package upgrade? I don't know everything that depends on your... So that's nice. Yeah. Yeah. So one of the things we do support, and I don't know what to do, is we do support upgrading packages on the given release. I mean binary. I got security issue. I got a new version and I have packages in place. We actually do support binary package upgrade on the given release, but we do not provide the pre-compiled packages. So... Yeah. So yeah, it's true that you need some kind of a build box where you can distribute your packages update from. There's actually work in progress in this area, and I'm pretty confident that within this year, we'll be able to provide binary upgrade for packages on all our supported releases. Oh, nice. Yeah. So keeping your box up to date will just be a matter of package... Package add minus you and... And up here. Talking about distributing packages actually, it's important to note that there are a lot of operations on OpenBSD when using package add. All done in using a no privilege user. The fetching of the packages, extracting, verifying the signature, et cetera. It's all done as a separate user. We don't go online as a root or nor as the build user. We actually prevent the build user to go online. And if I remember correctly, you guys tried to do that in libfetch,<|ml|><|translate|> in privilege, something like that. That was very good. Well, actually, yeah, what we do is since day one almost, well, since capcicom's day one, the package is capsicumized. So, yeah. So, yeah. So, yeah. So, yeah. So, yeah. So, yeah. So, yeah. So, yeah. So, yeah. So, yeah. So, yeah. So, yeah. So, yeah. So, yeah. So, yeah. So, yeah. So, yeah. So, yeah. So, yeah. So, yeah. So, yeah. So, yeah. So, yeah. So, yeah. So, yeah. So, yeah. So, yeah. So, yeah. So, yeah. So, yeah. So, yeah. So, yeah. So, yeah. So, yeah. So, yeah. So, yeah. So, yeah. So, yeah. So, yeah. So, yeah. So, yeah. So, yeah. So, yeah. So, yeah. So, yeah. So, yeah. So, yeah. among the cores, two and eight, and only one socket. And our actual scheduler isn't bad either, it's just that it's a bit old. It was written for real SMP machines, meaning that it does not consider the cache distance between the cores. And that's one of the main reasons why the machine with several sockets often have lower performance than the one with only one socket. We do, we do a lot of ping pong. So we can use 24 cores. In the context of bug built, it's way, way better for us in terms of performance to actually split this 24 cores into six different machines. Yeah, hopefully performance will improve. Yeah, well I wonder how you will handle this kind of change in the model of OpenBSD. Because I mean, when 3BSD took that road and changed the model to something more SMP, it took a lot of time. It also ended up with some fabulous release like 3BSD 5.0. So I'm not saying that the road we took, well we have to change almost everything in one big release, it's the only one to go. But I don't see how you can do with very incremental simple way, getting rid of this jank lock. Okay, well there's a few things that can be incremental. Because they're not, they're not usually related to the schedule itself. Like for example, some performance issue that we have on OpenBSD actually come from speed lock in our P-thread implementation. So that's being actively worked on. We do expect a huge improvement in that regard for the next release or the one after. And contrary to the myth, I mean we scale very nicely on the big user land workloads. Of course, is our role performance on par with 3BSDs? No, but we have different priorities. And we're okay if we lose a bit of performance if that gains us more security or more simplicity or something that's closer to the goal that we have. Yeah, so to tell the truth, anyway, SMP support is something that should be done all the time because things change each performance, okay, to multiple, okay, to multiple cores and whatever. And on 3BSDs, the next challenge is really to get something like better, numer-aware support in the kernel. We need to set you improve a lot of locking mechanism to get into, if we can, direction of lockless things. So we are experimenting right now with concurrency to the kernel. What is the current status right now after moving to a fast SMP on OpenBSD? Well, our entire SCURSI stack and kernel providing already fully SMP, for example. Recently, there's been some huge work and progress on making our network stack SMP friendly. The goal being to be able to forward traffic over multiple threads and things like that. I don't think you will argue the fact that modern scheduling is hard, as you mentioned it. Most operating systems actually had to do it several times. I mean, some even rolled back and then when you see what happened in Linux, for example, it's completely scheduling, right? I mean, they have like 10 different scheduler. So yeah, that scaling is hard. So as usual on OpenBSD, we lag a bit behind in that regard that we're also learning from the other operating system and we make a big mistake, so hopefully we'll come there slowly and hopefully with a simple implementation because that's how we lag things. When, as I said earlier, you guys are waiting for which way to go. Right, so while you're here, can you explain me something I never understand on OpenBSD and the way you involve the project? It seems like you keep rewriting all the tools even if there is already BSD licensed counterparts. I mean, HTPD, SNTPD, VMM. Well, you're not suffering some kind of NIH syndrome. That's actually a very good question. I'm glad that you asked it because in my opinion, there are very objective reasons to do that. The first one would be trust and control. We have a coding style, practice and process that makes us confident in what we develop. We know someone will not decide to change the software license, for example, one day to the next door, so they start adding options and knobs for each and every crazy corner case that no one will be using. And looking at how many CVEs impacted like NTPD or OpenSSL in the last couple of years, should be a good hint as to why it was necessary to actually create NTPD implementation for us or fork and become liberal SSL. So I don't think it's really NIH syndrome to write secure implementation even if a BSD counterpart does exist. Right, but Mr. I'm sorry, I'm sorry. There's no BSD quality good enough, but not good enough in BSD alternatives. But what about the Hive? I mean, it was working because of the design, it's very easy to add security requirements that you may want. And so why started the new implementation? Well, because we had to basically, a few years ago, an effort was started to actually import the Hive, but after just a week trying to do that and not even being able to compile like two CVEs, we say that, I mean, if it's that much work to be to port the software, then we just should write our own from scratch. I mean, the situation may have changed since no behalf has been reported to Mac OS, I think. Yeah. So maybe it evolved, but at the time, it was really complicated. And but there was an effort that started. So it's not that we said, okay, let's trade BMM and not look into BI, we actually did look into BI. But on and on, I guess having control and rewriting some part of the software ecosystem gives us a base system that in our definition just works and works the way we want it to work. Like if you ever feel the need to tune or harden something on OpenBSD or tweak billions of options, then you're turning on the wrong operating system. And that's why also we are rewriting still to be really simple. Right, right. But I mean, what about the case of sandboxing? We have Capsicum, it works, it was there way before OpenBSD. So why not? There's also a very good reason for that. But before we talk about Capsicum and our sandboxing implementation, since you brought up the subject of security, we can talk about it a bit. Okay, let's go on it. So I maybe start with something which is not directly related to security, but helps a lot when you develop to get secure application while to not get flows. Say let's talk a bit about our malloc implementation, which is a G malloc. Yeah, so that tool is very nice. That malloc is very nice because it helps us to, you have a lot of tuning you can do on it through malloc.conf or the malloc.conf variable where you can, for example, use a tool called Preflick, a broth leak which allows you through malloc to detect memorandics a bit like deep ref tools are doing that. We can do heat profiling. We can do a lot of things like that. We can also put some garbage in the memory when you mallocs, so that you make sure that you don't correct things. Yeah, I think we're pretty similar in that regard. Our memory allocator has a lot of counter measures as well. Some are not enabled by default because they're very costly in terms of performance. But we, developers do run with them because it allows us to catch a lot of different issues beforehand, so they're pretty, we have a lot of very convenient options in our malloc. The capital C option is a good example. It enables all the security related options in malloc for security auditing. We have part pages that can be enabled, so just to provide you with an overrun detection. A bunch of different counter measures like that. Yeah, it's like both malloc are quite in the same team. Regarding debugging and memory related potential security issues. Partly in a different way, almost the same. On a side topic, related but different from malloc. The way we develop our demons on OpenBSD are always pretty much the same. We do privilege separation. Most of the code is one-chewed as a non-privileged user. And OpenSSH kind of led the way for the way we're doing things now. It was the first to actually implement all of this before anything else in OpenBSD. So we use also privilege revocation, to drug privilege as soon as possible. I mentioned NTPD earlier, which is a good example. It's a really traditional, if you look at the code, it's a good example because it's a traditional OpenBSD rating demon. It was written with principle of the least privilege in mind. So not only does it work set and pre-drop, but it also has complete privilege separation, TLS speaker for the constraint feature. Constraint feature is actually a pretty cool one. It allows you to mitigate the man in the middle pack. Basically, when you ask the time server, you will also connect using HTTPS to a well-known website, Google, Apple, whatever, and get the time from the web server as well. So you can actually compare what the time server and what the well-known web server on the internet gives you. And if the constraint is too hard, then there's probably a problem somewhere. Yeah, the thing is, you did that, but that have a lot of part in the case of HP. Like, for example, you don't support half of the feature that are supposed to be supported, like authenticating the peers, which are giving you as a time, or supporting proper lead second in that case. You actually just described exactly the strength of OpenATTPD. It is simple. It doesn't need to authenticate because we use constraints. That's good enough. It doesn't need to implement the kitchen scene because no one cares and no one uses most ATTPD feature. And if there is a need for it, then we have the NGPD package that people can install and use instead. It's just by default, we want something simple and secure. And on a really related topic, we are well-known for our numerous exploit mitigation techniques. It's important to note that all of these have been enabled by default for years. And they're very hard to actually disable. We don't want to encourage people to activate them. We actually activate them by default and they get very hard to disable them. I won't go into a lot of details, but we have ASLR or to notepad people here, I can say ASLR. I can say ASLR. WXORX, the stack matching protection from a police, by executable static binaries as well. The way we approach the OS development is that we assume that we're running in a hostile environment. So everything we do is actually dependent on that. Yeah, so in 3B, is the, well, yeah, we don't have yet ASLR, but we have probably, so we have a couple of mitigation technique waylust, I agree. But we also have something like the our primary purchase monetary access control, which is very nice to be able to compartmentize what an application is supposed to access to as a resource, network, five systems, or to view on a system preventing seeing that there are other users or the process. Way more. We also have a very nice auditing framework, the street open DSM, which allows you to, let's report everything that happened on your system. And even report that on a remote machine if you need to throw distributed mechanism. Okay. Well, just to rebound on what you said earlier regarding capsicum. So we do have a sandbox implementation, it's called pledge. So now the reason why we did not port capsicum is that capsicum is too complicated. I'm not saying it's bad, it's a very good capability system. It's just too complex. And as such, we think it doesn't get as much use as it should be. The pledge Cisco is actually very simple and describe exactly what we, how we envision security. We want to provide affordable security. By affordable, I mean simple, easy to use, and make it easy for the actual developer programmer to add pledge call into his code. One pledge was implemented, 30% of our base system was pledged after only about two months. And today we have between 85 and 90% of the entire user and base that use pledge. And even some big ports like Chromium is pledged. So it's actually pretty easy to use. So, and as such people actually use them. Also as a nice side effect is that I guess that's also true with Capsicum, but encourage actually re-auditing your code to know exactly where you're gonna put the pledge call and so on and so on. So yeah. Another feature we haven't really developed is the Jets, which are container secured by design, by default, and which allows you to run the process in a prison that cannot do anything. If you want to like reducing, you can just limit the number of CPU, you can limit the memory, the resource, the access to the network or no and things like that. That is very important to be able to add security on the system. Yeah, yeah, yeah, in that regard, I do agree that we suck. We have no container like technology. There's been an initial effort a few years ago in CIS jail, but it was using CIS trace, which had a big security flow. It would, that rendered basically the sandbox completely, completely. So, but anyway. Well, I think given the time, we'll probably skip the project explanation on how the different project works and that's around two, which will last only two minutes. Sorry. Wait, so it's a two track. Yeah, it's supposed to be a two track though, but. Right, so let's pick about the base defecation. I mean, you claim a lot about your license purity. Everything should be BSD and we do almost the same, but I'm very surprised by the fact that there's a lot of product we're working on to bring BSD license tools in the basic system. And we don't see you in that area in particular when speaking about the tool chain, for example. We're very close to get the first release without GPL in days of previously. Wow. For tier one. For what? For tier one. What is that? So tier one and previously means the main supported release, not in terms of supporting the code. So basically right now it's MD64 and IS386, but it means that the one we're providing binary security patches, well, security, binary security patches, because security patches will provide for everything. And so that's the most common one. We don't provide for MIPS or even POS. Well, see, we support the platform or we don't support it. So there is no tier one, two, three on OpenVSZ. Yeah, so basically OpenVSZ status right now is on tier one. We removed GCC, Lipschandl, C++, we have a full, almost full compiler chain via the license. We also removed half of the Bineutils using our home-backed L-Foodchain project, which removes everything but the linker. We're pretty close to add LLD right now, which will be the next linker to replace Bineutils totally. And so the only left thing, or, oh, we removed take info because, who reads take info files? I mean, no one, we removed CVS. Go see because we're not on CVS anymore. We removed ours. And GDB is slowly being removed, replaced by LLDB. So what is left is we still have Gnudiv. Well, as LLIV has been replaced by an OpenVSZ and a VSZMix plus some previous batches on top of it, you might want the batches, by the way. Is that him over? Yeah, I need to. Graph is still there because a couple of men paid for the rendering and because we have a lot of papers that were written back in the old time by free BSD developers that are in the base system that are written in rough. So we are still looking at what we do with that. The graph is still there because there is too many bugs in BSD graph for now, but, I mean, for free BSD 12, we're pretty sure that we'll be fully with any GPL license stuff. What is the situation for you? Well, okay, I will not talk about the licenses itself because I'm not a religious guy. Besides a few exceptions, most of the user land is BSD license on OpenVSZ. Which obviously still has some kind of a fork of Gnud CVS that we cannot remove right now. RCS is actually a rewrite, a BSD rewrite implementation. So that's under a BSD license. Man doc takes care of all our man needs, so we actually don't need a rough in the base system at all. So that's gone since a while. Regarding the tool chain, sorry, you guys are thinking ahead, I agree. But we finally did jump on the bandwagon thanks to the ARM64 architecture. So now we do have a lot of VMs, you land an older gang in base. I don't want to go too much into detail because this effort is somewhat recent. So there's probably a lot of things that are gonna change in the upcoming month. But we're going pretty much into the same direction as you guys are, LLD and C++, et cetera, et cetera. But as I mentioned earlier, we have no tier one, two, three. So we still have to support some architecture that will most probably never be supported by LLVM and the gang, so we'll have to keep GCC and such in base. Yeah, so I'm pretty sure that it took that long because you wanted to skip one of the subjects, which is this one. We don't want to talk about that. Yeah. I think we will have to, I think we'll have to. Well, it will be very quick. So basically we have a lot of five system support, including very modern one. We have journalization, soft updates, seeing that we have very nice high-sized SCSI support, very low-level system for storage, multi-pass, encryption, whatever. What is the situation on OpenBSD? I don't think people are really interested. Well, I guess, well, I will summarize it by saying that we still have bugs in soft updates. Yeah, you still have bugs in soft updates, certainly. Yeah, but I mean, you guys have curve, so. Yeah, true. It's easy to do. But yeah, no, we don't have the ZFS, obviously. I guess, licensing, but not just that. I use ZFS daily on different operating systems. It's really great. It's just super scary. What scares me the most is that it requires ECC memory. And when the five system requires ECC memory. It doesn't really. You can leave it out. Well, it's highly recommended. Of course, it works without it, but, so that's kind of scary. It's big, it's not just a five system. It's actually an entire volume, maintenance, whatever. But it's, I mean, feature-wise, it's great. It's awesome, and there's no. Too bad we don't have time to compare our desktop situation. Well, we're actually pretty much the same on the desktop, I guess. Yeah, we're so excited, I think. That's an entirely. It's getting there. It's not that they're true. We have all the packages, everything, but, I mean, the drivers are we are still laying behind and the Wi-Fi and the X. Yeah. Anyway, so, what's the thing considered Xpreer just that might be as easy success than yours? I'm not really sure. I pretty found that mine sucks very well less than yours. Yeah. Anyway, I'm really happy that OpenGSD, even if it sucks more than free BSD, is around as they push a lot of BSD license tool. And they are very pushing also security, security coding principle and widespreading that. So I'm very happy that you were there, guys. Thank you. Well, I think free BSD is very important as well. First of all, it's a real enterprise operating system. And it's, for me, the way I see it, it's slowly filling up the spot left by Osonaris. It bundles some amazing pieces of technology. And what is great about it is that it's actually our emblem to the external ecosystem. That is, people know about free BSD, huge company use free BSD, like, I mean, Netflix and all. So it's not just like some weird fringe operating system. Thank you. So we both organized the next EuroBusyCon in Paris in September, so we hope to see you, everyone there. Save the dates. And you can have the long version of the talk. Yeah. So actually we know now that it will get fit two hours. I thought they named it. Well, in French. Yeah, yeah. Anyway, thank you very much. Thank you. Thank you.
 40 seconds.  No, because the recording starts exactly.  I think I know.  This is something experimental.  Yeah, that's sort of a talk.  It's not for you, Tom.  Yeah, it's not for you, Tom. It's a thing.  Anyway, welcome everyone.  Thank you for attending this thing.  My name is Antoine Jacoteau. I've been an open BSD developer for 11 years or so.  And yeah, I think that's pretty much SunZero.  I'm Baptiste Darussin. I'm a free BSD developer, member of the core team.  And I've been in the project since almost eight years now.  And we're here to speak about things.  Yeah.  So just a quick disclaimer before we start.  We're going to talk about a lot of different topics.  But of course, first, we're not experts at everything.  And second, each topic that we're going to talk about could have their own one-hour talk.  So there are a lot of stuff we're not going to go deep into.  So sorry about that.  And well, first let's start with how we came up with the idea of this talk.  It was pretty funny actually. It was like, I don't know, it was summertime.  It was afternoon. We were having herbal teas, farm cakes, something like that.  Yeah, exactly. We were having interactions talking about something like the ponies, unicorns,  the first stars.  Yeah, book emperors, blah, blah, blah.  The usual meeting you can have.  Yeah, exactly. We had a lot of physiological discussion with Baptiste.  So that was it.  It was summer afternoon.  Well, no, you can tell them.  Yeah, okay, okay. We'll make it in. It was like 2 a.m.  It was in a pub somewhere in our mango area.  We were having our 10th pint of what was it, like crappy beer, like Duvel or something?  No, no, no. It's a little indulgent.  Oh, sorry, sorry.  So I was, what was it?  It was crappy beer. I was a hannigan.  A hannigan, sorry.  So we're having our 10th pint of hannigan.  And I was like, Baptiste, this beer doesn't have any flavor anymore.  It's like, I can't feel the taste.  Yeah, yeah, and that's why you hit me.  My God, you guys, you suck. You don't have flavor packages.  Let's get ready to rumble.  So, talking about flavor.  Flavor in packages on OpenBSD is actually a very interesting concept.  I'm not aware of any other UNIX package manager that actually implemented.  That doesn't mean they aren't, and shows that I don't know any.  What the Flavor package does is that it allows you to provide packages  compiled with a different set of options.  So that's very convenient from a dependency point of view.  Since, according to the options that you want to compile the package with,  the final binary will change, since you will end up linking to different libraries, et cetera.  So to give you an example, let's say you want to compile Sendmail,  and you want to give it support for SASL or LDAP, and things like that.  So of course, if you compile against LDAP, your package will link against LDAP.  Maybe it's something you want. Maybe it's something you don't want.  And the thing is that on OpenBSD, we really want the user to use packages  and not compile things.  So Flavor lets you basically create a package with a pretty fine set of options.  So we actually have several Sendmail packages that you can choose from when you install it,  that they all conflict with each other, of course.  And that's actually pretty convenient from a dependency point of view.  It's different from what sub-packages, sub-package is when you build one big package that's too split.  So that's typically used for things like PHP, for example.  On OpenBSD, we build PHP with support for all modules.  And at the end of the packaging, we actually speed the package so you have PHP IMA,  PHP MySQL, PHP, blah, blah, blah, stuff like that.  Yeah, on FreeBSD, it's true that we don't have the favors.  Actually, we have kind of, I would say, shitty sub-package system where you're just hacking  so that you get actually a sub-package.  So for the case of PHP, it's basically the same as OpenBSD,  and then you get PHP-IMAP, whatever.  But it's true that some situations like for LibelDAP where you probably want to  enable or disable Sazos, depending on what you need,  right now we have two packages, both conflict together,  but imagine someone is depending on LDAP and doesn't care if it's Sazos or not.  What we have defined as a default is a default.  So if you install, I don't know, LibelDAP Sazos,  and you, some may depend on LibelDAP, then it will remove some mail,  which is probably a good idea to remove some mail anyway.  But we have work in progress in that direction.  We are working a lot on that. The problem is we have a lot of old tools  that deals with the port street, port master, port upgrade, and things like that.  That depends on having a unique origin per package,  and if you go to flavors, if you go to sub-packages, then you break that paradigm.  So that's why it took so long to come down.  But we have decided that, okay, fix those tools.  Let's make this happen and see if someone cares about those tools.  They will have to fix it, and we'll be happy to keep those tools if it's fixed.  Okay. So like I said, I need Sazos support in opening LDAP on previous deal.  Yeah.  So I actually made it to bid on myself, right?  No, actually we have a package for it.  Oh, okay.  But then what happens if I run like package update and package upgrade?  I don't know everything that depends on your...  So that's nice.  Yeah.  Yeah. So one of the things we do support, and I don't know what to do,  is we do support upgrading packages on the given release.  I mean binary. I got security issue.  I got a new version and I have packages in place.  We actually do support binary package upgrade on the given release,  but we do not provide the pre-compiled packages.  So...  Yeah.  So yeah, it's true that you need some kind of a build box  where you can distribute your packages update from.  There's actually work in progress in this area,  and I'm pretty confident that within this year,  we'll be able to provide binary upgrade for packages on all our supported releases.  Oh, nice.  Yeah. So keeping your box up to date will just be a matter of package...  Package add minus you and...  And up here.  Talking about distributing packages actually,  it's important to note that there are a lot of operations on OpenBSD when using package add.  All done in using a no privilege user.  The fetching of the packages, extracting, verifying the signature, et cetera.  It's all done as a separate user.  We don't go online as a root or nor as the build user.  We actually prevent the build user to go online.  And if I remember correctly,  you guys tried to do that in libfetch,  in privilege, something like that.  That was very good.  Well, actually, yeah, what we do is since day one almost,  well, since capcicom's day one,  the package is capsicumized.  So, yeah.  So, yeah.  So, yeah.  So, yeah.  So, yeah.  So, yeah.  So, yeah.  So, yeah.  So, yeah.  So, yeah.  So, yeah.  So, yeah.  So, yeah.  So, yeah.  So, yeah.  So, yeah.  So, yeah.  So, yeah.  So, yeah.  So, yeah.  So, yeah.  So, yeah.  So, yeah.  So, yeah.  So, yeah.  So, yeah.  So, yeah.  So, yeah.  So, yeah.  So, yeah.  So, yeah.  So, yeah.  So, yeah.  So, yeah.  So, yeah.  So, yeah.  So, yeah.  So, yeah.  So, yeah.  So, yeah.  So, yeah.  So, yeah.  So, yeah.  So, yeah.  So, yeah.  So, yeah.  So, yeah.  among the cores, two and eight, and only one socket.  And our actual scheduler isn't bad either,  it's just that it's a bit old.  It was written for real SMP machines,  meaning that it does not consider  the cache distance between the cores.  And that's one of the main reasons why the machine  with several sockets often have lower performance  than the one with only one socket.  We do, we do a lot of ping pong.  So we can use 24 cores.  In the context of bug built, it's way, way better  for us in terms of performance to actually split  this 24 cores into six different machines.  Yeah, hopefully performance will improve.  Yeah, well I wonder how you will handle  this kind of change in the model of OpenBSD.  Because I mean, when 3BSD took that road  and changed the model to something more SMP,  it took a lot of time.  It also ended up with some fabulous release  like 3BSD 5.0.  So I'm not saying that the road we took,  well we have to change almost everything  in one big release, it's the only one to go.  But I don't see how you can do with very  incremental simple way, getting rid of this jank lock.  Okay, well there's a few things that can be incremental.  Because they're not, they're not  usually related to the schedule itself.  Like for example, some performance issue  that we have on OpenBSD actually come from  speed lock in our P-thread implementation.  So that's being actively worked on.  We do expect a huge improvement in that regard  for the next release or the one after.  And contrary to the myth, I mean we scale very nicely  on the big user land workloads.  Of course, is our role performance on par with 3BSDs?  No, but we have different priorities.  And we're okay if we lose a bit of performance  if that gains us more security or more simplicity  or something that's closer to the goal that we have.  Yeah, so to tell the truth, anyway,  SMP support is something that should be done  all the time because things change each performance,  okay, to multiple, okay, to multiple cores and whatever.  And on 3BSDs, the next challenge is really to get  something like better, numer-aware support in the kernel.  We need to set you improve a lot of locking mechanism  to get into, if we can, direction of lockless things.  So we are experimenting right now  with concurrency to the kernel.  What is the current status right now  after moving to a fast SMP on OpenBSD?  Well, our entire SCURSI stack and kernel providing  already fully SMP, for example.  Recently, there's been some huge work and progress  on making our network stack SMP friendly.  The goal being to be able to forward traffic  over multiple threads and things like that.  I don't think you will argue the fact  that modern scheduling is hard, as you mentioned it.  Most operating systems actually had to do it several times.  I mean, some even rolled back and then when you see  what happened in Linux, for example,  it's completely scheduling, right?  I mean, they have like 10 different scheduler.  So yeah, that scaling is hard.  So as usual on OpenBSD, we lag a bit behind in that regard  that we're also learning from the other operating system  and we make a big mistake, so hopefully we'll come there  slowly and hopefully with a simple implementation  because that's how we lag things.  When, as I said earlier, you guys are waiting for  which way to go.  Right, so while you're here, can you explain me something  I never understand on OpenBSD and the way  you involve the project?  It seems like you keep rewriting all the tools  even if there is already BSD licensed counterparts.  I mean, HTPD, SNTPD, VMM.  Well, you're not suffering some kind of NIH syndrome.  That's actually a very good question.  I'm glad that you asked it because in my opinion,  there are very objective reasons to do that.  The first one would be trust and control.  We have a coding style, practice and process  that makes us confident in what we develop.  We know someone will not decide to change the software license,  for example, one day to the next door,  so they start adding options and knobs  for each and every crazy corner case  that no one will be using.  And looking at how many CVEs impacted like NTPD  or OpenSSL in the last couple of years,  should be a good hint as to why it was necessary  to actually create NTPD implementation for us  or fork and become liberal SSL.  So I don't think it's really NIH syndrome  to write secure implementation even if a BSD  counterpart does exist.  Right, but Mr.  I'm sorry, I'm sorry.  There's no BSD quality good enough,  but not good enough in BSD alternatives.  But what about the Hive?  I mean, it was working because of the design,  it's very easy to add security requirements  that you may want.  And so why started the new implementation?  Well, because we had to basically,  a few years ago, an effort was started  to actually import the Hive,  but after just a week trying to do that  and not even being able to compile like two CVEs,  we say that, I mean, if it's that much work  to be to port the software,  then we just should write our own from scratch.  I mean, the situation may have changed  since no behalf has been reported to Mac OS, I think.  Yeah.  So maybe it evolved, but at the time,  it was really complicated.  And but there was an effort that started.  So it's not that we said, okay, let's trade BMM  and not look into BI, we actually did look into BI.  But on and on, I guess having control  and rewriting some part of the software ecosystem  gives us a base system that in our definition just works  and works the way we want it to work.  Like if you ever feel the need to tune or harden something  on OpenBSD or tweak billions of options,  then you're turning on the wrong operating system.  And that's why also we are rewriting still  to be really simple.  Right, right.  But I mean, what about the case of sandboxing?  We have Capsicum, it works, it was there way before OpenBSD.  So why not?  There's also a very good reason for that.  But before we talk about Capsicum  and our sandboxing implementation,  since you brought up the subject of security,  we can talk about it a bit.  Okay, let's go on it.  So I maybe start with something which is not directly  related to security, but helps a lot  when you develop to get secure application  while to not get flows.  Say let's talk a bit about our malloc implementation,  which is a G malloc.  Yeah, so that tool is very nice.  That malloc is very nice because it helps us to,  you have a lot of tuning you can do on it  through malloc.conf or the malloc.conf variable  where you can, for example, use a tool called  Preflick, a broth leak which allows you through malloc  to detect memorandics a bit like deep ref tools  are doing that.  We can do heat profiling.  We can do a lot of things like that.  We can also put some garbage in the memory  when you mallocs, so that you make sure  that you don't correct things.  Yeah, I think we're pretty similar in that regard.  Our memory allocator has a lot of counter measures as well.  Some are not enabled by default because they're very costly  in terms of performance.  But we, developers do run with them  because it allows us to catch a lot of different issues  beforehand, so they're pretty,  we have a lot of very convenient options in our malloc.  The capital C option is a good example.  It enables all the security related options in malloc  for security auditing.  We have part pages that can be enabled,  so just to provide you with an overrun detection.  A bunch of different counter measures like that.  Yeah, it's like both malloc are quite in the same team.  Regarding debugging and memory related  potential security issues.  Partly in a different way, almost the same.  On a side topic, related but different from malloc.  The way we develop our demons on OpenBSD  are always pretty much the same.  We do privilege separation.  Most of the code is one-chewed as a non-privileged user.  And OpenSSH kind of led the way  for the way we're doing things now.  It was the first to actually implement all of this  before anything else in OpenBSD.  So we use also privilege revocation,  to drug privilege as soon as possible.  I mentioned NTPD earlier, which is a good example.  It's a really traditional, if you look at the code,  it's a good example because it's a traditional  OpenBSD rating demon.  It was written with principle of the least privilege in mind.  So not only does it work set and pre-drop,  but it also has complete privilege separation,  TLS speaker for the constraint feature.  Constraint feature is actually a pretty cool one.  It allows you to mitigate the man in the middle pack.  Basically, when you ask the time server,  you will also connect using HTTPS  to a well-known website, Google, Apple, whatever,  and get the time from the web server as well.  So you can actually compare what the time server  and what the well-known web server on the internet gives you.  And if the constraint is too hard,  then there's probably a problem somewhere.  Yeah, the thing is, you did that,  but that have a lot of part in the case of HP.  Like, for example, you don't support half of the feature  that are supposed to be supported,  like authenticating the peers,  which are giving you as a time,  or supporting proper lead second in that case.  You actually just described exactly  the strength of OpenATTPD.  It is simple.  It doesn't need to authenticate  because we use constraints.  That's good enough.  It doesn't need to implement the kitchen scene  because no one cares  and no one uses most ATTPD feature.  And if there is a need for it,  then we have the NGPD package  that people can install and use instead.  It's just by default,  we want something simple and secure.  And on a really related topic,  we are well-known for our numerous  exploit mitigation techniques.  It's important to note that all of these  have been enabled by default for years.  And they're very hard to actually disable.  We don't want to encourage people to activate them.  We actually activate them by default  and they get very hard to disable them.  I won't go into a lot of details,  but we have ASLR or to notepad people here,  I can say ASLR.  I can say ASLR.  WXORX, the stack matching protection  from a police,  by executable static binaries as well.  The way we approach the OS development is  that we assume that we're running  in a hostile environment.  So everything we do is actually dependent on that.  Yeah, so in 3B,  is the, well, yeah, we don't have yet ASLR,  but we have probably,  so we have a couple of mitigation technique waylust,  I agree.  But we also have something like the  our primary purchase monetary access control,  which is very nice to be able to compartmentize  what an application is supposed to access to  as a resource,  network,  five systems,  or to view on a system preventing  seeing that there are other users or the process.  Way more.  We also have a very nice auditing  framework,  the street open DSM,  which allows you to,  let's report everything that happened on your system.  And even report that on a remote machine  if you need to throw distributed mechanism.  Okay.  Well, just to rebound on what you said earlier  regarding capsicum.  So we do have a sandbox implementation,  it's called pledge.  So now the reason why we did not port capsicum  is that capsicum is too complicated.  I'm not saying it's bad,  it's a very good capability system.  It's just too complex.  And as such,  we think it doesn't get as much use as it should be.  The pledge Cisco is actually very simple  and describe exactly what we,  how we envision security.  We want to provide affordable security.  By affordable, I mean simple,  easy to use,  and make it easy for the actual developer programmer  to add pledge call into his code.  One pledge was implemented,  30% of our base system was pledged  after only about two months.  And today we have between 85 and 90%  of the entire user and base that use pledge.  And even some big ports like Chromium is pledged.  So it's actually pretty easy to use.  So, and as such people actually use them.  Also as a nice side effect is that  I guess that's also true with Capsicum,  but encourage actually re-auditing your code  to know exactly where you're gonna put the pledge call  and so on and so on.  So yeah.  Another feature we haven't really developed  is the Jets,  which are container secured by design, by default,  and which allows you to run the process in a prison  that cannot do anything.  If you want to like reducing, you can just  limit the number of CPU,  you can limit the memory, the resource,  the access to the network or no and things like that.  That is very important to be able to  add security on the system.  Yeah, yeah, yeah, in that regard, I do agree that we suck.  We have no container like technology.  There's been an initial effort a few years ago  in CIS jail, but it was using CIS trace,  which had a big security flow.  It would, that rendered basically the sandbox  completely, completely.  So, but anyway.  Well, I think given the time, we'll probably skip  the project explanation on how the different project works  and that's around two, which will last only two minutes.  Sorry.  Wait, so it's a two track.  Yeah, it's supposed to be a two track though, but.  Right, so let's pick about the base defecation.  I mean, you claim a lot about your license purity.  Everything should be BSD and we do almost the same,  but I'm very surprised by the fact that  there's a lot of product we're working on  to bring BSD license tools in the basic system.  And we don't see you in that area in particular  when speaking about the tool chain, for example.  We're very close to get the first release without  GPL in days of previously.  Wow.  For tier one.  For what?  For tier one.  What is that?  So tier one and previously means the main supported  release, not in terms of supporting the code.  So basically right now it's MD64 and IS386,  but it means that the one we're providing  binary security patches, well, security,  binary security patches, because security patches  will provide for everything.  And so that's the most common one.  We don't provide for MIPS or even POS.  Well, see, we support the platform or we don't support it.  So there is no tier one, two, three on OpenVSZ.  Yeah, so basically OpenVSZ status right now is on tier one.  We removed GCC, Lipschandl, C++,  we have a full, almost full compiler chain via the license.  We also removed half of the Bineutils  using our home-backed L-Foodchain project,  which removes everything but the linker.  We're pretty close to add LLD right now,  which will be the next linker to replace Bineutils totally.  And so the only left thing, or, oh, we removed  take info because, who reads take info files?  I mean, no one, we removed CVS.  Go see because we're not on CVS anymore.  We removed ours.  And GDB is slowly being removed, replaced by LLDB.  So what is left is we still have Gnudiv.  Well, as LLIV has been replaced by an OpenVSZ  and a VSZMix plus some previous batches on top of it,  you might want the batches, by the way.  Is that him over?  Yeah, I need to.  Graph is still there because a couple of men  paid for the rendering and because we have a lot of papers  that were written back in the old time by free BSD developers  that are in the base system that are written in rough.  So we are still looking at what we do with that.  The graph is still there because there is too many bugs  in BSD graph for now, but, I mean, for free BSD 12,  we're pretty sure that we'll be fully with any  GPL license stuff.  What is the situation for you?  Well, okay, I will not talk about the licenses itself  because I'm not a religious guy.  Besides a few exceptions, most of the user land  is BSD license on OpenVSZ.  Which obviously still has some kind of a fork of Gnud CVS  that we cannot remove right now.  RCS is actually a rewrite, a BSD rewrite implementation.  So that's under a BSD license.  Man doc takes care of all our man needs,  so we actually don't need a rough in the base system at all.  So that's gone since a while.  Regarding the tool chain, sorry,  you guys are thinking ahead, I agree.  But we finally did jump on the bandwagon  thanks to the ARM64 architecture.  So now we do have a lot of VMs,  you land an older gang in base.  I don't want to go too much into detail  because this effort is somewhat recent.  So there's probably a lot of things  that are gonna change in the upcoming month.  But we're going pretty much into the same direction  as you guys are, LLD and C++, et cetera, et cetera.  But as I mentioned earlier, we have no tier one, two, three.  So we still have to support some architecture  that will most probably never be supported by LLVM  and the gang, so we'll have to keep GCC and such in base.  Yeah, so I'm pretty sure that it took that long  because you wanted to skip one of the subjects,  which is this one.  We don't want to talk about that.  Yeah.  I think we will have to, I think we'll have to.  Well, it will be very quick.  So basically we have a lot of five system support,  including very modern one.  We have journalization, soft updates,  seeing that we have very nice high-sized SCSI support,  very low-level system for storage,  multi-pass, encryption, whatever.  What is the situation on OpenBSD?  I don't think people are really interested.  Well, I guess, well, I will summarize it  by saying that we still have bugs in soft updates.  Yeah, you still have bugs in soft updates, certainly.  Yeah, but I mean, you guys have curve, so.  Yeah, true.  It's easy to do.  But yeah, no, we don't have the ZFS, obviously.  I guess, licensing, but not just that.  I use ZFS daily on different operating systems.  It's really great.  It's just super scary.  What scares me the most is that it requires ECC memory.  And when the five system requires ECC memory.  It doesn't really.  You can leave it out.  Well, it's highly recommended.  Of course, it works without it, but,  so that's kind of scary.  It's big, it's not just a five system.  It's actually an entire volume, maintenance, whatever.  But it's, I mean, feature-wise, it's great.  It's awesome, and there's no.  Too bad we don't have time to compare  our desktop situation.  Well, we're actually pretty much the same  on the desktop, I guess.  Yeah, we're so excited, I think.  That's an entirely.  It's getting there.  It's not that they're true.  We have all the packages, everything, but,  I mean, the drivers are we are still  laying behind and the Wi-Fi and the X.  Yeah.  Anyway, so, what's the thing considered  Xpreer just that might be as easy success than yours?  I'm not really sure.  I pretty found that mine sucks very well less than yours.  Yeah.  Anyway, I'm really happy that OpenGSD,  even if it sucks more than free BSD,  is around as they push a lot of BSD license tool.  And they are very pushing also security,  security coding principle and widespreading that.  So I'm very happy that you were there, guys.  Thank you.  Well, I think free BSD is very important as well.  First of all, it's a real enterprise operating system.  And it's, for me, the way I see it,  it's slowly filling up the spot left by Osonaris.  It bundles some amazing pieces of technology.  And what is great about it is that it's actually our emblem  to the external ecosystem.  That is, people know about free BSD,  huge company use free BSD, like, I mean, Netflix and all.  So it's not just like some weird fringe operating system.  Thank you.  So we both organized the next EuroBusyCon in Paris  in September, so we hope to see you, everyone there.  Save the dates.  And you can have the long version of the talk.  Yeah.  So actually we know now that it will get fit two hours.  I thought they named it.  Well, in French.  Yeah, yeah.  Anyway, thank you very much.  Thank you.  Thank you.
My_BSD_sucks_less_than_yours_0_59.png My_BSD_sucks_less_than_yours_60_131.png My_BSD_sucks_less_than_yours_132_1175.png My_BSD_sucks_less_than_yours_1176_1331.png My_BSD_sucks_less_than_yours_1332_1523.png My_BSD_sucks_less_than_yours_1524_1955.png My_BSD_sucks_less_than_yours_1956_2111.png My_BSD_sucks_less_than_yours_2112_2891.png My_BSD_sucks_less_than_yours_2892_3203.png My_BSD_sucks_less_than_yours_3204_3827.png My_BSD_sucks_less_than_yours_3828_4175.png My_BSD_sucks_less_than_yours_4176_4667.png My_BSD_sucks_less_than_yours_4668_4715.png My_BSD_sucks_less_than_yours_4716_4763.png My_BSD_sucks_less_than_yours_4764_4811.png My_BSD_sucks_less_than_yours_4812_4859.png My_BSD_sucks_less_than_yours_4860_4907.png My_BSD_sucks_less_than_yours_4908_5387.png My_BSD_sucks_less_than_yours_5388_5543.png My_BSD_sucks_less_than_yours_5544_6323.png My_BSD_sucks_less_than_yours_6324_6947.png My_BSD_sucks_less_than_yours_6948_9443.png My_BSD_sucks_less_than_yours_9444_9599.png My_BSD_sucks_less_than_yours_9600_12095.png My_BSD_sucks_less_than_yours_12096_12563.png My_BSD_sucks_less_than_yours_12564_13343.png My_BSD_sucks_less_than_yours_13344_15215.png My_BSD_sucks_less_than_yours_15216_15407.png My_BSD_sucks_less_than_yours_15408_17243.png My_BSD_sucks_less_than_yours_17244_17711.png My_BSD_sucks_less_than_yours_17712_19739.png My_BSD_sucks_less_than_yours_19740_22859.png My_BSD_sucks_less_than_yours_22860_23015.png My_BSD_sucks_less_than_yours_23016_23639.png My_BSD_sucks_less_than_yours_23640_24887.png My_BSD_sucks_less_than_yours_24888_26447.png My_BSD_sucks_less_than_yours_26448_26591.png My_BSD_sucks_less_than_yours_26592_27383.png My_BSD_sucks_less_than_yours_27384_28787.png My_BSD_sucks_less_than_yours_28788_29567.png My_BSD_sucks_less_than_yours_29568_30035.png My_BSD_sucks_less_than_yours_30036_30347.png My_BSD_sucks_less_than_yours_30348_31127.png My_BSD_sucks_less_than_yours_31128_31595.png My_BSD_sucks_less_than_yours_31596_35339.png My_BSD_sucks_less_than_yours_35340_35963.png My_BSD_sucks_less_than_yours_35964_37367.png My_BSD_sucks_less_than_yours_37368_37991.png My_BSD_sucks_less_than_yours_37992_38927.png My_BSD_sucks_less_than_yours_38928_39083.png My_BSD_sucks_less_than_yours_39084_39395.png My_BSD_sucks_less_than_yours_39396_40019.png My_BSD_sucks_less_than_yours_40020_40175.png My_BSD_sucks_less_than_yours_40176_42431.png My_BSD_sucks_less_than_yours_42432_47675.png My_BSD_sucks_less_than_yours_47676_50003.png My_BSD_sucks_less_than_yours_50004_50471.png My_BSD_sucks_less_than_yours_50472_52343.png My_BSD_sucks_less_than_yours_52344_54611.png My_BSD_sucks_less_than_yours_54612_56747.png My_BSD_sucks_less_than_yours_56748_56999.png My_BSD_sucks_less_than_yours_57000_65999.png My_BSD_sucks_less_than_yours_66000_67439.png My_BSD_sucks_less_than_yours_67440_72731.png My_BSD_sucks_less_than_yours_72732_72779.png My_BSD_sucks_less_than_yours_72780_72827.png My_BSD_sucks_less_than_yours_72828_73211.png My_BSD_sucks_less_than_yours_73212_73259.png My_BSD_sucks_less_than_yours_73260_79655.png My_BSD_sucks_less_than_yours_79656_82823.png My_BSD_sucks_less_than_yours_82824_82871.png My_BSD_sucks_less_than_yours_82872_84707.png My_BSD_sucks_less_than_yours_84708_85499.png My_BSD_sucks_less_than_yours_85500_85547.png My_BSD_sucks_less_than_yours_85548_85619.png My_BSD_sucks_less_than_yours_85620_85679.png My_BSD_sucks_less_than_yours_85680_85739.png My_BSD_sucks_less_than_yours_85740_85823.png My_BSD_sucks_less_than_yours_85824_85871.png My_BSD_sucks_less_than_yours_85872_85919.png My_BSD_sucks_less_than_yours_85920_85967.png My_BSD_sucks_less_than_yours_85968_86027.png My_BSD_sucks_less_than_yours_86028_86105.png