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,
with
@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
If you have serious data that you encrypt and are concerned about, why would
you even have dump enabled? It's more for debugging a problem after all.
--
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
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 ar
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
--
openzfs-develop
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:
https://github.com/openzfs/openzfs/pull/
> 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
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 wil
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 modify
@ahrens can we make it an error to try to dumpify a zvol that has encryption
active, then? At least for now?
--
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-321332510
@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:
https://github.com/openzfs/openzfs/pull/124#issuecomment-
@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.
Reply
@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
I've subsequently had the panic I noticed happen on creation of an encrypted
zvol without the `checksum` property set, so I suspect it's not just a result
of that.
After hacking around that panic the way I outlined above (still not sure if it
was a great idea, but it lets me consistently make z
14 matches
Mail list logo