Feature #14856

Use kexec to display kernel panic messages

Added by cypherpunks 2017-10-17 09:08:11 . Updated 2019-05-20 01:06:37 .

Status:
Rejected
Priority:
Low
Assignee:
Category:
Target version:
Start date:
2017-10-17
Due date:
% Done:

0%

Feature Branch:
Type of work:
Research
Blueprint:

Starter:
0
Affected tool:
Deliverable for:

Description

When a kernel panic occurs, it is displayed using printk(), which is only visible in the Linux console. If a user is in an X session, a panic simply causes the system to appear to lock up. Given that the kernel will panic in many situations where an unreliable exploit is used, it’s vital that that information be available to be communicated, otherwise even unreliable exploits can be used against Tails systems with next to no fear that they will burn their 0day. This is especially important now that Zerodium has put a bug bounty on Tails in order to provide various governments with live exploits.

The solution to the panic issue is to have the system kexec into a fresh kernel upon panic, and display, either via a framebuffer or Xorg, a message telling the user that the computer has crashed. It can either simply display the panic, or a friendly message saying Tails has crashed, and giving the option to reboot, view technical information (the panic log itself), or open a debugging shell (kgdb, for the more experienced users). It could additionally recommend that the panic information be written down and sent to the Tails team, or sent interactively, as the new kernel will be capable of connecting to the network.

The motivation for this change is threefold. Firstly, it raises the bar for attackers, as unstable 0days and other exploits can no longer be guaranteed to leave no trace. Secondly, it makes fatal errors more user-friendly. It’s not very encouraging when a security-focused operating system just stops responding, but if a message is displayed saying that it crashed, users tend to be more forgiving. Lastly, the new kernel can initiate a memory wipe immediately or before shutting down, allowing users with older DDR2 RAM to reduce the life of volatile secrets.

Implementation is simple. Kexec supports running upon panic, and the new kernel will be given a file, /proc/vmcore, which contains debugging information (simple to parse with tools) from the crashed kernel. Like any kernel, it will first start an init script, which can contain anything from a simple, ncurses-based dialog to a more complex environment with Xorg, or even a complete and working Tails system, allowing the user experience to simply be “something bad happened and you have been logged out”, followed by the early administration dialog with a possible new option involving reading and sending the panic report.


Subtasks


History

#1 Updated by mercedes508 2017-11-25 18:36:37

  • Assignee set to emmapeel

I’ll let you (emma) take care of this one according to our shift schedule

#2 Updated by Anonymous 2018-01-15 09:02:52

ping @emmapeel?

#3 Updated by emmapeel 2018-01-15 10:52:57

  • Assignee changed from emmapeel to intrigeri
  • QA Check set to Info Needed
  • Type of work changed from Code to Research

intrigeri: could you please, with your FT hat, have a look at this ticket and see if it is interesting for Tails’ roadmap?

#4 Updated by intrigeri 2018-01-15 11:05:15

  • Status changed from New to Rejected
  • Assignee deleted (intrigeri)
  • Priority changed from Normal to Low

It’s not clear to me if/how that information would be actionable by real-world users. Please reopen if there’s a clear & useful course of action we can realistically expect them to follow upon crashes if this were implemented. And then I think it’ll remain Low priority aka. “great patches are welcome but likely the Tails core team won’t work on this”.

#5 Updated by cypherpunks 2018-06-04 05:35:07

intrigeri wrote:
> It’s not clear to me if/how that information would be actionable by real-world users. Please reopen if there’s a clear & useful course of action we can realistically expect them to follow upon crashes if this were implemented. And then I think it’ll remain Low priority aka. “great patches are welcome but likely the Tails core team won’t work on this”.

The UX alone is sufficient reason to implement this. Kernel panics are not at all uncommon with Tails, and right now, they cause the system to lock up with no visible messages. I know at least one real-world users in real life who has called Tails buggy because it “randomly freezes on him” and he has no idea why (I had to tell him it was probably a kernel panic). Even a simple message saying “Tails has crashed” would be preferable to what we currently have, no?

#6 Updated by intrigeri 2018-06-04 06:05:04

Yeah, perhaps. Please reopen and assign to yourself if you intend to prepare a mergeable branch for this :)

#7 Updated by cypherpunks 2018-06-05 00:49:04

I don’t think cypherpunks can reopen, can they?

#8 Updated by intrigeri 2018-06-05 07:41:57

> I don’t think cypherpunks can reopen, can they?

Indeed, probably not. So either ask to reopen if/when it makes sense or create another user account and after enough contributions that account will get such credentials :)

#9 Updated by cypherpunks 2019-05-20 01:06:37

Just an update, but I do intend to work on this when I am able to. I have not abandoned it.