Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
T
tails
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 965
    • Issues 965
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 17
    • Merge Requests 17
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • tails
  • tails
  • Issues
  • #12354

Closed
Open
Opened Mar 17, 2017 by intrigeri@intrigeriMaintainer4 of 4 tasks completed4/4 tasks

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

  • #12397 (closed)
  • #12398 (closed)
  • #12428 (closed)

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)
Edited May 15, 2020 by intrigeri
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Tails_3.0~rc1
Milestone
Tails_3.0~rc1 (Past due)
Assign milestone
Time tracking
None
Due date
None
Reference: tails/tails#12354