OS-8085: Support Encrypted Dump


Issue Type:New Feature
Priority:4 - Normal
Created at:2020-01-06T18:58:06.996Z
Updated at:2020-01-13T20:30:30.700Z


Created by:Former user
Reported by:Former user
Assigned to:Former user


Fixed: A fix for this issue is checked into the tree and tested.
(Resolution Date: 2020-01-13T20:30:30.692Z)

Fix Versions

2020-01-16 Jerk Store (Release Date: 2020-01-16)

Related Issues

Related Links




OS-7828 added kernel support for encrypted crash dumps. We should hook in the feature into SmartOS.

While this is technically independent of EDAR, we'll (initially at least) only enable this for EDAR enabled CNs. That simplifies the implementation:

During CN setup, we create key for the dump device as /var/crash/volatile/keyfile. The changes to perform this will be done as TRITON-1330 for the sdc-headnode repository (by joysetup.sh). Since we are only looking to enable this for EDAR nodes, the keyfile itself will be protected by the (almost) whole-pool encryption provided by EDAR (i.e. the file will reside on an encrypted dataset).

This change will modify svc-dumpadm to look for /var/crash/volatile/keyfile and when present, modify the dumpadm and savecore invocations by svc-dumpadm to use the keyfile.

Since we are only supporting enabling this during CN setup w/ an EDAR node, there should be no concerns about booting between unsupported releases -- we can only successfully setup a encrypted CN if it is running an EDAR supported image, and you cannot toggle the encrypted/unencrypted status of a CN after setup (you must factory-reset the node instead).


Comment by Former user
Created at 2020-01-13T17:17:15.857Z

To test, I first verified an EDAR test CN (with this change) had encrypted dump setup:

[root@00-1b-21-c1-4a-20 (emy-9) ~]# dumpadm
      Dump content: kernel pages
       Dump device: /dev/zvol/dsk/zones/dump (dedicated)
Savecore directory: /var/crash/volatile
  Savecore enabled: yes
   Save compressed: on
    Dump encrypted: yes

I also verified /var/crash/volatile/keyfile existed.

I then forced a panic:

[root@00-1b-21-c1-4a-20 (emy-9) ~]# mdb -kw
Loading modules: [ unix genunix specfs dtrace mac cpu.generic uppc pcplusmp scsi_vhci ufs ip hook neti sockfs arp usba uhci mm sd stmf_sbd stmf zfs lofs idm cpc logindmux ptm sppp nfs ]
> rootdir/Z 0
rootdir:        0xfffffe8673c08900      =       0x0

And verified the resulting dump was readable:

[root@00-1b-21-c1-4a-20 (emy-9) /var/crash/volatile]# savecore -f vmdump.0
savecore: System dump time: Mon Jan 13 16:23:33 2020

savecore: saving system crash dump in /var/crash/volatile/{unix,vmcore}.0
Constructing namelist /var/crash/volatile/unix.0
Constructing corefile /var/crash/volatile/vmcore.0
 2:44 100% done: 3332036 of 3332036 pages saved
[root@00-1b-21-c1-4a-20 (emy-9) /var/crash/volatile]# mdb unix.0 vmcore.0
Loading modules: [ unix genunix specfs dtrace mac cpu.generic uppc pcplusmp scsi_vhci ufs ip hook neti sockfs arp usba uhci mm sd stmf_sbd stmf zfs lofs random idm cpc logindmux ptm sppp nfs ]
> ::status
debugging crash dump vmcore.0 (64-bit) from 00-1b-21-c1-4a-20
operating system: 5.11 joyent_20200108T054536Z (i86pc)
git branch: zfs-crypto
git rev: d187f77f0ee027507a6742a511f39f07f3579a36
image uuid: (not set)
panic message: BAD TRAP: type=e (#pf Page fault) rp=fffffe00b8b3da30 addr=0 occurred in module "unix" due to a NULL pointer dereference
dump content: kernel pages only

Comment by Jira Bot
Created at 2020-01-13T20:29:00.716Z

illumos-joyent commit f4b68d4a2e8e136cb874536424c3a46c2a39b5d4 (branch master, by Jason King)

OS-8085 Support Encrypted Dump (#249)

Reviewed by: Dan McDonald <danmcd@joyent.com>
Reviewed by: Mike Gerdts <mike.gerdts@joyent.com>
Approved by: Dan McDonald <danmcd@joyent.com>