Fix shutdown and memory wipe regressions on 3.0~betaN (#12354) · Issues · tails / tails

Fix shutdown and memory wipe regressions on 3.0~betaN

Originally created by @intrigeri on #12354 (Redmine)

We’ve been reported a number of regressions vs. 2.x on 3.0~beta1 and beta2: on shutdown, the kernel is kexec’ed but then either nothing else happens (blinking caps lock == kernel panic) or the system fails to shut down and leaves the user facing an initramfs prompt.

So:

Do we see any cheap way to debug this? If not:
Is it better to have an unreliable memory wiping feature, that leaves the system in a weird (and suspicious) state when it fails, or no such feature at all? In other words, do we want to optimize for the high-risk users who need this feature and got hardware where it is reliable? Or for everybody else? And is it OK to provide this feature (and then some users will rely on it) even though it doesn’t work reliably (and then some users will be bitten because they rely on it and today / on other hardware) it fails?

Note that #12089 (closed) might be enough (see discussion on #12107 (closed) and tails-dev) to erase most memory without any special “memory wipe on shutdown” process.

Feature Branch: bugfix/12354-drop-kexec-memory-wipe

Subtasks

Related issues

Related to #12089 (closed)
Related to #12393 (closed)
Related to #5417 (closed)
Related to #12560 (closed)
Has duplicate #11786 (closed)
Blocked by #12554 (closed)

_Originally created by @intrigeri on [#12354 (Redmine)](https://public-redmine-archive.tails.boum.org/code/issues/12354)_

We’ve been reported a number of regressions vs. 2.x on 3.0\~beta1 and
beta2: on shutdown, the kernel is kexec’ed but then either nothing else
happens (blinking caps lock == kernel panic) or the system fails to shut
down and leaves the user facing an initramfs prompt.

So:

- Do we see any cheap way to debug this? If not:
  - Is it better to have an unreliable memory wiping feature, that
    leaves the system in a weird (and suspicious) state when it fails,
    or no such feature at all? In other words, do we want to optimize
    for the high-risk users who need this feature and got hardware where
    it is reliable? Or for everybody else? And is it OK to provide this
    feature (and then some users will rely on it) even though it doesn’t
    work reliably (and then some users will be bitten because they rely
    on it and today / on other hardware) it fails?

Note that tails/tails#12089 might be enough (see discussion on tails/tails#12107 and
tails-dev) to erase most memory without any special “memory wipe on
shutdown” process.

Feature Branch: bugfix/12354-drop-kexec-memory-wipe

### Subtasks

- [x] tails/tails#12397
  - [x] tails/tails#12398
  - [x] tails/tails#12428

### Related issues

- **Related to** tails/tails#12089
  - **Related to** tails/tails#12393
  - **Related to** tails/tails#5417
  - **Related to** tails/tails#12560
  - **Has duplicate** tails/tails#11786
  - [x] **Blocked by** tails/tails#12554

Edited May 15, 2020 by intrigeri

To upload designs, you'll need to enable LFS and have admin enable hashed storage. More information