I absolutely love that the BSDs are switching to llvm. This makes me giddy like a school child.
By switching to a full llvm toolchain, the BSDs will be able to do some really nifty things that simply cannot be done in Linux. HardenedBSD, for example, is working on integrating Cross-DSO CFI in base (and, later, ports). NetBSD is looking at deeper sanitizer integration in base. From an outsider’s perspective, it seems OpenBSD is playing catch up right now, but they’ve got the talent and the manpower to do so within a reasonable period of time.
It’s my dream that all the BSDs switch fully to llvm as the compiler toolchain, including llvm-ar, llvm-nm, llvm-objdump, llvm-as, etc. Doing so will allow the BSDs to do add some really nifty security enhancements. Want an enterprise OS that secures the entire ecosystem? Choose BSD.
Linux simply cannot compete here. A userland that innovates in lockstep with the kernel is absolutely required to do these kinds of things. Go BSD!
You’re overstating it. Most of the mitigation development of past decade or two was for Linux. Most of the high-security solutions integrated with Linux, often virtualizing it. The most-secure systems you can get right now are separation kernels running Linux along-side critical apps. Twoexamples. Some of the mitigation work is also done for FreeBSD. Of that, some is done openly for wide benefit and some uses BSD license specifically to lock-down/patent/sue when commercialized. Quick pause to say thanks for you own work on the open side. :)
So, what’s best for people depends on a lot of factors from what apps they want, what they’re trying to mitigate, stance on licensing, whether they have money for proprietary solutions or custom work, time for custom work or debugging if FOSS, and so on. One is not superior to the other. That could change if any company builds a mobile/desktop/server-class processor with memory safety or CFI built checking every sensitive operation. Stuff like that exists in CompSci for both OS’s. Hardware-level security could be an instant win. Past that, all I can say is it depends.
On embedded side, Microsemi says CodeSEAL works with Linux and Windows. CoreGuard, based on SAFE architecture, currently runs FreeRTOS. The next solution needs to be at least as strong at addressing root causes.
Thanks for making me think a bit deeper on this subject. And thanks for the kind words on my own work. :)
With a historical perspective, I agree with you. grsecurity has done a lot with regards to Linux security (and security in general). I think the entire computing industry owes a lot to grsecurity, especially those of us in infosec.
With the BSDs (except FreeBSD) having the core exploit mitigations in place (ASLR, W^X), it’s time to move on to other, more advanced mitigations. There’s only so much the kernel can do to harden userland and keep performance in check. Thus, these more advanced exploit mitigations must be implemented in the compiler. The BSDs are positioning themselves to be able to adopt and tightly integrate compiler-based exploit mitigations like CFI. Due to Linux’s fragmentation, it’s simply not possible for Linux to position itself in the same way. HardenedBSD has already surpassed Linux as far as userland exploit mitigations are concerned. This is due in part because of using llvm as the compiler toolchain.
Microsoft is making huge strides as well. However, the PE file format, which allows individual PE objects to opt-in or opt-out of the various exploit mitigations, is a glaring weakness commonly abused by attackers. All it takes is for one DLL to not be compiled with /DYNAMICBASE, and boom goes the dynamite. Recently, VLC on Windows was found not to have ASLR enabled, even though it was compiled with /DYNAMICBASE and OS-enforced ASLR enabled, due to the .reloc section being stripped. Certain design decisions made decades ago by Microsoft are still biting them in the butt.
I completely agree with you about hardware-based exploit mitigations. The CHERI project from the University of Cambridge in England is doing just that: hardware-enforced capabilities and bounds enforcement. However, it’ll probably take another 20+ years for their work to be available in silicon and an additional 20+ years for their work to be used broadly (and thus, actually usable/used). In the meantime, we need these software-based exploit mitigations.
I guess I view it differently, due to newer versions of gcc being GPLv3, which limits who can adopt it. With llvm being permissively licensed, it can be adopted by a much wider audience. The GPL is driving FreeBSD to replace all GPL code in the base operating system with more permissively-licensed options.
(Speaking from the perspective of a FreeBSD/HardenedBSD user): gcc has no real future in the BSDs. Because of licensing concerns (GPLv3), the BSDs are moving towards a permissively-licensed compiler toolchain. Newer versions of gcc do contain sanitizer frameworks, they’re not usable in the BSD base operating system.
I absolutely love that the BSDs are switching to llvm. This makes me giddy like a school child.
By switching to a full llvm toolchain, the BSDs will be able to do some really nifty things that simply cannot be done in Linux. HardenedBSD, for example, is working on integrating Cross-DSO CFI in base (and, later, ports). NetBSD is looking at deeper sanitizer integration in base. From an outsider’s perspective, it seems OpenBSD is playing catch up right now, but they’ve got the talent and the manpower to do so within a reasonable period of time.
It’s my dream that all the BSDs switch fully to llvm as the compiler toolchain, including llvm-ar, llvm-nm, llvm-objdump, llvm-as, etc. Doing so will allow the BSDs to do add some really nifty security enhancements. Want an enterprise OS that secures the entire ecosystem? Choose BSD.
Linux simply cannot compete here. A userland that innovates in lockstep with the kernel is absolutely required to do these kinds of things. Go BSD!
You’re overstating it. Most of the mitigation development of past decade or two was for Linux. Most of the high-security solutions integrated with Linux, often virtualizing it. The most-secure systems you can get right now are separation kernels running Linux along-side critical apps. Two examples. Some of the mitigation work is also done for FreeBSD. Of that, some is done openly for wide benefit and some uses BSD license specifically to lock-down/patent/sue when commercialized. Quick pause to say thanks for you own work on the open side. :)
So, what’s best for people depends on a lot of factors from what apps they want, what they’re trying to mitigate, stance on licensing, whether they have money for proprietary solutions or custom work, time for custom work or debugging if FOSS, and so on. One is not superior to the other. That could change if any company builds a mobile/desktop/server-class processor with memory safety or CFI built checking every sensitive operation. Stuff like that exists in CompSci for both OS’s. Hardware-level security could be an instant win. Past that, all I can say is it depends.
On embedded side, Microsemi says CodeSEAL works with Linux and Windows. CoreGuard, based on SAFE architecture, currently runs FreeRTOS. The next solution needs to be at least as strong at addressing root causes.
Thanks for making me think a bit deeper on this subject. And thanks for the kind words on my own work. :)
With a historical perspective, I agree with you. grsecurity has done a lot with regards to Linux security (and security in general). I think the entire computing industry owes a lot to grsecurity, especially those of us in infosec.
With the BSDs (except FreeBSD) having the core exploit mitigations in place (ASLR, W^X), it’s time to move on to other, more advanced mitigations. There’s only so much the kernel can do to harden userland and keep performance in check. Thus, these more advanced exploit mitigations must be implemented in the compiler. The BSDs are positioning themselves to be able to adopt and tightly integrate compiler-based exploit mitigations like CFI. Due to Linux’s fragmentation, it’s simply not possible for Linux to position itself in the same way. HardenedBSD has already surpassed Linux as far as userland exploit mitigations are concerned. This is due in part because of using llvm as the compiler toolchain.
Microsoft is making huge strides as well. However, the PE file format, which allows individual PE objects to opt-in or opt-out of the various exploit mitigations, is a glaring weakness commonly abused by attackers. All it takes is for one DLL to not be compiled with /DYNAMICBASE, and boom goes the dynamite. Recently, VLC on Windows was found not to have ASLR enabled, even though it was compiled with /DYNAMICBASE and OS-enforced ASLR enabled, due to the .reloc section being stripped. Certain design decisions made decades ago by Microsoft are still biting them in the butt.
I completely agree with you about hardware-based exploit mitigations. The CHERI project from the University of Cambridge in England is doing just that: hardware-enforced capabilities and bounds enforcement. However, it’ll probably take another 20+ years for their work to be available in silicon and an additional 20+ years for their work to be used broadly (and thus, actually usable/used). In the meantime, we need these software-based exploit mitigations.
What does this news story have to do with LLVM?
UBSan (and NetBSD’s new micro-UBSan) is a sanitizer found in llvm.
And gcc.
Yes. So the tirade about LLVM could have been about GCC and it would make as much sense here.
I guess I view it differently, due to newer versions of gcc being GPLv3, which limits who can adopt it. With llvm being permissively licensed, it can be adopted by a much wider audience. The GPL is driving FreeBSD to replace all GPL code in the base operating system with more permissively-licensed options.
For the base OS, gcc is dead to me.
(Speaking from the perspective of a FreeBSD/HardenedBSD user): gcc has no real future in the BSDs. Because of licensing concerns (GPLv3), the BSDs are moving towards a permissively-licensed compiler toolchain. Newer versions of gcc do contain sanitizer frameworks, they’re not usable in the BSD base operating system.
NetBSD base uses GPLv3 GCC and builds it with sanitizers libraries etc.
Good to know! Thanks! Perhaps my perception is a bit skewed towards FreeBSD lines of thinking.
I know NetBSD is working on incorporating llvm. I wonder why if they use newer versions of gcc.