This emacs “unexec” functionality is also why it didn’t build on FreeBSD/arm64 originally: https://lists.gnu.org/archive/html/bug-gnu-emacs/2016-11/msg00213.html
I’m glad they’re looking at this. There are some issues, though:
Regardless, having any form of randomization is better than none. And I’m sure this is just the start of the work. I hope they plan to support PIEs.
For what it’s worth, this is definitely just the start of the work. This patch has been floating around for quite a while, and most of what you’ve listed here was brought up right back at the beginning – but like you say, we decided that as a first step, something is better than nothing. illumos still has quite a bit of exploit mitigation work to catch up on at the moment when put against other server operating systems of its class (heck, we only got stack cookies turned on late last year in the kernel and we’re still on gcc 4.4.4 so they’re not even in half the functions I want them to be in).
PIE is on the cards. Rich Lowe said back at the beginning that he already had a dirty hacked-up prototype of it, but it probably needs a lot of work before it can go in.
Regarding vDSO – we don’t use that trick currently, though Joyent’s SmartOS distro includes some patches that add it only for Linux emulation (in the “LX brand”). Specific enhancements here will likely have to be done before LX makes it into upstream illumos.
And as for terminology… well, consider it aspirational – at least for me, I’d expect the PROC_SEC_ASLR flag to eventually turn on full ASLR once we have it. For now it’s doing the best it can (with the code it has) to fulfill what the user asked for. You could argue that’s misleading, and I’m not going to really disagree, but eventually I hope it won’t be. The bug title / commit message could have been clearer, but I hate bike-shedding those.
Completely agreed and it’s good to see that this is just the start. We at HardenedBSD are still playing catch up. There’s a whole heck of a lot of tasks to bring the grsecurity patchset to HardenedBSD. And we’re a smaller team that IllumOS.
Rich Lowe asked for my thoughts and suggestions in an email thread to him, which was sent off this morning. I gave some helpful suggestions on how to make the implementation better, but still keeping along the lines of ASR rather than ASLR.
I think that many people consider ASLR as a generic term, applying to various forms of address map randomization. The Wikipedia page on ASLR doesn’t make a clear distinction, and I have yet to find a good, detailed comparison of the implementation in various operating systems, or a reasonable benchmark comparing implementations.
I guess we’ll just have to eternally agree to disagree. Here’s why I’m so insistent on ASR vs ASLR nomenclature (in some of the points, I’m going to use HardenedBSD as an example, because I’m most familiar with its ASLR implementation):
Now, I’m not a performance engineer, but it doesn’t take one to know that doing expensive crypto operations fewer times means better performance. Unless there’s some magic that says the opposite. I think by performance alone, there’s merit to show distinction between ASR and ASLR. Add to that not using deltas.
Side-note: lobsters is misformatting my comments when using underscores in the right spots for MAPFIXED and MAP32BIT, so I’ve left them out. But I’m sure it’s clear where those underscores are supposed to be.
I think you may be missing my point. I’m not really disagreeing with you and certainly there are technical differences between the two approaches.
I’m simply saying that:
The final sentence in your first comment is the important part: getting this change into Illumos is much more important than whether the commit calls it ASR or ASLR and whether or not it addresses all of the related exploit mitigations.
I understand. English isn’t a dead language and meanings of words are subject to change. But, being an engineer, I prefer a distinction made between the two to easily tell the user what’s going on under-the-hood. If a user educated in security sees that an operating system uses ASR instead of ASLR, said user instantly knows the ramifications. If the technical implementation of ASLR is actually ASR under-the-hood, yet is marketed as ASLR, there is a lot of ambiguity. The user may assume deltas are being used.
Consider a developer writing an application that needs to make careful use of the virtual memory subsystem (maybe qemu or wine could be good examples). If the operating system claims ASLR when really it’s ASR, the developer might be confused when certain tasks within the application misbehave.
There’s nothing wrong with being extra clear about an implementation. Correctly stating the implementation is ASR benefits everyone in the long term.
I asked about it on twitter and was told it’s still not considered a stable conversion (the commit hashes may change in the future if necessary). I think this is a great resource to have, but be aware of the limitations.
Tag suggestion: +software since this is a release announcement, -freebsd since that OS is not relevant.
I figured the FreeBSD tag was relevant because of FreeBSD’s ongoing clang/llvm/lld efforts. But maybe not?
Ah, I see what you were going for. But the linked page doesn’t mention that at all.
They mention FreeBSD in the pages for the subprojects.
Indeed, upstream lld developers have been doing a lot of work to get lld into shape as a linker for FreeBSD, and FreeBSD developers have been working on bringing 3.9 into FreeBSD. The lld work is mentioned in lld’s release notes:
What’s new in ELF Support?
LLD 3.9 is a major milestone for us. It is the first release that can link real-world large userland programs, including LLVM/Clang/LLD themselves. In fact, for example, it can now be used to produce most userland programs distributed as part of FreeBSD.
But indeed, this isn’t a FreeBSD story per se.
I’m running FreeBSD 12-CURRENT on a Thinkpad X220, and have FreeBSD 10.3 on my desktop machine. I’ve been using a FreeBSD laptop as my daily driver since sometime in the mid 2000s.
I’ve been exceedingly happy with how FreeBSD works on the X220; it’s more than fast enough for most of what I want to do, and sound, wireless, suspend and resume, etc. “just works.” Admittedly the X220 is getting a little old now, and FreeBSD’s got a little ways to go with contemporary Intel graphics, but we’re close. Friends of mine are using the work-in-progress graphics stack update on recent Thinkpads like the T450 or X260.
Do you have a way to disable the trackpad in software?
I just turned it off in the BIOS, and haven’t looked for a way to do it in software.