I totally understand wanting to have encrypted dumps.
However, the current designs of dump and encryption are incompatible.
Specifically: when dumping we do not modify any ZFS data structures; instead we
just overwrite pre-allocated space. Therefore dump doesn't have checksums,
doesn't
> 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
@arekinath Yes, it should be an error to dumpify (i.e. disable
checksums/encryption on) a zvol that has encryption on.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@ahrens Ok. That works for me. Is the change to make that an error going to go
in this repo and this PR? Or be a separate but we file and integrate just in
illumos when we merge this up (seeing as it's illumos specific)?
--
You are receiving this because you are subscribed to this thread.
I debugged the crash that I got a bit further, in case it's helpful: When we
died we're trying to encrypt a dnode, and `zio_crypt_init_uios_dnode` is
setting `total_len = 0` (as well as `*no_crypt = B_TRUE`). In
`zio_do_crypt_data` we carry on to call `zio_do_crypt_uio` after this returns,
@arekinath
> And I think the dump zvol should not be encrypted
Are you serious? I would definitely not want to expose plaintext dumps of
kernel memory if I'm otherwise encrypting the entire pool.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly
Because dumps are useful for post-mortem debugging of production failures as
well; OmniOS for example creates a dump device by default. Even if not, it's
not nice to have a "trap" like that where the user thinks they're encrypting
the entire disk but crash dumps happen to be special.
--
You
@arekinath The panic should be fixed in this PR.
--
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-321363891
--
openzfs-developer
Actually I'm gonna correct myself there a bit, I'm pretty sure after more
reading that the thing that was too complex to have in dump code was not so
much computing Fletcher4 itself, as updating the actual pool structure and
committing a new txg (but hopefully someone who knows more about it
Closed #443 via 4dd3b53234a873997120dcaa3e433209467d0704.
--
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/443#event-1199122741
--
I've restarted the tests. I think the GitHub API was returning an error, which
resulted in the CI failing; looks like it's working now.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
11 matches
Mail list logo
