crypto ahash error handling
Hello, When using crypto ahash API, is it necessary/mandatory to call crypto_ahash_final() if crypto_ahash_update() returns error... Basically it might happen after several calls while calculating hash if HW error happens. It is not possible to continue hash calculation. it is necessary to reset HW and start whole hash again.. Any comments? Thanks, Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] crypto: algif_skcipher - User-space interface for skcipher operations
Hmm, can you show me your test program and how you determined
that it was leaking pages?
The test program below runs 1000 encryptions:
# grep nr_free /proc/vmstat
nr_free_pages 11031
# ./test
...
# grep nr_free /proc/vmstat
nr_free_pages 10026
# ./test
...
# grep nr_free /proc/vmstat
nr_free_pages 9027
# ./test
...
# grep nr_free /proc/vmstat
nr_free_pages 8025
Regards
Martin
--
#include stdio.h
#include unistd.h
#include stddef.h
#include string.h
#include sys/socket.h
#include linux/if_alg.h
int main()
{
int tfm, i;
char key[16];
struct sockaddr_alg sa = {
.salg_family = AF_ALG,
.salg_type = skcipher,
.salg_name = cbc(aes),
};
tfm = socket(AF_ALG, SOCK_SEQPACKET, 0);
if (tfm == -1 ||
bind(tfm, (struct sockaddr*)sa, sizeof(sa)) == -1)
{
return 1;
}
memset(key, 0x34, sizeof(key));
if (setsockopt(tfm, SOL_ALG, ALG_SET_KEY,
key, sizeof(key)) == -1)
{
return 1;
}
for (i = 0; i 1000; i++)
{
struct msghdr msg = {};
struct cmsghdr *cmsg;
struct af_alg_iv *ivm;
u_int32_t type;
struct iovec iov;
char buf[CMSG_SPACE(sizeof(type)) +
CMSG_SPACE(offsetof(struct af_alg_iv, iv)+16)];
char data[64];
ssize_t len;
int op;
op = accept(tfm, NULL, 0);
if (op == -1)
{
return 1;
}
type = ALG_OP_ENCRYPT;
memset(data, 0x12, sizeof(data));
memset(buf, 0, sizeof(buf));
msg.msg_control = buf;
msg.msg_controllen = sizeof(buf);
cmsg = CMSG_FIRSTHDR(msg);
cmsg-cmsg_level = SOL_ALG;
cmsg-cmsg_type = ALG_SET_OP;
cmsg-cmsg_len = CMSG_LEN(sizeof(type));
*(u_int32_t*)CMSG_DATA(cmsg) = type;
cmsg = CMSG_NXTHDR(msg, cmsg);
cmsg-cmsg_level = SOL_ALG;
cmsg-cmsg_type = ALG_SET_IV;
cmsg-cmsg_len = CMSG_LEN(
offsetof(struct af_alg_iv, iv) + 16);
ivm = (void*)CMSG_DATA(cmsg);
ivm-ivlen = 16;
memset(ivm-iv, 0x23, 16);
msg.msg_iov = iov;
msg.msg_iovlen = 1;
iov.iov_base = data;
iov.iov_len = sizeof(data);
len = sendmsg(op, msg, 0);
if (len != sizeof(data))
{
return 1;
}
if (read(op, data, len) != len)
{
return 1;
}
printf(.);
fflush(stdout);
close(op);
}
close(tfm);
printf(\n);
return 0;
}
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1.2 1/4] lib: hex2bin converts ascii hexadecimal string to binary
Similar to the kgdb_hex2mem() code, hex2bin converts a string
to binary using the hex_to_bin() library call.
Signed-off-by: Mimi Zohar zo...@us.ibm.com
Acked-by: Serge E. Hallyn se...@hallyn.com
---
include/linux/kernel.h |1 +
lib/hexdump.c | 16
2 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 450092c..efe0e1e 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -417,6 +417,7 @@ static inline char *pack_hex_byte(char *buf, u8 byte)
}
extern int hex_to_bin(char ch);
+extern void hex2bin(unsigned char *mem, char *buf, int count);
#ifndef pr_fmt
#define pr_fmt(fmt) fmt
diff --git a/lib/hexdump.c b/lib/hexdump.c
index 5d7a480..66f96bb 100644
--- a/lib/hexdump.c
+++ b/lib/hexdump.c
@@ -34,6 +34,22 @@ int hex_to_bin(char ch)
EXPORT_SYMBOL(hex_to_bin);
/**
+ * hex2bin - convert an ascii hexadecimal string to its binary representation
+ * @mem: result
+ * @buf: ascii hexadecimal string
+ * @count: result length
+ */
+void hex2bin(unsigned char *mem, char *buf, int count)
+{
+ while (count--) {
+ *mem = hex_to_bin(*buf++) 4;
+ *mem += hex_to_bin(*buf++);
+ mem++;
+ }
+}
+EXPORT_SYMBOL(hex2bin);
+
+/**
* hex_dump_to_buffer - convert a blob of data to hex ASCII in memory
* @buf: data blob to dump
* @len: number of bytes in the @buf
--
1.7.2.2
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1.2 0/4] keys: trusted and encrypted keys
The major change, since the previous posting, are serveral new trusted-key options (migratable, pcrlock, keyhandle, keyauth, blobauth), described below, based on suggestions by Jason Gunthorpe. By default, trusted keys work as previously described. Trusted and Encrypted Keys are two new key types added to the existing kernel key ring service. Both of these new types are variable length symmetic keys, and in both cases all keys are created in the kernel, and user space sees, stores, and loads only encrypted blobs. Trusted Keys require the availability of a Trusted Platform Module (TPM) chip for greater security, while Encrypted Keys can be used on any system. All user level blobs, are displayed and loaded in hex ascii for convenience, and are integrity verified. Trusted Keys use a TPM both to generate and to seal the keys. Keys are sealed under a 2048 bit RSA key in the TPM, and optionally sealed to specified PCR (integrity measurement) values, and only unsealed by the TPM, if PCRs and blob integrity verifications match. A loaded Trusted Key can be updated with new (future) PCR values, so keys are easily migrated to new pcr values, such as when the kernel and initramfs are updated. The same key can have many saved blobs under different PCR values, so multiple boots are easily supported. By default, trusted keys are sealed under the SRK, which has the default authorization value (20 zeros). This can be set at takeownership time with the trouser's utility: tpm_takeownership -u -z. Usage: keyctl add trusted name new keylen [options] ring keyctl add trusted name load hex_blob [pcrlock=pcrnum] ring keyctl update key update [options] keyctl print keyid options: keyhandle= ascii hex value of sealing key default 0x4000 (SRK) keyauth= ascii hex auth for sealing key default 0x00... (40 ascii zeros) blobauth= ascii hex auth for sealed data default 0x00... (40 ascii zeros) pcrinfo= ascii hex of PCR_INFO or PCR_INFO_LONG (no default) pcrlock= pcr number to be extended to lock blob migratable= 0|1 indicating permission to reseal to new PCR values, default 1 (resealing allowed) The key length for new keys are always in bytes. Trusted Keys can be 32 - 128 bytes (256 - 1024 bits), the upper limit is to fit within the 2048 bit SRK (RSA) keylength, with all necessary structure/padding. Encrypted keys do not depend on a TPM, and are faster, as they use AES for encryption/decryption. New keys are created from kernel generated random numbers, and are encrypted/decrypted using a specified 'master' key. The 'master' key can either be a trusted-key or user-key type. The main disadvantage of encrypted keys is that if they are not rooted in a trusted key, they are only as secure as the user key encrypting them. The master user key should therefore be loaded in as secure a way as possible, preferably early in boot. Usage: keyctl add encrypted name new master-key-name keylen ring keyctl add encrypted name load master-key-name keylen hex_blob ring keyctl update keyid update master-key-name The initial consumer of trusted keys is EVM, which at boot time needs a high quality symmetric key for HMAC protection of file metadata. The use of a trusted key provides strong guarantees that the EVM key has not been compromised by a user level problem, and when sealed to specific boot PCR values, protects against boot and offline attacks. Other uses for trusted and encrypted keys, such as for disk and file encryption are anticipated. Mimi Zohar Dave Safford Mimi Zohar (4): lib: hex2bin converts ascii hexadecimal string to binary key: add tpm_send command keys: add new trusted key-type keys: add new key-type encrypted drivers/char/tpm/tpm.c| 17 + include/keys/encrypted-type.h | 30 + include/keys/trusted-type.h | 32 ++ include/linux/kernel.h|1 + include/linux/tpm.h |3 + lib/hexdump.c | 16 + security/Kconfig | 31 + security/keys/Makefile|2 + security/keys/encrypted_defined.c | 816 +++ security/keys/encrypted_defined.h | 52 ++ security/keys/trusted_defined.c | 1096 + security/keys/trusted_defined.h | 147 + 12 files changed, 2243 insertions(+), 0 deletions(-) create mode 100644 include/keys/encrypted-type.h create mode 100644 include/keys/trusted-type.h create mode 100644 security/keys/encrypted_defined.c create mode 100644 security/keys/encrypted_defined.h create mode 100644 security/keys/trusted_defined.c create mode 100644 security/keys/trusted_defined.h -- 1.7.2.2 -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1.2 3/4] keys: add new trusted key-type
Defines a new kernel key-type called 'trusted'. Trusted keys are
random number symmetric keys, generated and RSA-sealed by the TPM.
The TPM only unseals the keys, if the boot PCRs and other criteria
match. Userspace can only ever see encrypted blobs.
Based on suggestions by Jason Gunthorpe, several new options have
been added to support additional usages.
The new options are:
migratable= designates that the key may/may not ever be updated
(resealed under a new key, new pcrinfo or new auth.)
pcrlock=nextends the designated PCR 'n' with a random value,
so that a key sealed to that PCR may not be unsealed
again until after a reboot.
keyhandle= specifies the sealing/unsealing key handle.
keyauth= specifies the sealing/unsealing key auth.
blobauth=specifies the sealed data auth.
Implementation of a kernel reserved locality for trusted keys
will be investigated for a possible future extension.
Changelog:
- New options: migratable, pcrlock, keyhandle, keyauth, blobauth (based on
discussions with Jason Gunthorpe)
- Free payload on failure to create key(reported/fixed by Roberto Sassu)
- Updated Kconfig and other descriptions (based on Serge Hallyn's suggestion)
- Replaced kzalloc() with kmalloc() (reported by Serge Hallyn)
Signed-off-by: David Safford saff...@watson.ibm.com
Signed-off-by: Mimi Zohar zo...@us.ibm.com
---
include/keys/trusted-type.h | 32 ++
security/Kconfig| 15 +
security/keys/Makefile |1 +
security/keys/trusted_defined.c | 1096 +++
security/keys/trusted_defined.h | 147 ++
5 files changed, 1291 insertions(+), 0 deletions(-)
create mode 100644 include/keys/trusted-type.h
create mode 100644 security/keys/trusted_defined.c
create mode 100644 security/keys/trusted_defined.h
diff --git a/include/keys/trusted-type.h b/include/keys/trusted-type.h
new file mode 100644
index 000..5c3a158
--- /dev/null
+++ b/include/keys/trusted-type.h
@@ -0,0 +1,32 @@
+/* trusted-type.h: trusted-defined key type
+ *
+ * Copyright (C) 2010 IBM Corporation
+ * Author: David Safford saff...@us.ibm.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, version 2 of the License.
+ */
+
+#ifndef _KEYS_TRUSTED_TYPE_H
+#define _KEYS_TRUSTED_TYPE_H
+
+#include linux/key.h
+#include linux/rcupdate.h
+
+#define MIN_KEY_SIZE 32
+#define MAX_KEY_SIZE 128
+#define MAX_BLOB_SIZE 320
+
+struct trusted_key_payload {
+ struct rcu_head rcu;/* RCU destructor */
+ unsigned int key_len;
+ unsigned int blob_len;
+ unsigned char migratable;
+ unsigned char key[MAX_KEY_SIZE+1];
+ unsigned char blob[MAX_BLOB_SIZE];
+};
+
+extern struct key_type key_type_trusted;
+
+#endif /* _KEYS_TRUSTED_TYPE_H */
diff --git a/security/Kconfig b/security/Kconfig
index bd72ae6..415422e 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -21,6 +21,21 @@ config KEYS
If you are unsure as to whether this is required, answer N.
+config TRUSTED_KEYS
+ tristate TRUSTED KEYS
+ depends on KEYS TCG_TPM
+ select CRYPTO
+ select CRYPTO_HMAC
+ select CRYPTO_SHA1
+ help
+ This option provides support for creating, sealing, and unsealing
+ keys in the kernel. Trusted keys are random number symmetric keys,
+ generated and RSA-sealed by the TPM. The TPM only unseals the keys,
+ if the boot PCRs and other criteria match. Userspace can only ever
+ see encrypted blobs.
+
+ If you are unsure as to whether this is required, answer N.
+
config KEYS_DEBUG_PROC_KEYS
bool Enable the /proc/keys file by which keys may be viewed
depends on KEYS
diff --git a/security/keys/Makefile b/security/keys/Makefile
index 74d5447..fcb1070 100644
--- a/security/keys/Makefile
+++ b/security/keys/Makefile
@@ -13,6 +13,7 @@ obj-y := \
request_key_auth.o \
user_defined.o
+obj-$(CONFIG_TRUSTED_KEYS) += trusted_defined.o
obj-$(CONFIG_KEYS_COMPAT) += compat.o
obj-$(CONFIG_PROC_FS) += proc.o
obj-$(CONFIG_SYSCTL) += sysctl.o
diff --git a/security/keys/trusted_defined.c b/security/keys/trusted_defined.c
new file mode 100644
index 000..a16a63f
--- /dev/null
+++ b/security/keys/trusted_defined.c
@@ -0,0 +1,1096 @@
+/*
+ * Copyright (C) 2010 IBM Corporation
+ *
+ * Author:
+ * David Safford saff...@us.ibm.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, version 2 of the License.
+ *
+ * Defines a new kernel key-type called 'trusted'. Trusted keys are random
+ * number symmetric keys, generated and RSA-sealed by the TPM. The TPM only
+ * unseals the keys, if the
[PATCH v1.2 2/4] key: add tpm_send command
Add internal kernel tpm_send() command used to seal/unseal keys.
Signed-off-by: David Safford saff...@watson.ibm.com
Reviewd-by: Mimi Zohar zo...@watson.ibm.com
Acked-by: Rajiv Andrade sra...@linux.vnet.ibm.com
Acked-by: Serge E. Hallyn se...@hallyn.com
---
drivers/char/tpm/tpm.c | 17 +
include/linux/tpm.h|3 +++
2 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/char/tpm/tpm.c b/drivers/char/tpm/tpm.c
index 7c41335..5987d9c 100644
--- a/drivers/char/tpm/tpm.c
+++ b/drivers/char/tpm/tpm.c
@@ -780,6 +780,23 @@ int tpm_pcr_extend(u32 chip_num, int pcr_idx, const u8
*hash)
}
EXPORT_SYMBOL_GPL(tpm_pcr_extend);
+int tpm_send(u32 chip_num, char *cmd, int buflen)
+{
+ struct tpm_chip *chip;
+ int rc;
+
+ chip = tpm_chip_find_get(chip_num);
+ if (chip == NULL)
+ return -ENODEV;
+
+ rc = transmit_cmd(chip, (struct tpm_cmd_t *)cmd, buflen,
+ attempting tpm_cmd);
+
+ module_put(chip-dev-driver-owner);
+ return rc;
+}
+EXPORT_SYMBOL_GPL(tpm_send);
+
ssize_t tpm_show_pcrs(struct device *dev, struct device_attribute *attr,
char *buf)
{
diff --git a/include/linux/tpm.h b/include/linux/tpm.h
index ac5d1c1..a0ecaa9 100644
--- a/include/linux/tpm.h
+++ b/include/linux/tpm.h
@@ -31,6 +31,7 @@
extern int tpm_pcr_read(u32 chip_num, int pcr_idx, u8 *res_buf);
extern int tpm_pcr_extend(u32 chip_num, int pcr_idx, const u8 *hash);
+extern int tpm_send(u32 chip_num, char *cmd, int buflen);
#else
static inline int tpm_pcr_read(u32 chip_num, int pcr_idx, u8 *res_buf) {
return -ENODEV;
@@ -38,5 +39,7 @@ static inline int tpm_pcr_read(u32 chip_num, int pcr_idx, u8
*res_buf) {
static inline int tpm_pcr_extend(u32 chip_num, int pcr_idx, const u8 *hash) {
return -ENODEV;
}
+static inline int tpm_send(u32 chip_num, char *cmd, int buflen) {
+ return -ENODEV;
#endif
#endif
--
1.7.2.2
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1.2 4/4] keys: add new key-type encrypted
Defines a new kernel key-type called 'encrypted'. Encrypted keys are
kernel generated random numbers, which are encrypted/decrypted with
a 'trusted' symmetric key. Encrypted keys are created/encrypted/decrypted
in the kernel. Userspace only ever sees/stores encrypted blobs.
Changelog:
- allocate derived_buf dynamically to support arbitrary length master key
(fixed by Roberto Sassu)
- wait until late_initcall for crypto libraries to be registered
- cleanup security/Kconfig
- Add missing 'update' keyword (reported/fixed by Roberto Sassu)
- Free epayload on failure to create key (reported/fixed by Roberto Sassu)
- Increase the data size limit (requested by Roberto Sassu)
- Crypto return codes are always 0 on success and negative on failure,
remove unnecessary tests.
- Replaced kzalloc() with kmalloc()
Signed-off-by: Mimi Zohar zo...@us.ibm.com
Signed-off-by: David Safford saff...@watson.ibm.com
Reviewed-by: Roberto Sassu roberto.sa...@polito.it
---
include/keys/encrypted-type.h | 30 ++
security/Kconfig | 16 +
security/keys/Makefile|1 +
security/keys/encrypted_defined.c | 816 +
security/keys/encrypted_defined.h | 52 +++
5 files changed, 915 insertions(+), 0 deletions(-)
create mode 100644 include/keys/encrypted-type.h
create mode 100644 security/keys/encrypted_defined.c
create mode 100644 security/keys/encrypted_defined.h
diff --git a/include/keys/encrypted-type.h b/include/keys/encrypted-type.h
new file mode 100644
index 000..e2312e0
--- /dev/null
+++ b/include/keys/encrypted-type.h
@@ -0,0 +1,30 @@
+/* encrypted-type.h: encrypted-defined key type
+ *
+ * Copyright (C) 2010 IBM Corporation
+ * Author: Mimi Zohar zo...@us.ibm.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, version 2 of the License.
+ */
+
+#ifndef _KEYS_ENCRYPTED_TYPE_H
+#define _KEYS_ENCRYPTED_TYPE_H
+
+#include linux/key.h
+#include linux/rcupdate.h
+
+struct encrypted_key_payload {
+ struct rcu_head rcu;/* RCU destructor */
+ char *master_desc; /* datablob: master key name */
+ char *datalen; /* datablob: decrypted key length */
+ void *iv; /* datablob: iv */
+ void *encrypted_data; /* datablob: encrypted key */
+ unsigned short datablob_len;/* length of datablob */
+ unsigned short decrypted_datalen; /* decrypted data length */
+ char decrypted_data[0]; /* decrypted data + datablob + hmac */
+};
+
+extern struct key_type key_type_encrypted;
+
+#endif /* _KEYS_ENCRYPTED_TYPE_H */
diff --git a/security/Kconfig b/security/Kconfig
index 415422e..a031ebb 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -36,6 +36,22 @@ config TRUSTED_KEYS
If you are unsure as to whether this is required, answer N.
+config ENCRYPTED_KEYS
+ tristate ENCRYPTED KEYS
+ depends on KEYS TRUSTED_KEYS
+ select CRYPTO_AES
+ select CRYPTO_CBC
+ select CRYPTO_SHA256
+ select CRYPTO_RNG
+ help
+ This option provides support for create/encrypting/decrypting keys
+ in the kernel. Encrypted keys are kernel generated random numbers,
+ which are encrypted/decrypted with a 'master' symmetric key. The
+ 'master' key can be either a trusted-key or user-key type.
+ Userspace only ever sees/stores encrypted blobs.
+
+ If you are unsure as to whether this is required, answer N.
+
config KEYS_DEBUG_PROC_KEYS
bool Enable the /proc/keys file by which keys may be viewed
depends on KEYS
diff --git a/security/keys/Makefile b/security/keys/Makefile
index fcb1070..6c94105 100644
--- a/security/keys/Makefile
+++ b/security/keys/Makefile
@@ -14,6 +14,7 @@ obj-y := \
user_defined.o
obj-$(CONFIG_TRUSTED_KEYS) += trusted_defined.o
+obj-$(CONFIG_ENCRYPTED_KEYS) += encrypted_defined.o
obj-$(CONFIG_KEYS_COMPAT) += compat.o
obj-$(CONFIG_PROC_FS) += proc.o
obj-$(CONFIG_SYSCTL) += sysctl.o
diff --git a/security/keys/encrypted_defined.c
b/security/keys/encrypted_defined.c
new file mode 100644
index 000..1d41228
--- /dev/null
+++ b/security/keys/encrypted_defined.c
@@ -0,0 +1,816 @@
+/*
+ * Copyright (C) 2010 IBM Corporation
+ *
+ * Author:
+ * Mimi Zohar zo...@us.ibm.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, version 2 of the License.
+ *
+ * File: encrypted_defined.c
+ *
+ * Defines a new kernel key-type called 'encrypted'. Encrypted keys
+ * are kernel generated random numbers, which are encrypted/decrypted
+ * using a 'master' key. The 'master' key can either be a trusted-key or
+ * user-key type. Encrypted keys are created/encrypted/decrypted in the
+ * kernel. Userspace ever only
Re: [PATCH v1.2 3/4] keys: add new trusted key-type
On Mon, Nov 08, 2010 at 10:30:45AM -0500, Mimi Zohar wrote: pcrlock=nextends the designated PCR 'n' with a random value, so that a key sealed to that PCR may not be unsealed again until after a reboot. Nice, but this seems very strange to me, since it has nothing to do with the key and could be done easially in userspace? Jason -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1.2 3/4] keys: add new trusted key-type
On Mon, 2010-11-08 at 10:09 -0700, Jason Gunthorpe wrote: On Mon, Nov 08, 2010 at 10:30:45AM -0500, Mimi Zohar wrote: pcrlock=nextends the designated PCR 'n' with a random value, so that a key sealed to that PCR may not be unsealed again until after a reboot. Nice, but this seems very strange to me, since it has nothing to do with the key and could be done easially in userspace? Jason This is strictly for convenience in initramfs, so that the trusted key can be loaded and locked in a single command, with no need for an additional application to extend a PCR. As the the TPM driver already has support for extend, it's a trivial addition. dave -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1.2 3/4] keys: add new trusted key-type
On Mon, Nov 08, 2010 at 01:18:33PM -0500, David Safford wrote: This is strictly for convenience in initramfs, so that the trusted key can be loaded and locked in a single command, with no need for an additional application to extend a PCR. As the the TPM driver already has support for extend, it's a trivial addition. I guess I imagined that user space would want to extend some PCRs anyhow with data from the root filesystem before handing over control. This is not related to your patch at all, just overall how I'd expect the TPM to be used.. It just seems like really odd functionality. I'm not familiar with the KH api, but is there any chance now (or in future) that non-root could access this function? A few random observations - I'm sure someone will say kdoc format should be used for those function comments? - Using a random value to extend the PCR effectively wastes it and creates a tiny risk the random extend could result in 0. - It would be nice to formally state the datablob is a TPM_STORED_DATA with no embellishments. The expectation is userspace can validate the sealInfo prior to loading the key. - I'm unclear on the merits of using raw random data from the TPM. I'd feel much better if this was mixed with random from the kernel pool too. Ideally using a FIPS DBRNG transform.. - Shouldn't all the TPM RPC functions live together in the TPM code someplace? You've done a good job of adding many more general primitives to build RPC's with. FWIW, last time I worked with TPMs I built a RPC code generator for this stuff, which if any more are added would be a really smart direction to head in. Cheers, Jason -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
