Kernel Crash Dump

mag

mag

Hi

My only question is: Do the crash dumps work if the swap space is encrypted with geli ?
I mean is it possible to get a crash dump core file after a panic if full disk encryption is deployed ?

Because the developers handbook states the following:

Before the kernel will dump the contents of its physical memory to a dump device, a dump device must be configured. A dump device is specified by using the dumpon(8) command to tell the kernel where to save kernel crash dumps. The dumpon(8) program must be called after the swap partition has been configured with swapon(8). This is normally handled by setting the dumpdev variable in rc.conf(5) to the path of the swap device (the recommended way to extract a kernel dump) or AUTO to use the first configured swap device.​

My /etc/rc.conf configuration:
Code: 
dumpdev="AUTO"
dumpdir="/var/crash"
savecore_enable="YES"

My /etc/fstab configuration:
Code: 
/dev/ada0p4.eli         none    swap    sw              0       0

Sorry if my question is really stupid.

Thank you
 
My problem is not how to generate a kernel panic.

Recently, i was trying to do the following:
  1. Mount a usb flash drive.
  2. rm something from inside.
  3. Aggressively remove the usb drive before the rm has finished.
  4. Re-enter the usb drive without mounting it this time.
  5. And then md5 /dev/da0 causes a kernel panic.
I want to explore the kernel crash but under my current configuration there's nothing under /var/crash
 
Of course before during panic i can't do anything, but after booting i don't see anything.
The only file that exists in /var/crash is called "minfree", it is an ASCII text file and it contains
the value 2048 in text.
 
I observe the same issue with FreeBSD-12.0. But I don't think my swap space is encrypted. But still, I don't see the core dump collected. I just see the "minfree" file in /var/crash. Any reasons?

Bash: 
root@freebsd_12_0_rel:~ # uname -a
FreeBSD freebsd_12_0_rel 12.0-RELEASE FreeBSD 12.0-RELEASE r341666 GENERIC  amd64

root@freebsd_12_0_rel:~ # swapinfo
Device          1K-blocks     Used    Avail Capacity
/dev/ada0p3       3944436        0  3944436     0%

root@freebsd_12_0_rel:~ # cat /etc/fstab
# Device        Mountpoint      FStype  Options Dump    Pass#
/dev/ada0p2     /               ufs     rw      1       1
/dev/ada0p3     none            swap    sw,late 0       0

/etc/rc.conf
# Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable
dumpdev="/dev/ada0p3"
dumpdir="/var/crash"
savecore_enable="YES"

I tried setting dumpdev="AUTO" as well. No luck.
 
How much memory does the machine have and how big is the swap partition?
 
This machine has 128GB of total memory and swap partition is around 3.8GB.

Bash: 
# top
Mem: 8036K Active, 12M Inact, 458M Wired, 35M Buf, 124G Free
Swap: 3852M Total, 3852M Free

So, shouldn't this be enough for minidump?
 
That's going to depend on the amount of memory being used by the kernel at that time. It's likely your swap is simply too small even for a minidump. I have never used it myself but a netdump(4) might work better for you.
 
What does not get clear to me from these discussions:
Is the dump written to the encrypted swap device or to the unencrypted swap device?
(Because, if it is written to the unencrypted device, one would have a problem afterwards.)

In my case, the difficulty is that my SATA controller is not supported for dumps, so I cannot dump onto the swap partition.
Using a different disk does not work either, because I do power-down the disks on inactivity, and it is not supported to dump onto a disk after SCSI STOP UNIT (this applies also to USB-sticks).

So, I need to create a specific dump device, that gets exluded from the power-down daemon.
 
So I tried it out:

First and most important of all: the dump is (by default, see below) written unencrypted.

Why is this a problem? The dump contains all the active kernel variables, including keys, passwords - it probably contains your decrypted geli masterkeys straight ahead. And, if that dump gets written to the swap device, it does not get deleted again (until perchance you use enough swap to overwrite the whole area).

The essential question is not if your dump successfully arrives in /var/crash so that you can use it. The essential question is: has the dump been dumped to the swapspace beforehand? Because if it has, then you have a problem and your system is already compromised.

This means, if you got a dump, no matter if it was successfully copied or not, you should soon go into maintenance mode and overwrite your swap with random bytes - otherwise you can just forget about your encrypted swapspace, because it is quite useless.

This problem is addressed in Rel. 12. Here a new functionality appears that allows to write encrypted dumps. (A proper key to encrypt them has to be defined beforehand.) See respective manpages dumpon(8), decryptcore(8).
This feature has nothing to do with geli, it is an independent functionality.

Concerning geli: at least in 11.2 it does not work to have encrypted swapspace and use dumpon="AUTO". Instead, the underlying provider has to be configured. E.g:
/etc/fstab:
/dev/ada0p4.eli none swap sw 0 0
/etc/rc.conf:
dumpon="/dev/ada0p4"
 
You must log in or register to reply here.
Back
Top