-
I’m glad they’re looking at this. There are some issues, though:
- It’s partial ASR, not ASLR. There are technical differences between ASR and ASLR.
- Performance will be degraded due to using ASR instead of ASLR.
- Without PIE base randomization, AS[L]R won’t do much good.
- They’re not randomizing the top of the stack, only inserting a gap.
- I don’t know whether IllumOS supports a VDSO, but I didn’t see VDSO randomization in the patch (perhaps the VDSO doesn’t exist at all?)
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_ASLRflag 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):
- The dude who coined the term ASLR, pipacs, aka PaXTeam, has a few more years experience than probably both of us at exploit mitigations. I like to learn from the experiences of others. He believes there’s enough technical difference between ASR and ASLR to merit the separate names.
- Crypto is expensive. Pulling from the entropy pool is expensive. FreeBSD’s entropy pool doesn’t block, but pulling from the entropy pool is still expensive regardless.
- HardenedBSD pulls from the entropy pool at most five times (PIE base, stack, mmap(!MAPFIXED) mappings, VDSO, and if supported, for MAP32BIT). For systems that don’t support MAP32BIT, HardenedBSD’s ASLR will only pull from the entropy pool four times. This is done within execve time, not during other points in the application’s lifecycle. By contrast, ASR pulls from the entropy pool during the lifecycle of the application. Firefox on my system, for example, loads 122 shared objects. That means ASR will pull entropy at least 122 times during run time. We must conclude, therefore, that pulling from the entropy pool five times during execve is less expensive than continuously pulling from the entropy pool during the lifecycle of the application. 5 < 122.
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:
- Like it or not, ASLR is already in common use as a generic term to refer to a number of different approaches to address randomization.
- Absent benchmarks we’re left with hand-wavy arguments about one approach being “more expensive,” without any indication of how much more, or if it’s enough to make a significant difference in application performance.
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: +
softwaresince this is a release announcement, -freebsdsince that OS is not relevant.-
-
-
-
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?
-
-
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