> Are you serious? I would definitely not want to expose plaintext dumps of
> kernel memory if I'm otherwise encrypting the entire pool. (I don't know if
> encryption keys can be dumped, but if so, that's obviously a huge problem)
I am, unfortunately, serious - there's a big tension here between the fact that
we have to be able to write to dump during a panic and not wanting to write out
plaintext data on disk ever. I'm not sure that we can confidently say we're
always going to be able to use all the crypto bits in panic context - that code
is extremely special so that it can keep working even in the face of all kinds
of chaos: even certain kinds of storage driver malfunctions.
The dump code has to be kept super simple or it loses that reliability.
We can shred (overwrite randomly and zero) all that space after we come back
up, or else maybe we could build some extremely simplified code specifically
for encrypting dumps, but I mean... as I said, we have previously decided that
even computing a Fletcher4 is too complex to have in that code.
I really think the easiest option will be to just make dump unencrypted and
plaster a big warning sign all over it that it might ruin your plans to keep
all plain data off disk if you include e.g. ARC in your dumped memory (which
isn't by default as I understand it, but other kinds of transient plaintext in
kernel memory will be of course)
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Powered by Topicbox: https://topicbox.com