diff options
author | David Howells <dhowells@redhat.com> | 2015-10-21 14:04:48 +0100 |
---|---|---|
committer | David Howells <dhowells@redhat.com> | 2015-10-21 15:18:36 +0100 |
commit | 146aa8b1453bd8f1ff2304ffb71b4ee0eb9acdcc (patch) | |
tree | a89ef2cd2e8029b0c09a58739cca0e7e2e68f4db /Documentation/crypto | |
parent | 4adc605edc5f744dcf432241b5996ff6a13d868c (diff) | |
download | talos-obmc-linux-146aa8b1453bd8f1ff2304ffb71b4ee0eb9acdcc.tar.gz talos-obmc-linux-146aa8b1453bd8f1ff2304ffb71b4ee0eb9acdcc.zip |
KEYS: Merge the type-specific data with the payload data
Merge the type-specific data with the payload data into one four-word chunk
as it seems pointless to keep them separate.
Use user_key_payload() for accessing the payloads of overloaded
user-defined keys.
Signed-off-by: David Howells <dhowells@redhat.com>
cc: linux-cifs@vger.kernel.org
cc: ecryptfs@vger.kernel.org
cc: linux-ext4@vger.kernel.org
cc: linux-f2fs-devel@lists.sourceforge.net
cc: linux-nfs@vger.kernel.org
cc: ceph-devel@vger.kernel.org
cc: linux-ima-devel@lists.sourceforge.net
Diffstat (limited to 'Documentation/crypto')
-rw-r--r-- | Documentation/crypto/asymmetric-keys.txt | 27 |
1 files changed, 14 insertions, 13 deletions
diff --git a/Documentation/crypto/asymmetric-keys.txt b/Documentation/crypto/asymmetric-keys.txt index b7675904a747..8c07e0ea6bc0 100644 --- a/Documentation/crypto/asymmetric-keys.txt +++ b/Documentation/crypto/asymmetric-keys.txt @@ -186,7 +186,7 @@ and looks like the following: const struct public_key_signature *sig); }; -Asymmetric keys point to this with their type_data[0] member. +Asymmetric keys point to this with their payload[asym_subtype] member. The owner and name fields should be set to the owning module and the name of the subtype. Currently, the name is only used for print statements. @@ -269,8 +269,7 @@ mandatory: struct key_preparsed_payload { char *description; - void *type_data[2]; - void *payload; + void *payload[4]; const void *data; size_t datalen; size_t quotalen; @@ -283,16 +282,18 @@ mandatory: not theirs. If the parser is happy with the blob, it should propose a description for - the key and attach it to ->description, ->type_data[0] should be set to - point to the subtype to be used, ->payload should be set to point to the - initialised data for that subtype, ->type_data[1] should point to a hex - fingerprint and quotalen should be updated to indicate how much quota this - key should account for. - - When clearing up, the data attached to ->type_data[1] and ->description - will be kfree()'d and the data attached to ->payload will be passed to the - subtype's ->destroy() method to be disposed of. A module reference for - the subtype pointed to by ->type_data[0] will be put. + the key and attach it to ->description, ->payload[asym_subtype] should be + set to point to the subtype to be used, ->payload[asym_crypto] should be + set to point to the initialised data for that subtype, + ->payload[asym_key_ids] should point to one or more hex fingerprints and + quotalen should be updated to indicate how much quota this key should + account for. + + When clearing up, the data attached to ->payload[asym_key_ids] and + ->description will be kfree()'d and the data attached to + ->payload[asm_crypto] will be passed to the subtype's ->destroy() method + to be disposed of. A module reference for the subtype pointed to by + ->payload[asym_subtype] will be put. If the data format is not recognised, -EBADMSG should be returned. If it |