Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Key load error: Failed to get encryption root for dataset #9267

Closed
gusev-vitaliy opened this issue Aug 31, 2019 · 1 comment · Fixed by #9294
Closed

Key load error: Failed to get encryption root for dataset #9267

gusev-vitaliy opened this issue Aug 31, 2019 · 1 comment · Fixed by #9294
Assignees
@tcaputi
Labels
Component: Encryption "native encryption" feature Type: Defect Incorrect behavior (e.g. crash, hang)

Comments

@gusev-vitaliy
Copy link

gusev-vitaliy commented Aug 31, 2019 •
edited

System information

Type Version/Name
Distribution Name Fedora
Distribution Version 30
Linux Kernel 5.2.9-200.fc30
Architecture x86_64
ZFS Version 0.8.0-233_gc95396004
SPL Version 0.8.0-233_gc95396004

Describe the problem you're observing

After fixing zfsonlinux#6703 and #8976 dataset cannot be accessed due to lost encryptionroot. So that encrypted data also is lost. Output of run commands:

NAME       PROPERTY        VALUE        SOURCE
data/A2/B  encryption      aes-256-ccm  -
data/A2/B  encryptionroot  data/A       -

NAME       PROPERTY        VALUE        SOURCE
data/A2/B  encryption      aes-256-ccm  -
data/A2/B  encryptionroot  -            -

Key load error: Failed to get encryption root for 'data/A2/B'.

Describe how to reproduce the problem

dd if=/dev/zero of=/var/tmp/disk0 bs=1M count=64

zpool create data /var/tmp/disk0
echo 'C74AE2525459' | zfs create -o encryption=on -o keyformat=passphrase data/A

zfs snapshot data/A@1
zfs clone data/A@1 data/A2
zfs create data/A2/B

zfs promote data/A2
zfs get -t all -r encryption,encryptionroot data/A2/B # encryptionroot should be 'data/A2', but is 'data/A'

zfs destroy data/A
zfs get -t all -r encryption,encryptionroot data/A2/B # no encryptionroot anymore

zpool export data
zpool import -d /var/tmp/ data

zfs load-key data/A2/B

Include any warning/errors/backtraces from the system logs
@gusev-vitaliy gusev-vitaliy changed the title Key load error: Failed to get encryption root for $dataset Key load error: Failed to get encryption root for dataset Sep 2, 2019
@behlendorf behlendorf added Component: Encryption "native encryption" feature Type: Defect Incorrect behavior (e.g. crash, hang) labels Sep 3, 2019
tcaputi pushed a commit to datto/zfs that referenced this issue Sep 6, 2019
Fix clone handling with encryption roots
d0b3f89 
Currently, spa_keystore_change_key_sync_impl() does not recurse
into clones when updating encryption roots for either a call to
'zfs promote' or 'zfs change-key'. This can cause children of
these clones to end up in a state where they point to the wrong
dataset as the encryption root. It can also trigger ASSERTs in
some cases where the code checks reference counts on wrapping
keys. This patch fixes this issue by ensuring that this function
properly recurses into clones during processing.

Fixes: openzfs#9267

Signed-off-by: Tom Caputi <tcaputi@datto.com>
@tcaputi tcaputi mentioned this issue Sep 6, 2019
Merged
12 tasks
@tcaputi
Copy link
Contributor

tcaputi commented Sep 6, 2019

@gusev-vitaliy Please confirm that #9294 fixes your issue when you get a chance.

tcaputi pushed a commit to datto/zfs that referenced this issue Sep 6, 2019
Fix clone handling with encryption roots
b24c6a2 
Currently, spa_keystore_change_key_sync_impl() does not recurse
into clones when updating encryption roots for either a call to
'zfs promote' or 'zfs change-key'. This can cause children of
these clones to end up in a state where they point to the wrong
dataset as the encryption root. It can also trigger ASSERTs in
some cases where the code checks reference counts on wrapping
keys. This patch fixes this issue by ensuring that this function
properly recurses into clones during processing.

Fixes: openzfs#9267

Signed-off-by: Tom Caputi <tcaputi@datto.com>
behlendorf pushed a commit that referenced this issue Sep 16, 2019
@behlendorf
Fix clone handling with encryption roots
637f0c6 
Currently, spa_keystore_change_key_sync_impl() does not recurse
into clones when updating encryption roots for either a call to
'zfs promote' or 'zfs change-key'. This can cause children of
these clones to end up in a state where they point to the wrong
dataset as the encryption root. It can also trigger ASSERTs in
some cases where the code checks reference counts on wrapping
keys. This patch fixes this issue by ensuring that this function
properly recurses into clones during processing.

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Alek Pinchuk <apinchuk@datto.com>
Signed-off-by: Tom Caputi <tcaputi@datto.com>
Closes #9267 
Closes #9294
tonyhutter pushed a commit to tonyhutter/zfs that referenced this issue Dec 24, 2019
@tonyhutter
Fix clone handling with encryption roots
315366d 
Currently, spa_keystore_change_key_sync_impl() does not recurse
into clones when updating encryption roots for either a call to
'zfs promote' or 'zfs change-key'. This can cause children of
these clones to end up in a state where they point to the wrong
dataset as the encryption root. It can also trigger ASSERTs in
some cases where the code checks reference counts on wrapping
keys. This patch fixes this issue by ensuring that this function
properly recurses into clones during processing.

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Alek Pinchuk <apinchuk@datto.com>
Signed-off-by: Tom Caputi <tcaputi@datto.com>
Closes openzfs#9267
Closes openzfs#9294
tonyhutter pushed a commit to tonyhutter/zfs that referenced this issue Dec 27, 2019
@tonyhutter
Fix clone handling with encryption roots
b58a354 
Currently, spa_keystore_change_key_sync_impl() does not recurse
into clones when updating encryption roots for either a call to
'zfs promote' or 'zfs change-key'. This can cause children of
these clones to end up in a state where they point to the wrong
dataset as the encryption root. It can also trigger ASSERTs in
some cases where the code checks reference counts on wrapping
keys. This patch fixes this issue by ensuring that this function
properly recurses into clones during processing.

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Alek Pinchuk <apinchuk@datto.com>
Signed-off-by: Tom Caputi <tcaputi@datto.com>
Closes openzfs#9267
Closes openzfs#9294
tonyhutter pushed a commit that referenced this issue Jan 23, 2020
@tonyhutter
Fix clone handling with encryption roots
5986c5c 
Currently, spa_keystore_change_key_sync_impl() does not recurse
into clones when updating encryption roots for either a call to
'zfs promote' or 'zfs change-key'. This can cause children of
these clones to end up in a state where they point to the wrong
dataset as the encryption root. It can also trigger ASSERTs in
some cases where the code checks reference counts on wrapping
keys. This patch fixes this issue by ensuring that this function
properly recurses into clones during processing.

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Alek Pinchuk <apinchuk@datto.com>
Signed-off-by: Tom Caputi <tcaputi@datto.com>
Closes #9267
Closes #9294
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@tcaputi tcaputi

Labels
Component: Encryption "native encryption" feature Type: Defect Incorrect behavior (e.g. crash, hang)
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fix clone handling with encryption roots datto/zfs
3 participants
@behlendorf @tcaputi @gusev-vitaliy