NAME

SYNOPSIS

DESCRIPTION

System administrators should typically configure dumpon in a persistent fashion using the rc.conf(5) variables dumpdev and dumpon_flags. For more information on this usage, see rc.conf(5).

Starting in FreeBSD 13.0, dumpon can configure a series of fallback dump devices. For example, an administrator may prefer netdump(4) by default, but if the netdump(4) service cannot be reached or some other failure occurs, they might choose a local disk dump as a second choice option.

IMPLEMENTATION NOTES

The loader(8) variable dumpdev may be used to enable early kernel core dumps for system panics which occur before userspace starts.

EXAMPLES

A public key can be extracted from the private key using the rsa(1) tool:

Once the RSA keys are created in a safe place, the public key may be moved to the untrusted netdump client machine. Now public.pem can be used by dumpon to configure encrypted kernel crash dumps:

It is recommended to test if the kernel saves encrypted crash dumps using the current configuration. The easiest way to do that is to cause a kernel panic using the ddb(4) debugger:

In the debugger the following commands should be typed to write a core dump and reboot:

After reboot savecore(8) should be able to save the core dump in the “dumpdir” directory, which is /var/crash by default:

Three files should be created in the core directory: info.#, key.# and vmcore_encrypted.# (where “#” is the number of the last core dump saved by savecore(8)). The vmcore_encrypted.# can be decrypted using the decryptcore(8) utility:

or shorter:

The vmcore.# can be now examined using kgdb(1):

or shorter:

The core was decrypted properly if kgdb(1) does not print any errors. Note that the live kernel might be at a different path which can be examined by looking at the kern.bootfile sysctl(8).

The dumpon rc(8) script runs early during boot, typically before networking is configured. This makes it unsuitable for configuring netdump(4) when the client address is dynamic. To configure netdump(4) when dhclient(8) binds to a server, dhclient-script(8) can be used to run dumpon(8). For example, to automatically configure netdump(4) on the vtnet0 interface, add the following to /etc/dhclient-exit-hooks.

case $reason in
BOUND|REBIND|REBOOT|RENEW)
	if [ "$interface" != vtnet0 ] || [ -n "$old_ip_address" -a \
	     "$old_ip_address" = "$new_ip_address" ]; then
		break
	fi
	if [ -n "$new_routers" ]; then
		# Take the first router in the list.
		gateway_flag="-g ${new_routers%% *}"
	fi
	# Configure as the highest-priority dump device.
	dumpon -i 0 -c $new_ip_address -s $server $gateway_flag vtnet0
	;;
esac

Be sure to fill in the server IP address and change the interface name if needed.

SEE ALSO

HISTORY

Support for encrypted kernel core dumps and netdump was added in FreeBSD 12.0.

AUTHORS

CAVEATS

Netdump does not automatically update the configured gateway if routing topology changes.

The size of a compressed dump or a minidump is not a fixed function of RAM size. Therefore, when at least one of these options is enabled, the dumpon utility cannot verify that the device has sufficient space for a dump. dumpon is also unable to verify that a configured netdumpd(8) server has sufficient space for a dump.

-Z requires a kernel compiled with the ZSTDIO kernel option. Similarly, -z requires the GZIO option.

BUGS

SECURITY CONSIDERATIONS

RSA keys smaller than 1024 bits are practical to factor and therefore weak. Even 1024 bit keys may not be large enough to ensure privacy for many years, so NIST recommends a minimum of 2048 bit RSA keys. As a seatbelt, dumpon prevents users from configuring encrypted kernel dumps with extremely weak RSA keys. If you do not care for cryptographic privacy guarantees, just use dumpon without specifying a -k pubkey option.

This process is sandboxed using capsicum(4).