Feature #12089

Enable the kernel page allocator poisoning

Added by intrigeri about 8 years ago. Updated about 8 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Target version:
Tails_3.0
Start date:
2016-12-27
Due date:
% Done:

100%

Feature Branch:
bugfix/12354-drop-kexec-memory-wipe
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

Following-up on Feature #11886, extracting this bit so that we can close Feature #11886 in Tails 2.10.

This requires CONFIG_PAGE_POISONING=y, requested for the Debian kernel in https://bugs.debian.org/849450.

Subtasks

Related issues

Related to Tails - Bug #12354: Fix shutdown and memory wipe regressions on 3.0~betaN Resolved 2017-03-20
Blocked by Tails - Feature #12122: Upgrade Linux to 4.9 Resolved 2016-12-27
Blocks Tails - Feature #12090: Enable the slab allocator poisoning Resolved 2016-12-27
Blocked by Tails - Bug #12298: Can't build the devel branch due to virtualbox-guest-dkms incompatibility with Linux 4.9 Resolved 2017-03-05

History

#1 Updated by intrigeri about 8 years ago

  • related to Feature #11886: Upgrade Linux to 4.8 and adjust our kernel tweaks accordingly added

#2 Updated by intrigeri about 8 years ago

  • related to Feature #12090: Enable the slab allocator poisoning added

#3 Updated by intrigeri about 8 years ago

  • related to deleted (Feature #11886: Upgrade Linux to 4.8 and adjust our kernel tweaks accordingly)

#4 Updated by intrigeri about 8 years ago

#5 Updated by intrigeri about 8 years ago

> This requires CONFIG_PAGE_POISONING=y, requested for the Debian kernel in https://bugs.debian.org/849450.

Fixed in version linux/4.9.1-1~exp1

#6 Updated by intrigeri about 8 years ago

#7 Updated by intrigeri about 8 years ago

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 10
  • Feature Branch set to feature/12089-poisoning

#8 Updated by intrigeri about 8 years ago

#9 Updated by intrigeri about 8 years ago

  • related to deleted (Feature #12090: Enable the slab allocator poisoning)

#10 Updated by intrigeri about 8 years ago

#11 Updated by intrigeri about 8 years ago

  • blocked by Bug #12298: Can't build the devel branch due to virtualbox-guest-dkms incompatibility with Linux 4.9 added

#12 Updated by intrigeri about 8 years ago

  • related to Feature #12107: Can PAX_MEMORY_SANITIZE replace memory erasure on shutdown? added

#13 Updated by intrigeri about 8 years ago

  • Target version deleted (Tails_2.12)

Just like the grsec branch (Feature #12107), this breaks automated testing of our memory wipe feature as the pattern can’t be found in RAM regardless of whether we wipe it or not. So this is becoming much more complicated than expected => dropping target version.

#14 Updated by cypherpunks about 8 years ago

intrigeri wrote:
> Just like the grsec branch (Feature #12107), this breaks automated testing of our memory wipe feature as the pattern can’t be found in RAM regardless of whether we wipe it or not. So this is becoming much more complicated than expected => dropping target version.

Have you tried running it in QEMU, pausing the VM state, and dumping the memory contents at various times at shutdown?

How do you test for the contents in Tails’ memory, anyway? If you’re doing physical tests, note that LFSR scrambling on modern DDR3 and DDR4 DRAM will make it hard to observe any patterns.

#15 Updated by intrigeri about 8 years ago

> Have you tried running it in QEMU, pausing the VM state, and dumping the memory contents at various times at shutdown?

What “various times”, and what would we learn through this experiment?

> How do you test for the contents in Tails’ memory, anyway?

We do all these tests in QEMU, using its feature to dump the memory contents.

#16 Updated by cypherpunks about 8 years ago

intrigeri wrote:
> > Have you tried running it in QEMU, pausing the VM state, and dumping the memory contents at various times at shutdown?
>
> What “various times”, and what would we learn through this experiment?

You said that you don’t find the pattern in memory even when you don’t wipe at shutdown. That implies that some process at shutdown is causing the pattern to be overwritten. Dumping at various times would allow you to find out exactly when it does get overwritten (which hints at why), without having to pull out kgdb.

#17 Updated by intrigeri about 8 years ago

> That implies that some process at shutdown is causing the pattern to be overwritten.

Well, given that the only difference between this branch and our “normal” ones (that don’t expose this behavior) is enabling poisoning, this seems pretty obvious, no?

#18 Updated by cypherpunks about 8 years ago

intrigeri wrote:
> > That implies that some process at shutdown is causing the pattern to be overwritten.
>
> Well, given that the only difference between this branch and our “normal” ones (that don’t expose this behavior) is enabling poisoning, this seems pretty obvious, no?

Oh I was completely misunderstanding you! My bad!

#19 Updated by intrigeri about 8 years ago

  • Feature Branch changed from feature/12089-poisoning to wip/feature/12089-poisoning

#20 Updated by intrigeri about 8 years ago

  • related to Bug #12354: Fix shutdown and memory wipe regressions on 3.0~betaN added

#21 Updated by intrigeri about 8 years ago

  • related to deleted (Feature #12107: Can PAX_MEMORY_SANITIZE replace memory erasure on shutdown?)

#22 Updated by intrigeri about 8 years ago

  • Assignee changed from intrigeri to anonym
  • Target version set to Tails_3.0
  • QA Check set to Ready for QA
  • Feature Branch changed from wip/feature/12089-poisoning to bugfix/12354-drop-kexec-memory-wipe

#23 Updated by intrigeri about 8 years ago

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

#24 Updated by intrigeri about 8 years ago

  • Status changed from Fix committed to Resolved