summaryrefslogtreecommitdiffstats
path: root/Documentation/crypto
diff options
context:
space:
mode:
authorDavid Howells <dhowells@redhat.com>2015-10-21 14:04:48 +0100
committerDavid Howells <dhowells@redhat.com>2015-10-21 15:18:36 +0100
commit146aa8b1453bd8f1ff2304ffb71b4ee0eb9acdcc (patch)
treea89ef2cd2e8029b0c09a58739cca0e7e2e68f4db /Documentation/crypto
parent4adc605edc5f744dcf432241b5996ff6a13d868c (diff)
downloadop-kernel-dev-146aa8b1453bd8f1ff2304ffb71b4ee0eb9acdcc.zip
op-kernel-dev-146aa8b1453bd8f1ff2304ffb71b4ee0eb9acdcc.tar.gz
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.txt27
1 files changed, 14 insertions, 13 deletions
diff --git a/Documentation/crypto/asymmetric-keys.txt b/Documentation/crypto/asymmetric-keys.txt
index b767590..8c07e0e 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
OpenPOWER on IntegriCloud