In D37359#850297, @kib wrote:

My preference, as you could see from the earlier response, is to have the patch in reverse direction, using &a_gen instead of cast. Cast means that you fight the type system, not utilizing it.

Anyway, I do not intend to block either change, go ahead with something.

Use an a_gen field instead of casting to vop_generic_args.

In D46016#1049086, @kp wrote:

Looks good to me, just needs slight tweaking of the commit message.

I'd be tempted to leave out the second paragraph explaining how CHERI objects to this because it's still wrong on non-CHERI hardware (even if it does just work) but I'll leave that up to you.

Update the commit message to clarify why the broadcast address is not set.

Remove ifaddr_ad() and move its logic to callers.

Thanks for reviews!

@brooks @oshogbo Do you have any suggestions who should review this? It is not clear to me based on the commit history.

@brooks @oshogbo Do you have any suggestions who should review this? It is not clear to me based on the commit history.

In D37359#849134, @kib wrote:

I believe all uses of &ap->a_gen are mine, and the casts are historic.
Isn't it more reliable to avoid cast and explicitly take the address of the generic member? Either case depends on the generic being the first member of the vop_arg struct for now.

Anyway, I am curious about your choice of the cast, Is it due to the calculated number of each case in the source?

Remove the style change.

In D36402#836213, @jhb wrote:

Hmm, does cscope fail because the directory name doesn't exist? (I confess to always using ALL_ARCH=yes myself)

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.