bugzilla-daemon at defect.opensolaris.org
2008-Mar-28 01:44 UTC
[Bug 882] New: loading an existing pool key causes and existing dataset to failed crypto
http://defect.opensolaris.org/bz/show_bug.cgi?id=882
Summary: loading an existing pool key causes and existing dataset
to failed crypto
Classification: Development
Product: zfs-crypto
Version: unspecified
Platform: Other
OS/Version: Solaris
Status: NEW
Severity: major
Priority: P2
Component: other
AssignedTo: darrenm at opensolaris.org
ReportedBy: ajscarp at yahoo.com
QAContact: hua.tang at sun.com
CC: zfs-crypto-discuss at opensolaris.org
Estimated Hours: 0.0
When a dataset is first created it looks to have the dataset key. But when the
pool key is unloaded, which causes the dataset to be unmounted, then loaded,
which causes the dataset to be mounted, there is a key failure because the
crypto fails in wrapping..
I am unsure if the wrapping error is from the act of copying or the
''zpool key
-l'' since it''s a console message..
bash-3.2# zpool create -f -o keysource=passphrase,prompt tank c0t0d0s6
Enter passphrase for ''tank'':
Enter again:
bash-3.2# zfs create -o encryption=on tank/fish
bash-3.2# cp /core /tank/fish
bash-3.2# ls -l /tank/fish
total 14349
-rw------- 1 root root 7327547 Mar 27 18:36 core
bash-3.2# zpool key -u
bash-3.2# zpool key -l
Enter passphrase for ''tank'':
bash-3.2# cp /core /tank/fish/core2
Mar 27 18:35:52 cag-v240b zfs: [ID 120330 kern.warning] WARNING:
zio_crypt_unwrap_key failed 10
cp: cannot create /tank/fish/core2: Resource temporarily unavailable
bash-3.2# zfs get all tank/fish
NAME PROPERTY VALUE SOURCE
tank/fish type filesystem -
tank/fish creation Thu Mar 27 18:36 2008 -
tank/fish used 7.02M -
tank/fish available 1.42G -
tank/fish referenced 7.02M -
tank/fish compressratio 1.00x -
tank/fish mounted yes -
tank/fish quota none default
tank/fish reservation none default
tank/fish recordsize 128K default
tank/fish mountpoint /tank/fish default
tank/fish sharenfs off default
tank/fish checksum sha256+mac local
tank/fish compression off default
tank/fish atime on default
tank/fish devices on default
tank/fish exec on default
tank/fish setuid on default
tank/fish readonly off default
tank/fish zoned off default
tank/fish snapdir hidden default
tank/fish aclmode groupmask default
tank/fish aclinherit secure default
tank/fish canmount on default
tank/fish shareiscsi off default
tank/fish xattr on default
tank/fish copies 1 default
tank/fish version 3 -
tank/fish utf8only off -
tank/fish normalization none -
tank/fish casesensitivity sensitive -
tank/fish vscan off default
tank/fish nbmand off default
tank/fish sharesmb off default
tank/fish refquota none default
tank/fish refreservation none default
tank/fish encryption on local
tank/fish keysource default
tank/fish keyscope pool default
tank/fish keystatus available -
bash-3.2# modinfo | grep aes
241 7b35e000 8e60 - 1 aes (AES Kernel SW Provider)
--
Configure bugmail: http://defect.opensolaris.org/bz/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
bugzilla-daemon at defect.opensolaris.org
2008-Apr-02 16:46 UTC
[Bug 882] loading an existing pool key causes and existing dataset to failed crypto
http://defect.opensolaris.org/bz/show_bug.cgi?id=882
Darren J Moffat <darrenm at opensolaris.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ACCEPTED
--- Comment #1 from Darren J Moffat <darrenm at opensolaris.org>
2008-04-02 09:46:40 ---
1 -> dsl_crypto_key_gen
1 <- dsl_crypto_key_gen return(0)
2 -> zio_encrypt_data crypt=4
2 -> zio_crypt_key_lookup
2 -> spa_keystore_find 40
2 -> spa_keystore_compare
2 <- spa_keystore_compare
2 <- spa_keystore_find
2 -> dsl_prop_get_ds_locked keyscope -1098976359992
2 <- dsl_prop_get_ds_locked
2 <- zio_crypt_key_lookup return(0x0)
2 <- zio_encrypt_data return(13)
The above dtrace fragment shows that we looked up the key for dataset 40 (the
one we are creating) because crypt=4 However the command we ran was:
# zfs create -o encryption=off tank/pp/a
Need to find out why we ended up in zio_encrypt_data() with crypt=4 when at the
CLI we specified encryption=off explicitly.
--
Configure bugmail: http://defect.opensolaris.org/bz/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
bugzilla-daemon at defect.opensolaris.org
2008-Apr-02 16:48 UTC
[Bug 882] loading an existing pool key causes and existing dataset to failed crypto
http://defect.opensolaris.org/bz/show_bug.cgi?id=882 --- Comment #2 from Darren J Moffat <darrenm at opensolaris.org> 2008-04-02 09:48:02 --- That last comment doesn''t belong in this bug - OOPS -- Configure bugmail: http://defect.opensolaris.org/bz/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
bugzilla-daemon at defect.opensolaris.org
2008-Apr-03 11:26 UTC
[Bug 882] loading an existing pool key causes and existing dataset to failed crypto
http://defect.opensolaris.org/bz/show_bug.cgi?id=882
Darren J Moffat <darrenm at opensolaris.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ACCEPTED |CLOSED
Resolution| |FIXED
--- Comment #3 from Darren J Moffat <darrenm at opensolaris.org>
2008-04-03 04:26:00 ---
Fixed (and verified) with the new per spa in memory keystore.
--
Configure bugmail: http://defect.opensolaris.org/bz/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.