linux (4.5-1~exp1) experimental; urgency=medium * [x86] Enable RANDOMIZE_BASE (kASLR). This is incompatible with hibernation, so you must use the kernel parameter "kaslr" to enable kASLR and disable hibernation at boot time. (Closes: #816067)
Blocked by Tails -
#2 Updated by intrigeri 2016-06-09 09:06:50
- Status changed from Confirmed to In Progress
- % Done changed from 0 to 10
- Feature Branch set to feature/10298-linux-4.x-aufs-kaslr
Dr_Whax pointed me to an article that explains that kaslr is not as good as one might think (I’m obviously not part of the target audience so I didn’t read it), he and said that 1. spender still thinks the same about the kASLR that landed in Linux 3 years after that post; 2. turning kaslr on may be weak, but shouldn’t harm.
On this ground, I would enable
RANDOMIZE_BASE with the
kaslr kernel command-line option, once we ship Linux 4.5+, even if it’s not a silver bullet.
co6, jvoisin: thoughts?
#4 Updated by intrigeri 2016-06-10 12:15:29
- Assignee changed from intrigeri to anonym
- Target version set to Tails_2.6
- QA Check set to Ready for QA
I’ve seen all test suite scenarios pass, Jenkins doesn’t particularly dislike it, and I see no blockers left. anonym, how about merging this for 2.6? (note that it’s blocked by
Feature #10298 but you might want to review/test/merge both at the same time.)
#5 Updated by cypherpunks 2016-06-12 05:40:15
> It doesn’t harm, but it’s useless: public generic bypasses exist :)
> But I guess it can annoy/stop kiddies.
It also makes debugging a good bit more irritating, because you have to take the offset into account with every address you get.
#8 Updated by intrigeri 2016-08-01 07:36:24
I’d like to ease reviewing for the 2.6 RM, and to get automated tests running about the combination of all these changes ASAP in the 2.6 dev cycle. So, I’ve merged this work, along with the other major branches I’m proposing for 2.6, into the feature/from-intrigeri-for-2.6 integration branch (Jenkins builds and tests.