Page MenuHomePhabricator

Emergency Crash Script to Protect Host FDE
Closed, ResolvedPublic

Description

One interesting feature I remember from Truecrypt was the ability to crash the system (using a user defined custom key) in an emergency shutdown to protect encrypted host data from seizure.

On Linux the way this would work is to enable the kernel feature for it and have a script execute the sysrq-trigger on demand - mapped to a key of the user's choice.

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/s2-kdump-configuration-testing.html

Then type the following commands at a shell prompt:

echo 1 > /proc/sys/kernel/sysrq
echo c > /proc/sysrq-trigger

Details

Impact
Normal

Event Timeline

HulaHoop created this task.Sep 2 2016, 1:37 AM

Tested this and I found it causes the VM to freeze and hang. Far from the emergency solution I was looking for.

HulaHoop closed this task as Invalid.Sep 2 2016, 1:53 AM

Host panic key instructions (or some day a package) would still be
desirable.

HulaHoop reopened this task as Review.Sep 20 2016, 4:29 AM

Apparently this feature is enabled on Debian hosts by default (so no package needed). Please test the key combination to confirm so I can document it.

To enable it:
echo "1" > /proc/sys/kernel/sysrq

To force crash:
echo "o" > /proc/sysrq-trigger

or press:
Alt + Printscreen + o


https://en.wikipedia.org/wiki/Magic_SysRq_key
http://www.thegeekstuff.com/2008/12/safe-reboot-of-linux-using-magic-sysrq-key/

Tested working without sysctl changes on Linux baremetal. Not supported on Xen.

https://forums.whonix.org/t/fde-emergency-feature-testing-requested/2985

wiki updated

HulaHoop closed this task as Resolved.Sep 23 2016, 8:43 PM
HulaHoop claimed this task.

On Qubes it results in kernel message: sysrq: SysRq : This sysrq operation is disabled.
Default value of /proc/sys/kernel/sysrq on Qubes dom0 is 16. Changing to 1 does not work either:

[1363616.422789] sysrq: SysRq : Power Off
[1363616.423456] xenbus: xenbus_dev_shutdown: backend/console/1069/0: Initialising != Connected, skipping
[1363621.427069] xenbus: xenbus_dev_shutdown: backend/vbd/1069/51760 timeout closing device
[1363626.430065] xenbus: xenbus_dev_shutdown: backend/vbd/1069/51744 timeout closing device
[1363631.434062] xenbus: xenbus_dev_shutdown: backend/vbd/1069/51728 timeout closing device
[1363636.437593] xenbus: xenbus_dev_shutdown: backend/vbd/1069/51712 timeout closing device
[1363636.437595] xenbus: xenbus_dev_shutdown: backend/console/1068/0: Initialising != Connected, skipping
[1363641.441056] xenbus: xenbus_dev_shutdown: backend/vbd/1068/51760 timeout closing device
[1363646.443064] xenbus: xenbus_dev_shutdown: backend/vbd/1068/51744 timeout closing device
[1363651.446038] xenbus: xenbus_dev_shutdown: backend/vbd/1068/51728 timeout closing device
[1363656.447016] xenbus: xenbus_dev_shutdown: backend/vbd/1068/51712 timeout closing device
[1363656.447016] xenbus: xenbus_dev_shutdown: backend/console/1067/0: Initialising != Connected, skipping
[1363661.448050] xenbus: xenbus_dev_shutdown: backend/vbd/1067/51760 timeout closing device
[1363666.451077] xenbus: xenbus_dev_shutdown: backend/vbd/1067/51744 timeout closing device
[1363671.454069] xenbus: xenbus_dev_shutdown: backend/vbd/1067/51728 timeout closing device
[1363676.457060] xenbus: xenbus_dev_shutdown: backend/vbd/1067/51712 timeout closing device
[1363676.457118] xenbus: xenbus_dev_shutdown: backend/console/711/0: Initialising != Connected, skipping
[1363681.460065] xenbus: xenbus_dev_shutdown: backend/vbd/711/51760 timeout closing device

And finally shutdown after timing out for every VM - 20s per VM. Not good, at least.
Sysrq-c makes dom0 frozen for some time (5s?) and then reboots. Also after changing sysctl setting.