Encrypted kernel core dumps with compression: fix writing of final block

[sigsys_gmail.com]

Summary

The final "residual" block is being written unencrypted. This makes decryptcore(8) garble it. Which makes trying to decompress with gzip/zstd error out when reaching the end (it's still possible to decompress most of the file though).

IIUC, there can only be a residual block like this when using compression.

I changed this code to be more like _dump_append() and now I don't get any more decompression errors (tried both with local partition dumps and netdumps).

[cem]

Thanks for the report! Nice find.

sys/kern/kern_shutdown.c

1683–1691 ↗

(On Diff #76230)

How about just using _dump_append()? It seems like it will do the same thing without duplicating the ekcd or not logic. The padding gets included in dumpoff but can just be subtracted out.

[sigsys_gmail.com]

Yeah that's better.

I also tested this just in case. Everything still decompressing fine.

[markj]

I'm surprised that you are able to decrypt compressed cores. Doesn't EKCD assume that the vmcore size is a multiple of the AES block size?

sys/kern/kern_shutdown.c

1683 ↗

(On Diff #76234)

This looks ok to me, but I'd prefer to also see Conrad's suggestion of zeroing out the unused portion of the buffer before writing.

[markj]

In D26188#581994, @markj wrote:

I'm surprised that you are able to decrypt compressed cores. Doesn't EKCD assume that the vmcore size is a multiple of the AES block size?

I forgot that EKCD supports chacha20 as well, which presumably doesn't have this limitation.

[cem]

In D26188#581996, @markj wrote:

In D26188#581994, @markj wrote:

I'm surprised that you are able to decrypt compressed cores. Doesn't EKCD assume that the vmcore size is a multiple of the AES block size?

I forgot that EKCD supports chacha20 as well, which presumably doesn't have this limitation.

It did have that limitation before Chacha20 mode was added. :-)

Edit: In fact I think even the AES mode could handle compressed input basically fine; the length is external and reflects the compressed size. We're already rounding up to the block size here so the underlying dump_write() doesn't reject the data. None of our dump modes has authentication or an authenticated length so the usual concerns around safely padding AES inputs to block size is irrelevant, AFAIK.

[sigsys_gmail.com]

Added a bzero() in kerneldumpcomp_write_cb(). Seemed a bit better to do it there. Not sure though.

The code is hard to follow, but yeah from what I understand, I think that compressed AES-CBC dumping could have worked with just savecore/netdumpd changes. It would have had to know to preserve the final cipher block when extracting the variable-sized dump, and then decryptcore would have had to trim it.

But it's much cleaner with an encryption method that doesn't require any of that now.

[cem]

That location looks better to me, too. Thanks!