Emergency Crash Script to Protect Host FDE

[phabricator-migrator]

Information

ID: 553
PHID: PHID-TASK-hjxtpmlmudn7crk2qmnv
Author: HulaHoop
Status at Migration Time: resolved
Priority at Migration Time: Wishlist

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.

32.2.4. Testing the Configuration Red Hat Enterprise Linux 6 | Red Hat...

Then type the following commands at a shell prompt:

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

Comments

---

HulaHoop

2016-09-01 23:52:50 UTC

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

---

Patrick

2016-09-02 00:03:01 UTC

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

---

HulaHoop

2016-09-20 02:29:16 UTC

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

---

Magic SysRq key - Wikipedia
Safe Reboot Of Linux Using Magic SysRq Key

---

HulaHoop

2016-09-23 18:43:01 UTC

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

Full Disk Encryption (FDE) Emergency Shutdown Feature - Testing Requested

wiki updated

---

marmarek

2016-09-23 19:43:57 UTC

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.