On Sat, 10 Dec 2016 21:53:43 +0100 Konrad Witaszczyk <[email protected]> wrote:
> On 12/10/2016 20:20, Justin Hibbits wrote: > > On Dec 10, 2016, at 10:20 AM, Konrad Witaszczyk wrote: > >> Author: def > >> Date: Sat Dec 10 16:20:39 2016 > >> New Revision: 309818 > >> URL: https://svnweb.freebsd.org/changeset/base/309818 > >> > >> Log: > >> Add support for encrypted kernel crash dumps. > >> > >> Changes include modifications in kernel crash dump routines, > >> dumpon(8) and savecore(8). A new tool called decryptcore(8) was > >> added. > >> > >> A new DIOCSKERNELDUMP I/O control was added to send a kernel > >> crash dump configuration in the diocskerneldump_arg structure to > >> the kernel. The old DIOCSKERNELDUMP I/O control was renamed to > >> DIOCSKERNELDUMP_FREEBSD11 for > >> backward ABI compatibility. > >> > >> dumpon(8) generates an one-time random symmetric key and encrypts > >> it using an RSA public key in capability mode. Currently only > >> AES-256-CBC is supported but EKCD was designed to implement > >> support for other algorithms in the future. The public key is > >> chosen using the -k flag. The dumpon rc(8) script can do this > >> automatically during startup using the dumppubkey rc.conf(5) > >> variable. Once the keys are calculated dumpon sends them to the > >> kernel via DIOCSKERNELDUMP I/O control. > >> > >> When the kernel receives the DIOCSKERNELDUMP I/O control it > >> generates a random IV and sets up the key schedule for the > >> specified algorithm. Each time the kernel tries to write a crash > >> dump to the dump device, the IV is replaced by a SHA-256 hash of > >> the previous value. This is intended to make a possible > >> differential cryptanalysis harder since it is possible to write > >> multiple crash dumps without reboot by repeating the following > >> commands: # sysctl debug.kdb.enter=1 > >> db> call doadump(0) > >> db> continue > >> # savecore > >> > >> A kernel dump key consists of an algorithm identifier, an IV and > >> an encrypted symmetric key. The kernel dump key size is included > >> in a kernel dump header. The size is an unsigned 32-bit integer > >> and it is aligned to a block size. The header structure has 512 > >> bytes to match the block size so it was required to > >> make a panic string 4 bytes shorter to add a new field to the > >> header structure. If the kernel dump key size in the header is > >> nonzero it is assumed that the kernel dump key is placed after the > >> first header on the dump device and the core > >> dump is encrypted. > >> > >> Separate functions were implemented to write the kernel dump > >> header and the kernel dump key as they need to be unencrypted. The > >> dump_write function encrypts > >> data if the kernel was compiled with the EKCD option. Encrypted > >> kernel textdumps > >> are not supported due to the way they are constructed which makes > >> it impossible to use the CBC mode for encryption. It should be > >> also noted that textdumps don't > >> contain sensitive data by design as a user decides what > >> information should be dumped. > >> > >> savecore(8) writes the kernel dump key to a key.# file if its > >> size in the header > >> is nonzero. # is the number of the current core dump. > >> > >> decryptcore(8) decrypts the core dump using a private RSA key and > >> the kernel dump key. This is performed by a child process in > >> capability mode. If the decryption was not successful the parent > >> process removes a partially decrypted core dump. > >> > >> Description on how to encrypt crash dumps was added to the > >> decryptcore(8), dumpon(8), rc.conf(5) and savecore(8) manual pages. > >> > >> EKCD was tested on amd64 using bhyve and i386, mipsel and sparc64 > >> using QEMU. The feature still has to be tested on arm and arm64 as > >> it wasn't possible to run > >> FreeBSD due to the problems with QEMU emulation and lack of > >> hardware. > >> > >> Designed by: def, pjd > >> Reviewed by: cem, oshogbo, pjd > >> Partial review: delphij, emaste, jhb, kib > >> Approved by: pjd (mentor) > >> Differential Revision: https://reviews.freebsd.org/D4712 > >> > >> Added: > >> head/sbin/decryptcore/ > >> head/sbin/decryptcore/Makefile (contents, props changed) > >> head/sbin/decryptcore/decryptcore.8 (contents, props changed) > >> head/sbin/decryptcore/decryptcore.c (contents, props changed) > >> Modified: > >> head/etc/defaults/rc.conf > >> head/etc/rc.d/dumpon > >> head/sbin/Makefile > >> head/sbin/dumpon/Makefile > >> head/sbin/dumpon/dumpon.8 > >> head/sbin/dumpon/dumpon.c > >> head/sbin/savecore/savecore.8 > >> head/sbin/savecore/savecore.c > >> head/share/man/man5/rc.conf.5 > >> head/sys/amd64/amd64/minidump_machdep.c > >> head/sys/arm/arm/minidump_machdep.c > >> head/sys/arm64/arm64/minidump_machdep.c > >> head/sys/conf/NOTES > >> head/sys/conf/files > >> head/sys/conf/options > >> head/sys/ddb/db_textdump.c > >> head/sys/dev/null/null.c > >> head/sys/geom/geom_dev.c > >> head/sys/i386/i386/minidump_machdep.c > >> head/sys/kern/kern_dump.c > >> head/sys/kern/kern_shutdown.c > >> head/sys/mips/mips/minidump_machdep.c > >> head/sys/sparc64/sparc64/dump_machdep.c > >> head/sys/sys/conf.h > >> head/sys/sys/disk.h > >> head/sys/sys/kerneldump.h > > > > Nice! Any reason you left out PowerPC from this list though? > > The architectures that I listed implement separate minidump functions > in their MD code. I had to change them to implement EKCD. ppc and > pc98 are not the case and we don't have minidumps in riscv yet. It > means that EKCD should also work on ppc. > Of course all architectures supported by FreeBSD should be verified. > However it is mandatory to test all changes in MD code. > Ah, thanks for the explanation. I hadn't read through the diff, only saw sys/powerpc wasn't on there, but from your explanation it's already handled implicitly by the generic full dump change. Thanks! - Justin _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "[email protected]"
