Yes, rijndael_blockEncrypt supports it. It's already used in gbde(8) in g_bde_crypt_delete (sys/geom/bde/g_bde_crypt.c) via AES_encrypt.

Why have dump_encrypt take a src and dst parameter at all if we're only going to use it with both equal?

Nevermind, I see dump_encrypt() was changed to only take the one pointer. Sorry about that.

No, this is not an interrupt context, really. If you add something like 'NMI interrupt context' definition, then it would be it, but the definition is non-sensical, because it is really any point in the code. Spinlocks cannot protect such context against interrupted execution, and this is the main and fatal difference with the usual interrupt context definition.

That said, malloc/UMA data structures are protected by normal (AKA sleepable) mutexes and thus malloc even with M_NOWAIT flag cannot be used from an interrupt context. It can be used from the context of interrupt thread, but this is much harder requirement. In other words, malloc(9) in any form is highly undesirable in the dumping path.

So do you think that we should have static buffer for it or malloc this memory earlier?

Thanks Mariusz and Konstantin for discussing this issue. I changed the code to allocate a buffer during a dump device setup.

It would be better that way, as @def said to change. Note that drivers which handle dumpdev might have different idea of dump time, e.g. they could use busdma, which often allocates memory. Still, less reliance on the working kernel subsystems for dump, more reliable it is.

My opinion is that such non-trivial things from ddb/panic context should be performed by mechanism like kexec.

We'd like to write packed data and an ordinary structure can have gaps between fields. geli does similar thing in geom/eli/g_eli.h to encode metadata so it can be used by various architectures.

We'd like to write packed data and an ordinary structure can have gaps between fields

So use __packed from sys/cdefs.h.

Wouldn't it create bus errors on some architectures, e.g. SPARC [1]? It would be nice to have a way to save a crash dump generated by another architecture.

https://docs.oracle.com/cd/E60778_01/html/E60745/bjaby.html#OSSCGbjacr

Nope. The compiler is responsible for generating appropriately sized and aligned memory operations and truncating as needed.

(I don't think that particular piece of Solaris documentation is relevant, but maybe I'm missing something.)

This is a quote from the link I sent:

Note - If you use #pragma pack to align struct or union members on boundaries other than their natural boundaries, accessing these fields usually leads to a bus error on SPARC.

As far as I understand SPARC has strict alignment and it won't be possible to save a crash dump generated by an amd64 machine on a SPARC machine because of alignment differences but correct me if I'm wrong.

Does Solaris' #pragma pack have *any* relationship to FreeBSD/Clang(/GCC on Sparc64)'s __packed aka __attribute__((__packed__))? I don't think it does.

As far as I understand it, it's completely invalid for a compiler to produce assembly that will generate bus errors when the struct itself is aligned, even if packed. The standards don't say anything about packed, of course, so I don't have anything authoritative to point to here.

Strict alignment just means the compiler generates assembly instructions to read the aligned DWORD(s) and uses binary shifts or ANDs to extract the relevant field from the aligned memory read. There is no reason packed should generate bus errors. That would be a compiler bug.

Thanks for the explanation, Conrad. It's fixed now.