> 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:
https://github.com/openzfs/openzfs/pull/124#issuecomment-321295975
------------------------------------------
openzfs-developer
Archives: 
https://openzfs.topicbox.com/groups/developer/discussions/T1625245905c55186-M9bf7f25356405e44715098a9
Powered by Topicbox: https://topicbox.com

Reply via email to