This update fixes typos, style and changes die() to write messages to stderr.

I'm using a script to test kernel dumps in bhyve. It exercises combinations of minidumps vs. full dumps, compression, encryption, and dump device sector size.

This revision fixes alignment of the kdc_dumpkey member of the kerneldumpcrypto structure and uses roundup2 macro to round a kernel dump key size.

The patch was updated to fix two problems:

• Use a packed structure instead of writing a kernel dump key structure byte per byte;
• Allocate require memory using malloc(9) when it's safe to do that which is during a dump device setup.

I've merged the changes from HEAD. The current patch is against r303588 [1]. The main changes include:

• ambrisko submitted a patch to write crash dumps on dump devices with a block size other than 512B. EKCD should be compatible with these changes now;
• DIOCSKERNELDUMP_FREEBSD10 became DIOCSKERNELDUMP_FREEBSD11 as we already have FreeBSD 12.0-CURRENT;
• DIOCSKERNELDUMP ioctl has a new number as a new DIOCZONECMD ioctl was introduced in [3].

Thanks for the review. I sent some replies to the inline comments.

In D4712#124230, @cem wrote:

In D4712#123472, @def wrote:

In D4712#99936, @kib wrote:

Still, I have a question. You choice was to modify the dump code, which resulted in spreading the patch over the MI dump and all MD minidump code. Semi-obvious alternate approach is to introduce a geom which would write the generated encrypted symmetric key into the first block and write data block N into encrypted block N+1 of the underlying provider. Then you do not have to touch the kernel dump code at all.

I agree with kib@. It would be nice not to have separate userspace tools here.
In fact we already have encrypted GEOM providers (g_eli, ...). All we lack is a way to dump core through them—maybe? I'm not even sure we lack that.

The kerneldumpkey structure has an arbitrary size.

I am sure this is not a problem in practice. An AES key is far smaller than 512 bytes.

In D4712#99936, @kib wrote:

I looked over the patch, it looks fine to me.
Still, I have a question. You choice was to modify the dump code, which resulted in spreading the patch over the MI dump and all MD minidump code. Semi-obvious alternate approach is to introduce a geom which would write the generated encrypted symmetric key into the first block and write data block N into encrypted block N+1 of the underlying provider. Then you do not have to touch the kernel dump code at all.
Is it possible technically ?

I have made some inline comments. I think a partial vmcore shouldn't be removed because another panic might happen before a user tries to run savecore manually again.