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.
Then type the following commands at a shell prompt:
echo 1 > /proc/sys/kernel/sysrq
echo c > /proc/sysrq-trigger
Tested this and I found it causes the VM to freeze and hang. Far from the emergency solution I was looking for.
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
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.