> 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
