Project

General

Profile

Feature #11281

Enable kASLR

Added by intrigeri over 3 years ago. Updated almost 3 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
03/24/2016
Due date:
% Done:

100%

Feature Branch:
feature/10298-linux-4.x-aufs-kaslr
Type of work:
Code
Blueprint:
Starter:
Affected tool:

Description

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)

Related issues

Blocked by Tails - Feature #10298: Upgrade to Linux 4.x Resolved 08/11/2015

Associated revisions

Revision c48b9f65 (diff)
Added by intrigeri about 3 years ago

Enable kASLR.

refs: #11281

Revision bd961bd8
Added by anonym almost 3 years ago

Merge remote-tracking branch 'origin/feature/from-intrigeri-for-2.6' into devel

Fix-committed: #5650, #6729, #6850, #8485, #10190, #10298, #10733, #10733, #11281, #11588, #11582, #11590

History

#1 Updated by intrigeri over 3 years ago

#2 Updated by intrigeri about 3 years ago

  • 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?

#3 Updated by jvoisin about 3 years ago

It doesn't harm, but it's useless: public generic bypasses exist :)
But I guess it can annoy/stop kiddies.

#4 Updated by intrigeri about 3 years ago

  • 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 #10298 but you might want to review/test/merge both at the same time.)

#5 Updated by cypherpunks about 3 years ago

jvoisin wrote:

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.

#6 Updated by intrigeri about 3 years ago

  • Assignee changed from anonym to intrigeri
  • QA Check deleted (Ready for QA)

I'll re-run the test suite entirely now that this branch has been upgraded to Linux 4.6.

#7 Updated by intrigeri about 3 years ago

  • Assignee changed from intrigeri to anonym
  • % Done changed from 10 to 50
  • QA Check set to Ready for QA

I've seen all test suite scenarios pass eventually, and Jenkins doesn't seem to particularly dislike this branch, so here we go :)

#8 Updated by intrigeri almost 3 years ago

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).

#9 Updated by anonym almost 3 years ago

  • Status changed from In Progress to Fix committed
  • Assignee deleted (anonym)
  • % Done changed from 50 to 100
  • QA Check changed from Ready for QA to Pass

#10 Updated by anonym almost 3 years ago

  • Status changed from Fix committed to Resolved

Also available in: Atom PDF