Re: [PATCH 3/3] KEYS: Add a 'trusted' flag and a 'trusted only' flag
On Wed, Jan 30, 2013 at 12:32 PM, David Howells wrote: > Kasatkin, Dmitry wrote: > >> What about the case when running from integrity protected initramfs? >> Either embedded into the signed kernel, or verified by the boot loader. >> In such case it is possible to assume that all keys which are added by >> user space are implicitly trusted. >> Later on, before continuing booting normal rootfs, set the key >> subsystem state (trust-lock), >> so that trusted keyrings accept only explicitly trusted keys... >> >> Does it make sense? > > I'm not sure it does. Initramfs is (re-)fabricated on the machine on which it > runs any time you update one of a set of rpms (such as the kernel rpm) because > it has machine-specific data and drivers in it. > Based on my latest post on signed initramfs it might make sense. But it seems to be that it would be behavior anyway, because "first" key added is implicitly should be assumed trusted. - Dmitry > David > -- > To unsubscribe from this list: send the line "unsubscribe > linux-security-module" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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 v3 1/1] dm-integrity: integrity protection device-mapper target
Hi Mikulas, I made fixes based on your comments. Can you think now about adding this target to the device-mapper tree, may be with different name, though? - Dmitry On Tue, Jan 22, 2013 at 2:37 PM, Dmitry Kasatkin wrote: > Device-mapper "integrity" target provides transparent cryptographic integrity > protection of the underlying read-write block device using hash-based message > authentication codes (HMACs). HMACs can be stored on the same or different > block device. > > dm-integrity uses an encrypted key type, stored on the kernel keyring, to > obtain a secret key for use in cryptographic operations. Encrypted keys are > never exposed in plain text to user space. The encrypted keys are encrypted > using master key, which can either be a user defined or trusted key type. > The secret key, which is usually device specific, binds integrity data to the > device. As a result data blocks and corresponding HMACs cannot simply be > copied over from other file systems. > > Signed-off-by: Dmitry Kasatkin > --- > Documentation/device-mapper/dm-integrity.txt | 137 > drivers/md/Kconfig | 13 + > drivers/md/Makefile |1 + > drivers/md/dm-integrity.c| 991 > ++ > 4 files changed, 1142 insertions(+) > create mode 100644 Documentation/device-mapper/dm-integrity.txt > create mode 100644 drivers/md/dm-integrity.c > > diff --git a/Documentation/device-mapper/dm-integrity.txt > b/Documentation/device-mapper/dm-integrity.txt > new file mode 100644 > index 000..394242f > --- /dev/null > +++ b/Documentation/device-mapper/dm-integrity.txt > @@ -0,0 +1,137 @@ > +dm-integrity > +=== > + > +Device-mapper "integrity" target provides transparent cryptographic integrity > +protection of the underlying read-write block device using hash-based message > +authentication codes (HMACs). HMACs can be stored on the same or different > +block device. > + > +dm-integrity uses an encrypted key type, stored on the kernel keyring, to > +obtain a secret key for use in cryptographic operations. Encrypted keys are > +never exposed in plain text to user space. The encrypted keys are encrypted > +using master key, which can either be a user defined or trusted key type. > +The secret key, which is usually device specific, binds integrity data to the > +device. As a result data blocks and corresponding HMACs cannot simply be > +copied over from other file systems. > + > +Parameters: > + \ > +[] > + > + > +This is the device that is going to be used to store the data. > +You can specify it as a path like /dev/xxx or a device : > +number. > + > + > +Device block size. > + > + > +Starting sector within the device where data begins. > + > + > +This is the device that is going to be used to store integrity data. > +You can specify it as a path like /dev/xxx or a device : > +number. > + > + > +HMAC device block size. > + > + > +Starting sector within the device where integrity data begins. > + > + > +Hash algorithm (sha1, sha256, etc). > + > + > +HMAC algorithm, e.g. hmac(sha1), hmac(sha256), etc. > + > + > +Description is a name of a key in the kernel keyring. > + > + > +fix=1|0 - enable fix mode > + In fix mode, incorrect hmacs are replaced with correct ones. > + It is used for device initialization and debugging. > + > +stats=1|0 - turns on collecting additional statistical information. > + It is used to find out resource usage to tune memory pool > + and queue sizes for particular use case. > + > +verbose=1|0 - prints block number, collected hmac and stored hmac. > + It is used for addition debug output. > + > + > +Determine the size of integrity/hmac device > +=== > + > +Every block device has corresponding hmac. > +While NIST does recommend to use sha256 hash algorithm instead of SHA1, > +this does not apply to hmac(sha1), because of keying. It is safe to use > +hmac(sha1), because it takes much less space and it is faster to calculate. > +hmac(sha1) size is 20 bytes. So every 4k block on the integrity device can > +store 204 hmacs. In order to get the required size of the integrity device, > +it is necessary to divide data device size by 204. See examples bellow how > +to do it from script. > + > +Example scripts > +=== > + > +1. Setting up integrity target using data and hmac store on the same block > device. > + > +[[ > +#!/bin/sh > + > +bdev=$1 > + > +# block device size > +dsize=`blockdev --getsize $bdev` > +# block size > +bs=4096 > +# sector to block shift > +sbs=3 > +# integrity record size (hmac size) > +hmac=20 > +# hmacs per block > +hpb=$((bs/hmac)) > +# target device size > +size=$dsize>>sbs)*hpb/(hpb+1))< + > +# load the key - in this example we just use test key > +keyctl add user kmk "testing123" @u > +keyctl add encrypted dm-int-key "lo
Re: [PATCH 3/3] KEYS: Add a 'trusted' flag and a 'trusted only' flag
On Thu, Jan 17, 2013 at 8:04 PM, David Howells wrote:
> Add KEY_FLAG_TRUSTED to indicate that a key either comes from a trusted source
> or had a cryptographic signature chain that led back to a trusted key the
> kernel already possessed.
>
> Add KEY_FLAGS_TRUSTED_ONLY to indicate that a keyring will only accept links
> to
> keys marked with KEY_FLAGS_TRUSTED.
>
> Signed-off-by: David Howells
> Reviewed-by: Kees Cook
> ---
>
> include/linux/key-type.h |1 +
> include/linux/key.h |3 +++
> kernel/system_keyring.c |4 +++-
> security/keys/key.c |8
> security/keys/keyring.c |4
> 5 files changed, 19 insertions(+), 1 deletion(-)
>
>
> diff --git a/include/linux/key-type.h b/include/linux/key-type.h
> index 518a53a..f942b2d 100644
> --- a/include/linux/key-type.h
> +++ b/include/linux/key-type.h
> @@ -45,6 +45,7 @@ struct key_preparsed_payload {
> const void *data; /* Raw data */
> size_t datalen;/* Raw datalen */
> size_t quotalen; /* Quota length for proposed payload
> */
> + booltrusted;/* True if key is trusted */
> };
>
> typedef int (*request_key_actor_t)(struct key_construction *key,
> diff --git a/include/linux/key.h b/include/linux/key.h
> index 4dfde11..0b32a09 100644
> --- a/include/linux/key.h
> +++ b/include/linux/key.h
> @@ -162,6 +162,8 @@ struct key {
> #define KEY_FLAG_NEGATIVE 5 /* set if key is negative */
> #define KEY_FLAG_ROOT_CAN_CLEAR6 /* set if key can be cleared
> by root without permission */
> #define KEY_FLAG_INVALIDATED 7 /* set if key has been invalidated */
> +#define KEY_FLAG_TRUSTED 8 /* set if key is trusted */
> +#define KEY_FLAG_TRUSTED_ONLY 9 /* set if keyring only accepts links
> to trusted keys */
>
> /* the description string
> * - this is used to match a key against search criteria
> @@ -203,6 +205,7 @@ extern struct key *key_alloc(struct key_type *type,
> #define KEY_ALLOC_IN_QUOTA 0x /* add to quota, reject if would
> overrun */
> #define KEY_ALLOC_QUOTA_OVERRUN0x0001 /* add to quota, permit even
> if overrun */
> #define KEY_ALLOC_NOT_IN_QUOTA 0x0002 /* not in quota */
> +#define KEY_ALLOC_TRUSTED 0x0004 /* Key should be flagged as trusted */
>
> extern void key_revoke(struct key *key);
> extern void key_invalidate(struct key *key);
> diff --git a/kernel/system_keyring.c b/kernel/system_keyring.c
> index a3ca76f..dae8778 100644
> --- a/kernel/system_keyring.c
> +++ b/kernel/system_keyring.c
> @@ -40,6 +40,7 @@ static __init int system_trusted_keyring_init(void)
> if (IS_ERR(system_trusted_keyring))
> panic("Can't allocate system trusted keyring\n");
>
> + set_bit(KEY_FLAG_TRUSTED_ONLY, &system_trusted_keyring->flags);
> return 0;
> }
>
> @@ -82,7 +83,8 @@ static __init int load_system_certificate_list(void)
>plen,
>(KEY_POS_ALL & ~KEY_POS_SETATTR) |
>KEY_USR_VIEW,
> - KEY_ALLOC_NOT_IN_QUOTA);
> + KEY_ALLOC_NOT_IN_QUOTA |
> + KEY_ALLOC_TRUSTED);
> if (IS_ERR(key))
> pr_err("Problem loading in-kernel X.509 certificate
> (%ld)\n",
>PTR_ERR(key));
> diff --git a/security/keys/key.c b/security/keys/key.c
> index 8fb7c7b..f3de9e4 100644
> --- a/security/keys/key.c
> +++ b/security/keys/key.c
> @@ -299,6 +299,8 @@ struct key *key_alloc(struct key_type *type, const char
> *desc,
>
> if (!(flags & KEY_ALLOC_NOT_IN_QUOTA))
> key->flags |= 1 << KEY_FLAG_IN_QUOTA;
> + if (flags & KEY_ALLOC_TRUSTED)
> + key->flags |= 1 << KEY_FLAG_TRUSTED;
>
> memset(&key->type_data, 0, sizeof(key->type_data));
>
> @@ -813,6 +815,7 @@ key_ref_t key_create_or_update(key_ref_t keyring_ref,
> prep.data = payload;
> prep.datalen = plen;
> prep.quotalen = ktype->def_datalen;
> + prep.trusted = flags & KEY_ALLOC_TRUSTED;
> if (ktype->preparse) {
> ret = ktype->preparse(&prep);
> if (ret < 0) {
> @@ -826,6 +829,11 @@ key_ref_t key_create_or_update(key_ref_t keyring_ref,
> goto error_free_prep;
> }
>
> + key_ref = ERR_PTR(-EPERM);
> + if (!prep.trusted && test_bit(KEY_FLAG_TRUSTED_ONLY, &keyring->flags))
> + goto error_free_prep;
> + flags |= prep.trusted ? KEY_ALLOC_TRUSTED : 0;
> +
> ret = __key_link_begin(keyring, ktype, description, &prealloc);
> if (ret < 0) {
> key_ref = ERR_PTR(ret);
> diff --git a/security/keys/keyring.c b/security/keys/keyring.c
> index 6ece7f2..f18d7f
Re: [RFC 1/1] ima: digital signature verification using asymmetric keys
On Mon, Jan 28, 2013 at 10:13 PM, Vivek Goyal wrote: > On Mon, Jan 28, 2013 at 02:51:34PM -0500, Mimi Zohar wrote: >> On Mon, 2013-01-28 at 13:52 -0500, Vivek Goyal wrote: >> > On Mon, Jan 28, 2013 at 05:20:20PM +0200, Kasatkin, Dmitry wrote: >> > >> > [..] >> > > > Ok. I am hoping that it will be more than the kernel command line we >> > > > support. In the sense that for digital signatures one needs to parse >> > > > the signature, look at what hash algorithm has been used and then >> > > > collect the hash accordingly. It is little different then IMA >> > > > requirement >> > > > of calculating one pre-determine hash for all files. >> > > >> > > Yes... It is obvious. It's coming. >> > > But in general, signer should be aware of requirements and limitation >> > > of the platform. >> > > It is not really a problem... >> > >> > Ok, I have another question. I was looking at your slide deck here. >> > >> > http://selinuxproject.org/~jmorris/lss2011_slides/IMA_EVM_Digital_Signature_Support.pdf >> > >> > Slide 12 mentions that keys are loaded into the kernel from initramfs. If >> > "root" can load any key, what are we protecting against. >> > >> > IOW, what good ima_appraise_tcb policy, which tries to appraise any root >> > owned file. A root can sign all the files using its own key and load its >> > public key in IMA keyring and then integrity check should pass on all >> > root files. >> >> > So what's the idea behind digital signature appraisal? By allowing root to >> > unconditionally load the keys in IMA keyring, it seems to circumvent the >> > appraisal mechanism. >> >> Vivek, you're asking obvious questions, without understanding that what >> you want to do is only now possible because of the work that has gone >> into upstreaming the different components of the linux-integrity >> subsystem (eg. IMA, trusted/encrypted keys, EVM, (MPI library), and now >> IMA-appraisal). In case you weren't aware, Dmitry made the necessary >> changes so that the MPI library could be upstreamed for >> EVM/IMA-appraisal digital signature support. > > Hi Mimi, > > Sure. I am just trying to understand that where are we and how can I > help improve things so that I can achieve my objectives. > > The problem I am running into is that I can't find a single good > documentation here which explains how to use things. There is no > single .txt file in Documentation/ directory which explains current > state of affiars or which explains how to use any of the IMA/EVM > functionality. > There is Wiki page available which contains lots of examples and explanations. http://sourceforge.net/p/linux-ima/wiki/Home/ This is an Open Source project. Anyone can contribute and improve it. If you find that something is unclear or missing in the wiki, you are welcome to contribute/ > So I have no way left but to read code and ask obivious questions > on mailing list to figure out what components are working, what > components are work in progress or what's the intent of components > and how they are supposed to be used. > > So are we saying that all the appraisal and digital signature stuff > is not useful till we figure a way out to lock down IMA keyring. Or > it is useful only when root can load the keyring but we are trying > to appraise only non-root files. > >> >> I'm pretty sure that keyrings can be locked, preventing additional keys >> from being added. (If it isn't currently supported, it needs to be.) >> The _evm and _ima keyrings should definitely be locked. When/how this >> is done, is yet to be defined. I'm pretty sure there are a number of >> people thinking about this, including David Howells, Dmitry Kataskin, >> David Safford and myself. >> >> As I previously said, the next steps are to integrate the >> EVM/IMA-appraisal public keys in a safe and trusted manner, without >> breaking the secure boot signature chain. > > In a private conversation David howells mentioned that IMA keyring > should allow loading only if new key is trusted by an already loaded > key. He has already posted some patches for marking a keyring trusted > and loading keys only if it is signed by a trusted key. > > We were wondring that what use case is served by allowing the root > to load keys unconditionally. By understanding the use case, atleast > one can try not to break it. Please read my previous email on how to lock down the kernel keyring. - Dmitry > > Thanks > Vivek -- 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: [RFC 1/1] ima: digital signature verification using asymmetric keys
On Mon, Jan 28, 2013 at 8:52 PM, Vivek Goyal wrote: > On Mon, Jan 28, 2013 at 05:20:20PM +0200, Kasatkin, Dmitry wrote: > > [..] >> > Ok. I am hoping that it will be more than the kernel command line we >> > support. In the sense that for digital signatures one needs to parse >> > the signature, look at what hash algorithm has been used and then >> > collect the hash accordingly. It is little different then IMA requirement >> > of calculating one pre-determine hash for all files. >> >> Yes... It is obvious. It's coming. >> But in general, signer should be aware of requirements and limitation >> of the platform. >> It is not really a problem... > > Ok, I have another question. I was looking at your slide deck here. > > http://selinuxproject.org/~jmorris/lss2011_slides/IMA_EVM_Digital_Signature_Support.pdf > > Slide 12 mentions that keys are loaded into the kernel from initramfs. If > "root" can load any key, what are we protecting against. > > IOW, what good ima_appraise_tcb policy, which tries to appraise any root > owned file. A root can sign all the files using its own key and load its > public key in IMA keyring and then integrity check should pass on all > root files. > > So what's the idea behind digital signature appraisal? By allowing root to > unconditionally load the keys in IMA keyring, it seems to circumvent the > appraisal mechanism. > I will answer directly to this email first. 'keyctl setperm' command is used to lock keyring from being able to add new keys... Even root is not able to revert locked keyring to original write-permissive mode. root@ubuntu:~# cat /proc/keys |grep ima 16a4c685 I--Q--- 1 perm 3f01 0 0 keyring _ima: 2/4 root@ubuntu:~# keyctl setperm 379897477 0x0b01 root@ubuntu:~# keyctl add user testkey "testing1" 379897477 add_key: Permission denied root@ubuntu:~# keyctl setperm 379897477 0x3f01 keyctl_setperm: Permission denied root@ubuntu:~# cat /proc/keys |grep ima 16a4c685 I--Q--- 1 perm 0b01 0 0 keyring _ima: 3/4 - Dmitry > Thanks > Vivek -- 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: [RFC 1/1] ima: digital signature verification using asymmetric keys
On Mon, Jan 28, 2013 at 5:15 PM, Vivek Goyal wrote: > On Mon, Jan 28, 2013 at 04:54:06PM +0200, Kasatkin, Dmitry wrote: >> On Fri, Jan 25, 2013 at 11:01 PM, Vivek Goyal wrote: >> > Hi, >> > >> > I am trying to read and understand IMA code. How does digital signature >> > mechanism work. >> > >> > IIUC, evmctl will install a file's signature in security.ima. And later >> > process_measurement() will do following. >> > >> > Calculate digest of file in ima_collect_measurement() and then >> > ima_appraise_measurement() actually compares signatuer against the >> > digest. >> > >> > If yes, ima_collect_measurement() always calculates digest either using >> > md5/sha1 but signatures might have used sha256 or something else. So >> > how does it work. What am I missing. >> >> Hi, >> >> Yes, currently it is possible to use only single configured algorithm, which >> is >> in generally enough. Consider it like a policy. >> Soon it will be a patch which allows to use any hash algorithms, supported by >> asymmetric key verification API. > > Ok. I am hoping that it will be more than the kernel command line we > support. In the sense that for digital signatures one needs to parse > the signature, look at what hash algorithm has been used and then > collect the hash accordingly. It is little different then IMA requirement > of calculating one pre-determine hash for all files. Yes... It is obvious. It's coming. But in general, signer should be aware of requirements and limitation of the platform. It is not really a problem... - Dmitry > > Thanks > Vivek -- 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: [RFC 1/1] ima: digital signature verification using asymmetric keys
On Fri, Jan 25, 2013 at 11:01 PM, Vivek Goyal wrote:
> Hi,
>
> I am trying to read and understand IMA code. How does digital signature
> mechanism work.
>
> IIUC, evmctl will install a file's signature in security.ima. And later
> process_measurement() will do following.
>
> Calculate digest of file in ima_collect_measurement() and then
> ima_appraise_measurement() actually compares signatuer against the
> digest.
>
> If yes, ima_collect_measurement() always calculates digest either using
> md5/sha1 but signatures might have used sha256 or something else. So
> how does it work. What am I missing.
Hi,
Yes, currently it is possible to use only single configured algorithm, which is
in generally enough. Consider it like a policy.
Soon it will be a patch which allows to use any hash algorithms, supported by
asymmetric key verification API.
- Dmitry
>
> Thanks
> Vivek
>
> On Wed, Jan 23, 2013 at 11:03:39AM +0200, Kasatkin, Dmitry wrote:
>> On Wed, Jan 23, 2013 at 12:53 AM, Mimi Zohar
>> wrote:
>> > On Tue, 2013-01-15 at 12:34 +0200, Dmitry Kasatkin wrote:
>> >> Asymmetric keys were introduced in linux-3.7 to verify the signature on
>> >> signed kernel modules. The asymmetric keys infrastructure abstracts the
>> >> signature verification from the crypto details. This patch adds IMA/EVM
>> >> signature verification using asymmetric keys. Support for additional
>> >> signature verification methods can now be delegated to the asymmetric
>> >> key infrastructure.
>> >>
>> >> Signed-off-by: Dmitry Kasatkin
>> >> ---
>> >> security/integrity/Kconfig | 12 +
>> >> security/integrity/digsig.c | 103
>> >> ++-
>> >> 2 files changed, 114 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/security/integrity/Kconfig b/security/integrity/Kconfig
>> >> index 5bd1cc1..19c4187 100644
>> >> --- a/security/integrity/Kconfig
>> >> +++ b/security/integrity/Kconfig
>> >> @@ -17,5 +17,17 @@ config INTEGRITY_SIGNATURE
>> >> This is useful for evm and module keyrings, when keys are
>> >> usually only added from initramfs.
>> >>
>> >> +config INTEGRITY_ASYMMETRIC_KEYS
>> >> + boolean "Digital signature verification using asymmetric keys"
>> >> + depends on INTEGRITY_SIGNATURE
>> >> + default n
>> >> +select ASYMMETRIC_KEY_TYPE
>> >> +select ASYMMETRIC_PUBLIC_KEY_SUBTYPE
>> >> +select PUBLIC_KEY_ALGO_RSA
>> >> +select X509_CERTIFICATE_PARSER
>> >> + help
>> >> + This option enables digital signature verification support
>> >> + using asymmetric keys.
>> >> +
>> >> source security/integrity/ima/Kconfig
>> >> source security/integrity/evm/Kconfig
>> >> diff --git a/security/integrity/digsig.c b/security/integrity/digsig.c
>> >> index 2dc167d..1896537 100644
>> >> --- a/security/integrity/digsig.c
>> >> +++ b/security/integrity/digsig.c
>> >> @@ -15,10 +15,22 @@
>> >> #include
>> >> #include
>> >> #include
>> >> +#include
>> >> +#include
>> >> #include
>> >>
>> >> #include "integrity.h"
>> >>
>> >> +/*
>> >> + * signature format v2 - for using with asymmetric keys
>> >> + */
>> >> +struct signature_v2_hdr {
>> >> + uint8_t version;/* signature format version */
>> >> + uint8_t hash_algo; /* Digest algorithm [enum pkey_hash_algo] */
>> >> + uint8_t keyid[8]; /* IMA key identifier - not X509/PGP
>> >> specific*/
>> >> + uint8_t payload[0]; /* signature payload */
>> >> +} __packed;
>> >> +
>> >> static struct key *keyring[INTEGRITY_KEYRING_MAX];
>> >>
>> >> static const char *keyring_name[INTEGRITY_KEYRING_MAX] = {
>> >> @@ -27,6 +39,91 @@ static const char *keyring_name[INTEGRITY_KEYRING_MAX]
>> >> = {
>> >> "_ima",
>> >> };
>> >>
>> >> +#ifdef CONFIG_INTEGRITY_ASYMMETRIC_KEYS
>> >> +
>> >> +/*
>> >> + * Request an asymmetric key.
>> >> + */
>> >> +static struct key *request_asymmetric_key(struct key *keyring, uint8_t
>> >> *keyid)
Re: [RFC 1/1] ima: digital signature verification using asymmetric keys
On Wed, Jan 23, 2013 at 12:53 AM, Mimi Zohar wrote:
> On Tue, 2013-01-15 at 12:34 +0200, Dmitry Kasatkin wrote:
>> Asymmetric keys were introduced in linux-3.7 to verify the signature on
>> signed kernel modules. The asymmetric keys infrastructure abstracts the
>> signature verification from the crypto details. This patch adds IMA/EVM
>> signature verification using asymmetric keys. Support for additional
>> signature verification methods can now be delegated to the asymmetric
>> key infrastructure.
>>
>> Signed-off-by: Dmitry Kasatkin
>> ---
>> security/integrity/Kconfig | 12 +
>> security/integrity/digsig.c | 103
>> ++-
>> 2 files changed, 114 insertions(+), 1 deletion(-)
>>
>> diff --git a/security/integrity/Kconfig b/security/integrity/Kconfig
>> index 5bd1cc1..19c4187 100644
>> --- a/security/integrity/Kconfig
>> +++ b/security/integrity/Kconfig
>> @@ -17,5 +17,17 @@ config INTEGRITY_SIGNATURE
>> This is useful for evm and module keyrings, when keys are
>> usually only added from initramfs.
>>
>> +config INTEGRITY_ASYMMETRIC_KEYS
>> + boolean "Digital signature verification using asymmetric keys"
>> + depends on INTEGRITY_SIGNATURE
>> + default n
>> +select ASYMMETRIC_KEY_TYPE
>> +select ASYMMETRIC_PUBLIC_KEY_SUBTYPE
>> +select PUBLIC_KEY_ALGO_RSA
>> +select X509_CERTIFICATE_PARSER
>> + help
>> + This option enables digital signature verification support
>> + using asymmetric keys.
>> +
>> source security/integrity/ima/Kconfig
>> source security/integrity/evm/Kconfig
>> diff --git a/security/integrity/digsig.c b/security/integrity/digsig.c
>> index 2dc167d..1896537 100644
>> --- a/security/integrity/digsig.c
>> +++ b/security/integrity/digsig.c
>> @@ -15,10 +15,22 @@
>> #include
>> #include
>> #include
>> +#include
>> +#include
>> #include
>>
>> #include "integrity.h"
>>
>> +/*
>> + * signature format v2 - for using with asymmetric keys
>> + */
>> +struct signature_v2_hdr {
>> + uint8_t version;/* signature format version */
>> + uint8_t hash_algo; /* Digest algorithm [enum pkey_hash_algo] */
>> + uint8_t keyid[8]; /* IMA key identifier - not X509/PGP specific*/
>> + uint8_t payload[0]; /* signature payload */
>> +} __packed;
>> +
>> static struct key *keyring[INTEGRITY_KEYRING_MAX];
>>
>> static const char *keyring_name[INTEGRITY_KEYRING_MAX] = {
>> @@ -27,6 +39,91 @@ static const char *keyring_name[INTEGRITY_KEYRING_MAX] = {
>> "_ima",
>> };
>>
>> +#ifdef CONFIG_INTEGRITY_ASYMMETRIC_KEYS
>> +
>> +/*
>> + * Request an asymmetric key.
>> + */
>> +static struct key *request_asymmetric_key(struct key *keyring, uint8_t
>> *keyid)
>> +{
>> + struct key *key;
>> + char name[20];
>> +
>> + sprintf(name, "%llX", __be64_to_cpup((uint64_t *)keyid));
>> +
>> + pr_debug("key search: \"%s\"\n", name);
>> +
>> + if (keyring) {
>> + /* search in specific keyring */
>> + key_ref_t kref;
>> + kref = keyring_search(make_key_ref(keyring, 1),
>> + &key_type_asymmetric, name);
>> + if (IS_ERR(kref))
>> + key = ERR_CAST(kref);
>> + else
>> + key = key_ref_to_ptr(kref);
>> + } else {
>> + key = request_key(&key_type_asymmetric, name, NULL);
>> + }
>> +
>> + if (IS_ERR(key)) {
>> + pr_warn("Request for unknown key '%s' err %ld\n",
>> + name, PTR_ERR(key));
>> + switch (PTR_ERR(key)) {
>> + /* Hide some search errors */
>> + case -EACCES:
>> + case -ENOTDIR:
>> + case -EAGAIN:
>> + return ERR_PTR(-ENOKEY);
>> + default:
>> + return key;
>> + }
>> + }
>> +
>> + pr_debug("%s() = 0 [%x]\n", __func__, key_serial(key));
>> +
>> + return key;
>> +}
>> +
>> +static int asymmetric_verify(struct key *keyring, const char *sig,
>> + size_t siglen, const char *data, int datalen)
>> +{
>> + struct public_key_signature pks;
>> + struct signature_v2_hdr *hdr = (struct signature_v2_hdr *)sig;
>> + struct key *key;
>> + int ret = -ENOMEM;
>> +
>> + if (siglen <= sizeof(*hdr))
>> + return -EBADMSG;
>> +
>> + siglen -= sizeof(*hdr);
>> +
>> + if (hdr->hash_algo >= PKEY_HASH__LAST)
>> + return -ENOPKG;
>> +
>> + key = request_asymmetric_key(keyring, hdr->keyid);
>> + if (IS_ERR(key))
>> + return PTR_ERR(key);
>> +
>> + memset(&pks, 0, sizeof(pks));
>> +
>> + pks.pkey_hash_algo = hdr->hash_algo;
>> + pks.digest = (u8 *)data;
>> + pks.digest_size = datalen;
>> + pks.nr_mpi = 1;
>> + pks.rsa.s = mpi_read_from_buffer(hdr->payload, &siglen);
>> +
>> + if (pks.rsa.s)
>> + ret =
Re: [RFC 1/1] ima: digital signature verification using asymmetric keys
On Thu, Jan 17, 2013 at 7:52 PM, David Howells wrote: > > Looks reasonable, I think, so you can add: > > Acked-by: David Howells > > David Thank you. -- 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: [PATCHv2 1/1] dm-integrity: integrity protection device-mapper target
Hello, If there is no comments, what about applying the patch? Regards, Dmitry On Wed, Dec 5, 2012 at 1:06 PM, Kasatkin, Dmitry wrote: > Hello, > > Any comments? > > - Dmitry > > > On Mon, Nov 26, 2012 at 4:39 PM, Dmitry Kasatkin > wrote: >> Device-mapper "integrity" target provides transparent cryptographic integrity >> protection of the underlying read-write block device using hash-based message >> authentication codes (HMACs). HMACs can be stored on the same or different >> block device. >> >> dm-integrity uses an encrypted key type, stored on the kernel keyring, to >> obtain a secret key for use in cryptographic operations. Encrypted keys are >> never exposed in plain text to user space. The encrypted keys are encrypted >> using master key, which can either be a user defined or trusted key type. >> The secret key, which is usually device specific, binds integrity data to the >> device. As a result data blocks and corresponding HMACs cannot simply be >> copied over from other file systems. >> >> Signed-off-by: Dmitry Kasatkin >> --- >> Documentation/device-mapper/dm-integrity.txt | 137 >> drivers/md/Kconfig | 13 + >> drivers/md/Makefile |1 + >> drivers/md/dm-integrity.c| 1050 >> ++ >> 4 files changed, 1201 insertions(+) >> create mode 100644 Documentation/device-mapper/dm-integrity.txt >> create mode 100644 drivers/md/dm-integrity.c >> >> diff --git a/Documentation/device-mapper/dm-integrity.txt >> b/Documentation/device-mapper/dm-integrity.txt >> new file mode 100644 >> index 000..394242f >> --- /dev/null >> +++ b/Documentation/device-mapper/dm-integrity.txt >> @@ -0,0 +1,137 @@ >> +dm-integrity >> +=== >> + >> +Device-mapper "integrity" target provides transparent cryptographic >> integrity >> +protection of the underlying read-write block device using hash-based >> message >> +authentication codes (HMACs). HMACs can be stored on the same or different >> +block device. >> + >> +dm-integrity uses an encrypted key type, stored on the kernel keyring, to >> +obtain a secret key for use in cryptographic operations. Encrypted keys are >> +never exposed in plain text to user space. The encrypted keys are encrypted >> +using master key, which can either be a user defined or trusted key type. >> +The secret key, which is usually device specific, binds integrity data to >> the >> +device. As a result data blocks and corresponding HMACs cannot simply be >> +copied over from other file systems. >> + >> +Parameters: >> + >> \ >> +[] >> + >> + >> +This is the device that is going to be used to store the data. >> +You can specify it as a path like /dev/xxx or a device : >> +number. >> + >> + >> +Device block size. >> + >> + >> +Starting sector within the device where data begins. >> + >> + >> +This is the device that is going to be used to store integrity data. >> +You can specify it as a path like /dev/xxx or a device : >> +number. >> + >> + >> +HMAC device block size. >> + >> + >> +Starting sector within the device where integrity data begins. >> + >> + >> +Hash algorithm (sha1, sha256, etc). >> + >> + >> +HMAC algorithm, e.g. hmac(sha1), hmac(sha256), etc. >> + >> + >> +Description is a name of a key in the kernel keyring. >> + >> + >> +fix=1|0 - enable fix mode >> + In fix mode, incorrect hmacs are replaced with correct ones. >> + It is used for device initialization and debugging. >> + >> +stats=1|0 - turns on collecting additional statistical information. >> + It is used to find out resource usage to tune memory pool >> + and queue sizes for particular use case. >> + >> +verbose=1|0 - prints block number, collected hmac and stored hmac. >> + It is used for addition debug output. >> + >> + >> +Determine the size of integrity/hmac device >> +=== >> + >> +Every block device has corresponding hmac. >> +While NIST does recommend to use sha256 hash algorithm instead of SHA1, >> +this does not apply to hmac(sha1), because of keying. It is safe to use >> +hmac(sha1), because it takes much less space and it is faster to calculate. >> +hmac(sha1) size
Re: [PATCHv2 1/1] dm-integrity: integrity protection device-mapper target
Hello, Any comments? - Dmitry On Mon, Nov 26, 2012 at 4:39 PM, Dmitry Kasatkin wrote: > Device-mapper "integrity" target provides transparent cryptographic integrity > protection of the underlying read-write block device using hash-based message > authentication codes (HMACs). HMACs can be stored on the same or different > block device. > > dm-integrity uses an encrypted key type, stored on the kernel keyring, to > obtain a secret key for use in cryptographic operations. Encrypted keys are > never exposed in plain text to user space. The encrypted keys are encrypted > using master key, which can either be a user defined or trusted key type. > The secret key, which is usually device specific, binds integrity data to the > device. As a result data blocks and corresponding HMACs cannot simply be > copied over from other file systems. > > Signed-off-by: Dmitry Kasatkin > --- > Documentation/device-mapper/dm-integrity.txt | 137 > drivers/md/Kconfig | 13 + > drivers/md/Makefile |1 + > drivers/md/dm-integrity.c| 1050 > ++ > 4 files changed, 1201 insertions(+) > create mode 100644 Documentation/device-mapper/dm-integrity.txt > create mode 100644 drivers/md/dm-integrity.c > > diff --git a/Documentation/device-mapper/dm-integrity.txt > b/Documentation/device-mapper/dm-integrity.txt > new file mode 100644 > index 000..394242f > --- /dev/null > +++ b/Documentation/device-mapper/dm-integrity.txt > @@ -0,0 +1,137 @@ > +dm-integrity > +=== > + > +Device-mapper "integrity" target provides transparent cryptographic integrity > +protection of the underlying read-write block device using hash-based message > +authentication codes (HMACs). HMACs can be stored on the same or different > +block device. > + > +dm-integrity uses an encrypted key type, stored on the kernel keyring, to > +obtain a secret key for use in cryptographic operations. Encrypted keys are > +never exposed in plain text to user space. The encrypted keys are encrypted > +using master key, which can either be a user defined or trusted key type. > +The secret key, which is usually device specific, binds integrity data to the > +device. As a result data blocks and corresponding HMACs cannot simply be > +copied over from other file systems. > + > +Parameters: > + \ > +[] > + > + > +This is the device that is going to be used to store the data. > +You can specify it as a path like /dev/xxx or a device : > +number. > + > + > +Device block size. > + > + > +Starting sector within the device where data begins. > + > + > +This is the device that is going to be used to store integrity data. > +You can specify it as a path like /dev/xxx or a device : > +number. > + > + > +HMAC device block size. > + > + > +Starting sector within the device where integrity data begins. > + > + > +Hash algorithm (sha1, sha256, etc). > + > + > +HMAC algorithm, e.g. hmac(sha1), hmac(sha256), etc. > + > + > +Description is a name of a key in the kernel keyring. > + > + > +fix=1|0 - enable fix mode > + In fix mode, incorrect hmacs are replaced with correct ones. > + It is used for device initialization and debugging. > + > +stats=1|0 - turns on collecting additional statistical information. > + It is used to find out resource usage to tune memory pool > + and queue sizes for particular use case. > + > +verbose=1|0 - prints block number, collected hmac and stored hmac. > + It is used for addition debug output. > + > + > +Determine the size of integrity/hmac device > +=== > + > +Every block device has corresponding hmac. > +While NIST does recommend to use sha256 hash algorithm instead of SHA1, > +this does not apply to hmac(sha1), because of keying. It is safe to use > +hmac(sha1), because it takes much less space and it is faster to calculate. > +hmac(sha1) size is 20 bytes. So every 4k block on the integrity device can > +store 204 hmacs. In order to get the required size of the integrity device, > +it is necessary to divide data device size by 204. See examples bellow how > +to do it from script. > + > +Example scripts > +=== > + > +1. Setting up integrity target using data and hmac store on the same block > device. > + > +[[ > +#!/bin/sh > + > +bdev=$1 > + > +# block device size > +dsize=`blockdev --getsize $bdev` > +# block size > +bs=4096 > +# sector to block shift > +sbs=3 > +# integrity record size (hmac size) > +hmac=20 > +# hmacs per block > +hpb=$((bs/hmac)) > +# target device size > +size=$dsize>>sbs)*hpb/(hpb+1))< + > +# load the key - in this example we just use test key > +keyctl add user kmk "testing123" @u > +keyctl add encrypted dm-int-key "load `cat /etc/keys/dm-int-key`" @u > + > +# creating the target > +table="0 $size integrity $bdev 4096 0 $bdev 4096 $size sha1 hmac(sh
Re: [PATCH 0/7] crypto: omap-aes updates
Hello, I am not working on OMAP anymore and not able to test anything. But in general changes are OK for me. - Dmitry On Tue, Nov 20, 2012 at 2:08 PM, Kasatkin, Dmitry wrote: > Great. You also worked on AES... > Will take a loos asap. > > On Mon, Nov 19, 2012 at 9:03 PM, Mark A. Greer wrote: >> From: "Mark A. Greer" >> >> This series updates the crypto omap-aes driver and supporting >> infrastructure. >> >> Notes: >> >> a) Based on omap-sham patches recently submitted, XXX >> >> b) Since these patches will likely go though the OMAP tree (and not >>through the crypto tree), it would be nice if the crypto guy(s) >>would ACK or NACK patches 4-7 which modify the >>drivers/crypto/omap-sham.c driver. >> >> c) These have only been tested on an omap2420 h4 and an am37x evm. >> >> d) Many thanks to Jon Hunter for testing on his omap2420 h4. >> >> Mark A. Greer (7): >> ARM: OMAP2xxx: hwmod: Convert AES crypto devcie data to hwmod >> ARM: OMAP3xxx: hwmod: Convert AES crypto device data to hwmod >> ARM: OMAP2+: Remove unnecessary message when no AES IP is present >> crypto: omap-aes: Remove cpu_is/omap_type check from driver >> crypto: omap-aes: Convert to use pm_runtime API >> crypto: omap-aes: Add code to use dmaengine API >> crypto: omap-aes: Remove usage of private DMA API >> >> arch/arm/mach-omap2/clock2430_data.c | 1 + >> arch/arm/mach-omap2/clock3xxx_data.c | 1 + >> arch/arm/mach-omap2/devices.c | 75 +--- >> arch/arm/mach-omap2/omap_hwmod_2420_data.c | 1 + >> arch/arm/mach-omap2/omap_hwmod_2430_data.c | 1 + >> .../mach-omap2/omap_hwmod_2xxx_interconnect_data.c | 18 ++ >> arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 38 >> arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 62 +++ >> arch/arm/mach-omap2/omap_hwmod_common_data.h | 2 + >> drivers/crypto/omap-aes.c | 202 >> - >> 10 files changed, 251 insertions(+), 150 deletions(-) >> >> -- >> 1.7.12 >> -- 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 v4 0/8] crypto: omap-sham updates
Hello, I am not working on OMAP anymore and not able to test anything. But in general changes are OK for me. - Dmitry On Mon, Nov 19, 2012 at 8:54 PM, Mark A. Greer wrote: > From: "Mark A. Greer" > > Changes since v3: > - Added hwmod support for SIDLEMODE. This requires adding > a specific omap_hwmod_sysc_fields structure since there > are not generic ones that have the correct offsets. > - Added patch to remove the cpu check from the omap-sham > driver. This can likely be ignored since there is a patch > that already does this in Tony's branch. I added it to > make it easier for others to test while Tony's patch makes > its way to the k.o. > > Changes since v2: > - Reworked pm_runtime calls to match where original clk_* > calls were so provide better PM (as per Kevin Hilman's > comments). > > Changes since v1: > - Removed the check of CM_IDLEST to see if the module exists > and instead add the hwmod data for all omap2's and omap3 GP's. > - Placed new sha_ick clk entries after the 'omap-sham' entry > in the clockxxx_data.c files > - Removed cpu_is_xxx() checks in > arch/arm/mach-omap2/devices.c:omap_init_sham() > - Rebased on the latest k.o. kernel > > > This series updates the crypto omap-sham driver and supporting > infrastructure. > > Notes: > > a) Based on 3587b1b (fanotify: fix FAN_Q_OVERFLOW case of fanotify_read()). > > b) Since these patches will likely go though the OMAP tree (and not >through the crypto tree), it would be nice if the crypto guy(s) >would ACK or NACK patches 5-7 which modify the >drivers/crypto/omap-sham.c driver. > > c) These have only been tested on an omap2420 h4 and an am37x evm. If you >have different hardware available and a few minutes, please test them. >A quick and easy test is to enable tcrypt as a module >(CONFIG_CRYPTO_TEST=m), boot, then run 'modprobe tcrypt sec=2 mode=403'. >'CONFIG_CRYPTO_SHA1' and 'CONFIG_CRYPTO_DEV_OMAP_SHAM' also have to be >enabled. A quick 'grep omap-sham /proc/interrupts' will tell you if >the omap-sham driver was really used. > > d) To test these patches, you will likely need... >i) The patch included here: >http://marc.info/?l=kernel-janitors&m=134910841909057&w=2 >ii) This patch from linux-omap/master: >27615a9 (ARM: OMAP: Trivial driver changes to remove include >plat/cpu.h) >iii) This patch from Paul Walmsley: >http://www.spinics.net/lists/linux-omap/msg79436.html > > e) If you prefer, a version you can test is available at >g...@github.com:mgreeraz/linux-mag.git wip/crypto/sham-v3+test > > f) There is a reduction in DMA performance after switching to dmaengine >(see http://www.spinics.net/lists/linux-omap/msg79855.html) > > g) Many thanks to Jon Hunter for testing on his omap2420 h4. > > Mark A. Greer (8): > ARM: OMAP2xxx: hwmod: Convert SHAM crypto device data to hwmod > ARM: OMAP2xxx: hwmod: Add DMA support for SHAM module > ARM: OMAP3xxx: hwmod: Convert SHAM crypto device data to hwmod > ARM: OMAP2+: Remove unnecessary message when no SHA IP is present > crypto: omap-sham: Remove cpu_is/omap_type check from driver > crypto: omap-sham: Convert to use pm_runtime API > crypto: omap-sham: Add code to use dmaengine API > crypto: omap_sham: Remove usage of private DMA API > > arch/arm/mach-omap2/clock2430_data.c | 1 + > arch/arm/mach-omap2/clock3xxx_data.c | 1 + > arch/arm/mach-omap2/devices.c | 73 ++-- > arch/arm/mach-omap2/omap_hwmod_2420_data.c | 1 + > arch/arm/mach-omap2/omap_hwmod_2430_data.c | 1 + > .../mach-omap2/omap_hwmod_2xxx_interconnect_data.c | 18 ++ > arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 43 + > arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 66 +++ > arch/arm/mach-omap2/omap_hwmod_common_data.h | 2 + > drivers/crypto/omap-sham.c | 202 > +++-- > 10 files changed, 251 insertions(+), 157 deletions(-) > > -- > 1.7.12 > -- 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 0/7] crypto: omap-aes updates
Great. You also worked on AES... Will take a loos asap. On Mon, Nov 19, 2012 at 9:03 PM, Mark A. Greer wrote: > From: "Mark A. Greer" > > This series updates the crypto omap-aes driver and supporting > infrastructure. > > Notes: > > a) Based on omap-sham patches recently submitted, XXX > > b) Since these patches will likely go though the OMAP tree (and not >through the crypto tree), it would be nice if the crypto guy(s) >would ACK or NACK patches 4-7 which modify the >drivers/crypto/omap-sham.c driver. > > c) These have only been tested on an omap2420 h4 and an am37x evm. > > d) Many thanks to Jon Hunter for testing on his omap2420 h4. > > Mark A. Greer (7): > ARM: OMAP2xxx: hwmod: Convert AES crypto devcie data to hwmod > ARM: OMAP3xxx: hwmod: Convert AES crypto device data to hwmod > ARM: OMAP2+: Remove unnecessary message when no AES IP is present > crypto: omap-aes: Remove cpu_is/omap_type check from driver > crypto: omap-aes: Convert to use pm_runtime API > crypto: omap-aes: Add code to use dmaengine API > crypto: omap-aes: Remove usage of private DMA API > > arch/arm/mach-omap2/clock2430_data.c | 1 + > arch/arm/mach-omap2/clock3xxx_data.c | 1 + > arch/arm/mach-omap2/devices.c | 75 +--- > arch/arm/mach-omap2/omap_hwmod_2420_data.c | 1 + > arch/arm/mach-omap2/omap_hwmod_2430_data.c | 1 + > .../mach-omap2/omap_hwmod_2xxx_interconnect_data.c | 18 ++ > arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 38 > arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 62 +++ > arch/arm/mach-omap2/omap_hwmod_common_data.h | 2 + > drivers/crypto/omap-aes.c | 202 > - > 10 files changed, 251 insertions(+), 150 deletions(-) > > -- > 1.7.12 > -- 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 v3 7/7] crypto: omap_sham: Remove usage of private DMA API
On Fri, Nov 9, 2012 at 9:17 AM, Mark A. Greer wrote: > On Fri, Nov 09, 2012 at 06:28:16PM +0200, Kasatkin, Dmitry wrote: >> On Wed, Nov 7, 2012 at 4:57 AM, Mark A. Greer wrote: >> > From: "Mark A. Greer" >> > >> > Remove usage of the private OMAP DMA API. >> > The dmaengine API will be used instead. >> > >> > CC: Russell King >> > CC: Dmitry Kasatkin >> > Signed-off-by: Mark A. Greer >> > --- >> > drivers/crypto/omap-sham.c | 117 >> > - >> > 1 file changed, 117 deletions(-) >> > >> > diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c >> > index b57277c..ebb5255 100644 >> > --- a/drivers/crypto/omap-sham.c >> > +++ b/drivers/crypto/omap-sham.c > >> > @@ -807,18 +762,6 @@ static int omap_sham_handle_queue(struct >> > omap_sham_dev *dd, >> > if (err) >> > goto err1; >> > >> > -#ifdef OMAP_SHAM_DMA_PRIVATE >> > - omap_set_dma_dest_params(dd->dma_lch, 0, >> > - OMAP_DMA_AMODE_CONSTANT, >> > - dd->phys_base + SHA_REG_DIN(0), 0, 16); >> > - >> > - omap_set_dma_dest_burst_mode(dd->dma_lch, >> > - OMAP_DMA_DATA_BURST_16); >> > - >> > - omap_set_dma_src_burst_mode(dd->dma_lch, >> > - OMAP_DMA_DATA_BURST_4); >> >> Burst mode significantly improves performance. >> How do you configure burst mode with new API? > > This is (or should be) taken care of by the dmaengine infrastructure. > I've noted that there's an issue and there is a discussion about it > here: > > http://www.spinics.net/lists/linux-omap/msg79855.html > > We probably need to extend the dmaengine API to allow API-users to > request specific tweaks/optimizations/whatever but that's MHO. > Hello, I am in favor of new APIs. The only my concern is that it performs worse.. Is it possible to keep burst mode setting there? - Dmitry > Mark > -- -- 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 v3 7/7] crypto: omap_sham: Remove usage of private DMA API
On Wed, Nov 7, 2012 at 4:57 AM, Mark A. Greer wrote:
> From: "Mark A. Greer"
>
> Remove usage of the private OMAP DMA API.
> The dmaengine API will be used instead.
>
> CC: Russell King
> CC: Dmitry Kasatkin
> Signed-off-by: Mark A. Greer
> ---
> drivers/crypto/omap-sham.c | 117
> -
> 1 file changed, 117 deletions(-)
>
> diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
> index b57277c..ebb5255 100644
> --- a/drivers/crypto/omap-sham.c
> +++ b/drivers/crypto/omap-sham.c
> @@ -13,8 +13,6 @@
> * Some ideas are from old omap-sha1-md5.c driver.
> */
>
> -#define OMAP_SHAM_DMA_PRIVATE
> -
> #define pr_fmt(fmt) "%s: " fmt, __func__
>
> #include
> @@ -29,10 +27,8 @@
> #include
> #include
> #include
> -#ifndef OMAP_SHAM_DMA_PRIVATE
> #include
> #include
> -#endif
> #include
> #include
> #include
> @@ -43,12 +39,6 @@
> #include
> #include
>
> -#ifdef OMAP_SHAM_DMA_PRIVATE
> -#include
> -#include
> -#include
> -#endif
> -
> #define SHA_REG_DIGEST(x) (0x00 + ((x) * 0x04))
> #define SHA_REG_DIN(x) (0x1C + ((x) * 0x04))
>
> @@ -120,9 +110,7 @@ struct omap_sham_reqctx {
>
> /* walk state */
> struct scatterlist *sg;
> -#ifndef OMAP_SHAM_DMA_PRIVATE
> struct scatterlist sgl;
> -#endif
> unsigned intoffset; /* offset in current sg */
> unsigned inttotal; /* total request */
>
> @@ -156,12 +144,7 @@ struct omap_sham_dev {
> int irq;
> spinlock_t lock;
> int err;
> -#ifdef OMAP_SHAM_DMA_PRIVATE
> - int dma;
> - int dma_lch;
> -#else
> struct dma_chan *dma_lch;
> -#endif
> struct tasklet_struct done_task;
>
> unsigned long flags;
> @@ -331,7 +314,6 @@ static int omap_sham_xmit_cpu(struct omap_sham_dev *dd,
> const u8 *buf,
> return -EINPROGRESS;
> }
>
> -#ifndef OMAP_SHAM_DMA_PRIVATE
> static void omap_sham_dma_callback(void *param)
> {
> struct omap_sham_dev *dd = param;
> @@ -339,34 +321,18 @@ static void omap_sham_dma_callback(void *param)
> set_bit(FLAGS_DMA_READY, &dd->flags);
> tasklet_schedule(&dd->done_task);
> }
> -#endif
>
> static int omap_sham_xmit_dma(struct omap_sham_dev *dd, dma_addr_t dma_addr,
> size_t length, int final, int is_sg)
> {
> struct omap_sham_reqctx *ctx = ahash_request_ctx(dd->req);
> -#ifdef OMAP_SHAM_DMA_PRIVATE
> - int len32;
> -#else
> struct dma_async_tx_descriptor *tx;
> struct dma_slave_config cfg;
> int ret;
> -#endif
>
> dev_dbg(dd->dev, "xmit_dma: digcnt: %d, length: %d, final: %d\n",
> ctx->digcnt, length, final);
>
> -#ifdef OMAP_SHAM_DMA_PRIVATE
> - len32 = DIV_ROUND_UP(length, sizeof(u32));
> -
> - omap_set_dma_transfer_params(dd->dma_lch, OMAP_DMA_DATA_TYPE_S32,
> len32,
> - 1, OMAP_DMA_SYNC_PACKET, dd->dma,
> - OMAP_DMA_DST_SYNC_PREFETCH);
> -
> - omap_set_dma_src_params(dd->dma_lch, 0, OMAP_DMA_AMODE_POST_INC,
> - dma_addr, 0, 0);
> -
> -#else
> memset(&cfg, 0, sizeof(cfg));
>
> cfg.dst_addr = dd->phys_base + SHA_REG_DIN(0);
> @@ -406,7 +372,6 @@ static int omap_sham_xmit_dma(struct omap_sham_dev *dd,
> dma_addr_t dma_addr,
>
> tx->callback = omap_sham_dma_callback;
> tx->callback_param = dd;
> -#endif
>
> omap_sham_write_ctrl(dd, length, final, 1);
>
> @@ -417,12 +382,8 @@ static int omap_sham_xmit_dma(struct omap_sham_dev *dd,
> dma_addr_t dma_addr,
>
> set_bit(FLAGS_DMA_ACTIVE, &dd->flags);
>
> -#ifdef OMAP_SHAM_DMA_PRIVATE
> - omap_start_dma(dd->dma_lch);
> -#else
> dmaengine_submit(tx);
> dma_async_issue_pending(dd->dma_lch);
> -#endif
>
> return -EINPROGRESS;
> }
> @@ -528,7 +489,6 @@ static int omap_sham_update_dma_start(struct
> omap_sham_dev *dd)
> if (ctx->bufcnt || ctx->offset)
> return omap_sham_update_dma_slow(dd);
>
> -#ifndef OMAP_SHAM_DMA_PRIVATE
> /*
> * Don't use the sg interface when the transfer size is less
> * than the number of elements in a DMA frame. Otherwise,
> @@ -537,7 +497,6 @@ static int omap_sham_update_dma_start(struct
> omap_sham_dev *dd)
> */
> if (ctx->total < (DST_MAXBURST * sizeof(u32)))
> return omap_sham_update_dma_slow(dd);
> -#endif
>
> dev_dbg(dd->dev, "fast: digcnt: %d, bufcnt: %u, total: %u\n",
> ctx->digcnt, ctx->bufcnt, ctx->total);
> @@ -599,11 +558,7 @@ static int omap_sham_update_dma_stop(struct
> omap_sham_dev *dd)
> {
> struct omap_sham_reqctx *ctx = ahash_request_ctx(dd->req);
>
> -#ifdef O
Re: [PATCH v3 3/7] ARM: OMAP3xxx: hwmod: Convert SHAM crypto device data to hwmod
On Wed, Nov 7, 2012 at 4:57 AM, Mark A. Greer wrote:
> From: "Mark A. Greer"
>
> Convert the device data for the OMAP3 SHAM2 (SHA1/MD5) crypto IP
> from explicit platform_data to hwmod.
>
> CC: Paul Walmsley
> Signed-off-by: Mark A. Greer
> ---
> arch/arm/mach-omap2/clock3xxx_data.c | 1 +
> arch/arm/mach-omap2/devices.c | 42 ++---
> arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 60
> ++
> 3 files changed, 64 insertions(+), 39 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
> b/arch/arm/mach-omap2/clock3xxx_data.c
> index 1f42c9d..6f14d9b 100644
> --- a/arch/arm/mach-omap2/clock3xxx_data.c
> +++ b/arch/arm/mach-omap2/clock3xxx_data.c
> @@ -3342,6 +3342,7 @@ static struct omap_clk omap3xxx_clks[] = {
> CLK(NULL, "icr_ick", &icr_ick, CK_34XX | CK_36XX),
> CLK("omap-aes", "ick", &aes2_ick, CK_34XX | CK_36XX),
> CLK("omap-sham","ick", &sha12_ick, CK_34XX | CK_36XX),
> + CLK(NULL, "sha12_ick",&sha12_ick, CK_34XX | CK_36XX),
> CLK(NULL, "des2_ick", &des2_ick, CK_34XX | CK_36XX),
> CLK("omap_hsmmc.1", "ick", &mmchs2_ick,CK_3XXX),
> CLK("omap_hsmmc.0", "ick", &mmchs1_ick,CK_3XXX),
> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> index f18fa50..f38ac9d 100644
> --- a/arch/arm/mach-omap2/devices.c
> +++ b/arch/arm/mach-omap2/devices.c
> @@ -36,6 +36,7 @@
> #include "devices.h"
> #include "cm2xxx_3xxx.h"
> #include "cm-regbits-24xx.h"
> +#include "cm-regbits-34xx.h"
>
> #define L3_MODULES_MAX_LEN 12
> #define L3_MODULES 3
> @@ -453,38 +454,9 @@ static void omap_init_rng(void)
> WARN(IS_ERR(pdev), "Can't build omap_device for omap_rng\n");
> }
>
> -#if defined(CONFIG_CRYPTO_DEV_OMAP_SHAM) ||
> defined(CONFIG_CRYPTO_DEV_OMAP_SHAM_MODULE)
> -
> -#ifdef CONFIG_ARCH_OMAP3
> -static struct resource omap3_sham_resources[] = {
> - {
> - .start = OMAP34XX_SEC_SHA1MD5_BASE,
> - .end= OMAP34XX_SEC_SHA1MD5_BASE + 0x64,
> - .flags = IORESOURCE_MEM,
> - },
> - {
> - .start = 49 + OMAP_INTC_START,
> - .flags = IORESOURCE_IRQ,
> - },
> - {
> - .start = OMAP34XX_DMA_SHA1MD5_RX,
> - .flags = IORESOURCE_DMA,
> - }
> -};
Ok... it is also for OMAP3..
> -static int omap3_sham_resources_sz = ARRAY_SIZE(omap3_sham_resources);
> -#else
> -#define omap3_sham_resources NULL
> -#define omap3_sham_resources_sz0
> -#endif
> -
> -static struct platform_device sham_device = {
> - .name = "omap-sham",
> - .id = -1,
> -};
> -
> -static void omap_init_sham(void)
> +static void __init omap_init_sham(void)
> {
> - if (cpu_is_omap24xx()) {
> + if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
> struct omap_hwmod *oh;
> struct platform_device *pdev;
>
> @@ -495,18 +467,10 @@ static void omap_init_sham(void)
> pdev = omap_device_build("omap-sham", -1, oh, NULL, 0, NULL,
> 0, 0);
> WARN(IS_ERR(pdev), "Can't build omap_device for omap-sham\n");
> - } else if (cpu_is_omap34xx()) {
> - sham_device.resource = omap3_sham_resources;
> - sham_device.num_resources = omap3_sham_resources_sz;
> - platform_device_register(&sham_device);
> } else {
> pr_err("%s: platform not supported\n", __func__);
> - return;
> }
> }
> -#else
> -static inline void omap_init_sham(void) { }
> -#endif
>
> #if defined(CONFIG_CRYPTO_DEV_OMAP_AES) ||
> defined(CONFIG_CRYPTO_DEV_OMAP_AES_MODULE)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> index f67b7ee..785a0c5 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> @@ -3543,6 +3543,65 @@ static struct omap_hwmod_ocp_if omap3xxx_l3_main__gpmc
> = {
> .user = OCP_USER_MPU | OCP_USER_SDMA,
> };
>
> +/* l4_core -> SHAM2 (SHA1/MD5) (similar to omap24xx) */
> +static struct omap_hwmod_class_sysconfig omap3_sham_sysc = {
> + .rev_offs = 0x5c,
> + .sysc_offs = 0x60,
> + .syss_offs = 0x64,
> + .sysc_flags = (SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE |
> + SYSS_HAS_RESET_STATUS),
> + .sysc_fields= &omap_hwmod_sysc_type1,
> +};
> +
> +static struct omap_hwmod_class omap3xxx_sham_class = {
> + .name = "sham",
> + .sysc = &omap3_sham_sysc,
> +};
> +
> +struct omap_hwmod_irq_info omap3_sham_mpu_irqs[] = {
> + { .irq = 49 + OMAP_INTC_START, },
> + { .irq = -1 }
> +};
> +
> +struct omap_hwmod_dma_info omap3_sham_sdma_reqs[] = {
> + {
Re: [PATCH v3 1/7] ARM: OMAP2xxx: hwmod: Convert SHAM crypto device data to hwmod
Hello,
On Wed, Nov 7, 2012 at 4:57 AM, Mark A. Greer wrote:
> From: "Mark A. Greer"
>
> Convert the device data for the OMAP2 SHAM crypto IP from
> explicit platform_data to hwmod.
>
> CC: Paul Walmsley
> Signed-off-by: Mark A. Greer
> ---
> arch/arm/mach-omap2/clock2430_data.c | 1 +
> arch/arm/mach-omap2/devices.c | 34
> arch/arm/mach-omap2/omap_hwmod_2420_data.c | 1 +
> arch/arm/mach-omap2/omap_hwmod_2430_data.c | 1 +
> .../mach-omap2/omap_hwmod_2xxx_interconnect_data.c | 18 +++
> arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 37
> ++
> arch/arm/mach-omap2/omap_hwmod_common_data.h | 2 ++
> 7 files changed, 73 insertions(+), 21 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/clock2430_data.c
> b/arch/arm/mach-omap2/clock2430_data.c
> index 22404fe..4d52ec6 100644
> --- a/arch/arm/mach-omap2/clock2430_data.c
> +++ b/arch/arm/mach-omap2/clock2430_data.c
> @@ -1993,6 +1993,7 @@ static struct omap_clk omap2430_clks[] = {
> CLK(NULL, "sdrc_ick", &sdrc_ick, CK_243X),
> CLK(NULL, "des_ick", &des_ick, CK_243X),
> CLK("omap-sham","ick", &sha_ick, CK_243X),
> + CLK(NULL, "sha_ick", &sha_ick, CK_242X),
> CLK("omap_rng", "ick", &rng_ick, CK_243X),
> CLK(NULL, "rng_ick", &rng_ick, CK_243X),
> CLK("omap-aes", "ick", &aes_ick, CK_243X),
> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> index cba60e0..f18fa50 100644
> --- a/arch/arm/mach-omap2/devices.c
> +++ b/arch/arm/mach-omap2/devices.c
> @@ -34,6 +34,8 @@
> #include "mux.h"
> #include "control.h"
> #include "devices.h"
> +#include "cm2xxx_3xxx.h"
> +#include "cm-regbits-24xx.h"
>
> #define L3_MODULES_MAX_LEN 12
> #define L3_MODULES 3
> @@ -453,24 +455,6 @@ static void omap_init_rng(void)
>
> #if defined(CONFIG_CRYPTO_DEV_OMAP_SHAM) ||
> defined(CONFIG_CRYPTO_DEV_OMAP_SHAM_MODULE)
>
> -#ifdef CONFIG_ARCH_OMAP2
> -static struct resource omap2_sham_resources[] = {
> - {
> - .start = OMAP24XX_SEC_SHA1MD5_BASE,
> - .end= OMAP24XX_SEC_SHA1MD5_BASE + 0x64,
> - .flags = IORESOURCE_MEM,
> - },
> - {
> - .start = 51 + OMAP_INTC_START,
> - .flags = IORESOURCE_IRQ,
> - }
> -};
> -static int omap2_sham_resources_sz = ARRAY_SIZE(omap2_sham_resources);
> -#else
> -#define omap2_sham_resources NULL
> -#define omap2_sham_resources_sz0
> -#endif
> -
> #ifdef CONFIG_ARCH_OMAP3
> static struct resource omap3_sham_resources[] = {
> {
> @@ -501,16 +485,24 @@ static struct platform_device sham_device = {
> static void omap_init_sham(void)
> {
> if (cpu_is_omap24xx()) {
> - sham_device.resource = omap2_sham_resources;
> - sham_device.num_resources = omap2_sham_resources_sz;
> + struct omap_hwmod *oh;
> + struct platform_device *pdev;
> +
> + oh = omap_hwmod_lookup("sham");
> + if (!oh)
> + return;
> +
> + pdev = omap_device_build("omap-sham", -1, oh, NULL, 0, NULL,
> +0, 0);
> + WARN(IS_ERR(pdev), "Can't build omap_device for omap-sham\n");
> } else if (cpu_is_omap34xx()) {
> sham_device.resource = omap3_sham_resources;
> sham_device.num_resources = omap3_sham_resources_sz;
> + platform_device_register(&sham_device);
Why changes are only for OMAP2?
OMAP3 is also the same class.
> } else {
> pr_err("%s: platform not supported\n", __func__);
> return;
> }
> - platform_device_register(&sham_device);
> }
> #else
> static inline void omap_init_sham(void) { }
> diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
> b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
> index b5db600..b102a53 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
> @@ -603,6 +603,7 @@ static struct omap_hwmod_ocp_if *omap2420_hwmod_ocp_ifs[]
> __initdata = {
> &omap2420_l4_core__mcbsp2,
> &omap2420_l4_core__msdi1,
> &omap2xxx_l4_core__rng,
> + &omap2xxx_l4_core__sham,
> &omap2420_l4_core__hdq1w,
> &omap2420_l4_wkup__counter_32k,
> &omap2420_l3__gpmc,
> diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
> b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
> index c455e41..b1ce7b0 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
> @@ -963,6 +963,7 @@ static struct omap_hwmod_ocp_if *omap2430_hwmod_ocp_ifs[]
> __initdata = {
> &omap2430_l4_core__mcbsp5,
> &omap2430_l4_core__hdq1w,
>
Re: [GIT PULL] Asymmetric keys and module signing
On Thu, Oct 4, 2012 at 2:22 AM, Rusty Russell wrote: > David Howells writes: > >> Rusty Russell wrote: >> >>> Right. I think we need to use different names for generated vs supplied >>> files >> >> The problem with supplied files is people who do allyesconfig, allmodconfig >> and randconfig just to test things finding that their builds break. The >> kernel build magic is not really set up to handle external files like this. >> I >> suppose make logic can be used to conditionally include stuff that might not >> exist. >> >>> BTW, you missed a Signed-off-by: on your "MODSIGN: Use the same digest >>> for the autogen key sig as for the module sig" patch. Please update. >> >> Done. >> >> I've also added a patch to convert the system clock to a struct tm and to >> produce a struct tm within the ASN.1 decode and then compare those rather >> than >> time_t values as a way to deal with the validity time overflow problem. We >> may have to be able to handle certificates that we haven't generated that >> stretch beyond 2038 (I wonder if we might find such in the UEFI key database >> for example. > > OK, cherry-picked to replace my hack. > > It's in linux-next, and I will push in the next two days. > http://git.kernel.org/?p=linux/kernel/git/rusty/linux.git;a=commit;h=a15e196c5543d1d2d7f0cd70e62351aeb1f8b871 It breaks bisect.. CC kernel/module_signing.o kernel/module_signing.c: In function ‘mod_verify_sig’: kernel/module_signing.c:21:10: error: ‘ENOKEY’ undeclared (first use in this function) kernel/module_signing.c:21:10: note: each undeclared identifier is reported only once for each function it appears in kernel/module_signing.c:22:1: warning: control reaches end of non-void function [-Wreturn-type] make[1]: *** [kernel/module_signing.o] Error 1 make: *** [kernel] Error 2 make: *** Waiting for unfinished jobs > Thanks, > Rusty. > -- > 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 -- 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: [GIT PULL] Asymmetric keys and module signing
Hello David,
As I can see API has changed towards our discussion on KS.
Now digest can be supplied to the verify_signature in a
public_key_signature argument.
It looks that in such away we can use this API for IMA/EVM as well.
Just one question about key description...
request_asymmetric_key uses format for key description: ": ".
Preparsing code creates description from those values.
I see that key id is not 8 bytes anymore but full hash size of 20 bytes.
For practical reasons for IMA it might be nice to save some space in
xattrs and use shorter key id/description.
As I understand from implementation, if key name is provided with
"keyctl add", it will not be replaced with
preparsed value.
Right?
And we can actually use any keyid we want?
- Dmitry
On Tue, Sep 25, 2012 at 3:07 AM, David Howells wrote:
>
> Hi Herbert, Rusty,
>
> Here are my latest module signing patches on top of the asymmetric key crypto
> patches, which I hope Herbert will consider taking, at least from the
> crypto-keys-post-KS branch:
>
>
> http://git.kernel.org/?p=linux/kernel/git/dhowells/linux-modsign.git;a=shortlog;h=refs/heads/crypto-keys-post-KS
>
> The module signing patches go on top of those, and the set can be found here:
>
>
> http://git.kernel.org/?p=linux/kernel/git/dhowells/linux-modsign.git;a=shortlog;h=refs/heads/modsign-post-KS
>
> Do you want the patches posting to the lists? I've tried posting the series
> as one, but there seems to be a problem posting the merge commit in the middle
> because it has two parents:-/
>
> Anyway...
>
>
> The module signing patches provide:
>
> - Some fixes to Rusty's patch. Also an additional patch to extend the policy
>handling for modules signed with an unknown key and to handle FIPS mode.
>
> - Module signature generation and checking. The signature format is:
>
>
>
>
>
>
>The fixed-length sig-information-block indicates the crypto algorithm (RSA
>only for the moment), the hash type (SHA512 for example) and the identifier
>scope (X.509 in this case), plus the lengths of the other three parts.
>
>The binary-key-id could be rendered as hex and pasted onto the end of the
>signer-id-string so that the kernel doesn't have to do the conversion.
>
>A script is provided in one of the patches to generate the signer name and
>key ID parts from the X.509 cert for later inclusion in module signatures
>during the build.
>
> - A transient X.509 cert will be automatically generated if one is not given
>and will be used to automatically sign the modules after they've been
>thoroughly stripped.
>
>Note that this may prove not to be the best way for distributions to do
>things. We're currently looking at the best way being to do the stripping
>and signing manually from the RPM spec file after the make modules_install
>step and after the debuginfo has been extracted, so automatic signing may
>need to go away, or at least become optional.
>
>To make this easier, a script is provided to sign a module and this can be
>called either from the Makefile or the spec file.
>
> - An 'extra_certificates' file can be placed in the root of the kernel build
>containing a number of supplementary X.509 certs just cat'd together.
> These
>will get added to the internal keyring and can then be used to check module
>signatures also.
>
>
> I have also fixed a number of things in the crypto patches:
>
> - GeneralizedTime and GeneralString were transposed in the ASN.1 compiler
>directive table and enum token_type ('S' comes before 'i' to strcmp()),
>resulting in it not being possible to use either.
>
> - I had made it a requirement that the X.509 certificate subjectKeyIdentifier
>and authorityKeyIdentifier extensions exist so that we can validate the
>X.509 signature if possible, but I hadn't put in any checks that they'd
> been
>found before using the values extracted, leading to a crash.
>
> - I fixed header length computation in ASN.1 decoder resulting making it
>possible to discard one of the x509.asn1 callback actions (we can locate
> the
>start of the TBS container directly now by subtraction).
>
> - I got rid of the fingerprint bit at the end of the public_key struct as
> it's
>superfluous (the asymmetric key type stores the fingerprint attached to
>key->type_data.p[1]).
>
> - I made the X.509 parser render the key description in a more compact
> manner:
>
>The description is split into two parts: ": ".
>
>The is a hex rendering of the key identifier - in the case of
> X.509
>that would be the contents of the subjectKeyIdentifier extension field with
>the ASN.1 OctetString wrapper removed.
>
>The is (in order) one of:
>
> - The O and CN attributes as ": " if the CN attribute
> isn't prefixed with the O attribute, and, if longer, doesn't share
> the same first seven chars
Re: [PATCH 0/1] dm-integrity: integrity protection device-mapper target
On Tue, Sep 25, 2012 at 3:15 PM, Milan Broz wrote: > > On 09/24/2012 06:20 PM, Kasatkin, Dmitry wrote: > >>> So it can provide confidentiality but it CANNOT provide integrity >>> protection. >>> >> Yes, it provides confidentiality and via encryption it provides >> certain level of integrity protection. >> Data cannot be modified without being detected. >> Decryption will result in garbage... > > It should, but it is not cryptographic integrity protection. > Moreover, you can revert ciphertext sector content. > > Btw I think dm-integrity doesn't solve the reply problem as well. > > (IOW can you replace/revert both data and hash, still using the same key > in keyring, without dm-integrity able to detect it?) Yes, reply problem is the same. It is context free. > > In dm-verity, root hash will change after such data tampering. > yes, I know. >>> Obvious question: can be dm-verity extended to provide read-write integrity? >>> >> >> I think re-calculating hash trees all the time and syncing block >> hashes and tree itself is heavier operation... > > Then why not extend dm-verity to use you hash format? There are options > for that and we can redefine table line if necessary. > dm-integrity does not use hash tree. switching tree to hmac needs to recalculating everything. It simply does not make sense. > (You are duplicating a lot of code here otherwise, not counting userspace > yet.) > All targets have similarities here and there. At the end they work in different way. >From source code point of it is clearer to keep them separately as they do things in different way. It does not require any user space tools. > Whatever, I shortly read the code and have some notes. > > First, device-mapper is variable system, you can stack devices in arbitrary > order. > > Unfortunately, this is something what can be dangerous in crypto, here you > can e.g. > - do mac (integrity) then encrypt > - do encrypt, then check integrity > > In many implementations mac-then-encrypt system was not secure. > Are we sure that it cannot provide side channels here? > > Note read-only integrity target (like dm-verity) is specific case, you should > not be able to run any chosen ciphertext attacks here, it is read-only device. > > In fact, I am not sure if we should provide separate read-write block > integrity > (wihtout encryption) target at all. > > Either it should use standard mode of authenticated encryption (like GCM) > or data integrity should be upper layer business (which knows better which > data > really need integrity checking and which areas are just unused garbage. > If you consider hashing and encryption as "heavy operation" you should > minimize > it to only really used area - and only upper layer know about real used data > content.) > > (Again, this is different for read-only target, where it usually uses > compressed > RO fs image which uses all available space.) > Again, as it is written in cover letter. It can be used for certain use cases, which does not want encryption for performance or data transforming reasons... > > 1) discards > It seems the dm-integrity target doesn't solve problem with discards. > > If you send discard request to underlying device, data content of discarded > area > is undefined (or zeroed if discards zeroes data) but is is definitely > "invalid" > form the dm-integrity point of view. And you are allowing discard IOs there. > I will check about it. > I am not sure what should happen, but the behaviour should be documented (at > least) > or disabled. > > 2) > All used hash algorithms must be configurable. > dm-integrity uses HASH and HMAC together for HW enabling reasons... Hash is calculated using async API and HMAC is sync. Hash algorithm is configurable. There is a target parameter for that [] HMAC is different... Because of using key, hmac(sha1) is not vulnerable to attacks as sha1... There is currently absolutely no reason to use hmac(sha256) or other. hmac(sha1) is absolutely enough... Before I used only sync API and it was a parameter for hmac only. Now there is hash only parameter.. But this is not an issue. I could easily have a parameter for hmac.. > From your doc: > > +While NIST does recommend to use SHA256 hash algorithm instead of SHA1, > +this does not apply to HMAC(SHA1), because of keying. > +This target uses HMAC(SHA1), because it takes much less space and it is > +faster to calculate. There is no parameter to change hmac hash algorithm. > > While this is technically true, > http://csrc.nist.gov/groups/ST/hash/policy.html > disallowing use of another hash algorithm is wrong, and i
Re: [PATCH 0/1] dm-integrity: integrity protection device-mapper target
On Mon, Sep 24, 2012 at 4:47 PM, Milan Broz wrote: > On 09/24/2012 11:55 AM, Dmitry Kasatkin wrote: >> Both dm-verity and dm-crypt provide block level integrity protection. > > This is not correct. dm-crypt is transparent block encryption target, > where always size of plaintext == size of ciphertext. > Of course... It is just said in relation to integrity protection. It is said about encryption in following paragraphs... > So it can provide confidentiality but it CANNOT provide integrity protection. > Yes, it provides confidentiality and via encryption it provides certain level of integrity protection. Data cannot be modified without being detected. Decryption will result in garbage... > We need extra space to store auth tag which dmcrypt cannot provide currently. > >> dm-integrity provides a lighter weight read-write block level integrity >> protection for file systems not requiring full disk encryption, but >> which do require writability. > > Obvious question: can be dm-verity extended to provide read-write integrity? > I think re-calculating hash trees all the time and syncing block hashes and tree itself is heavier operation... > I would prefer to use standard mode like GCM to provide both encryption and > integrity protection than inventing something new. As said, if encryption is considered heavy operation in term of CPU and battery usage and also if encryption is not desired for some reasons that would be an option. - Dmitry > > Milan -- 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
async hash & hmac
Hello,
When allocating hmac like: crypto_alloc_ahash("hmac(sha1)", ..),
it is actually fallsback to "shash" hmac and software shash hash
implementation..
Even when HW accelerator provides AHASH it will not be used with hmac.
Basically HW driver needs to provide its own implementation for async
hmac, like I did for omap-sham.
.cra_name = "hmac(sha1)",
.cra_driver_name= "omap-hmac-sha1",
Is that correct, right?
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: CRYPTO_ALG_ASYNC
On Thu, May 10, 2012 at 1:47 PM, Herbert Xu wrote: > On Thu, May 10, 2012 at 01:31:10PM +0300, Kasatkin, Dmitry wrote: >> >> But why do we need it for AHASH or ABLKCIPHER? >> It is obvious without it that they can be async? > > It makes sense for ahash/ablkcipher since even though you're > using the async API you can still request for a sync implementation. What I can see this flag is not tested and used. Where is the place of code where it "returns" sync implementation? - Dmitry > > Cheers, > -- > Email: Herbert Xu > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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: CRYPTO_ALG_ASYNC
On Thu, May 10, 2012 at 1:16 PM, Herbert Xu wrote: > On Thu, May 10, 2012 at 12:33:40PM +0300, Kasatkin, Dmitry wrote: >> Hello Herbert, >> >> CRYPTO_ALG_ASYNC is heavily used like: >> >> crypto_alloc_shash(hash_alg, 0, CRYPTO_ALG_ASYNC); > > Where did you see that? There is no need to specify ASYNC in the > mask for shash since they're always synchronous. > Yes, that is why I wonder... For example in security/keys/ But why do we need it for AHASH or ABLKCIPHER? It is obvious without it that they can be async? - Dmitry > Cheers, > -- > Email: Herbert Xu > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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 v2.2 2/7] crypto: GnuPG based MPI lib - header files (part 2)
On Wed, Mar 21, 2012 at 10:39 AM, Geert Uytterhoeven
wrote:
> Ping?
>
> On Sun, Mar 11, 2012 at 10:55, Geert Uytterhoeven
> wrote:
>> On Wed, 19 Oct 2011, Dmitry Kasatkin wrote:
>>> Adds the multi-precision-integer maths library which was originally taken
>>> from GnuPG and ported to the kernel by (among others) David Howells.
>>> This version is taken from Fedora kernel 2.6.32-71.14.1.el6.
>>> The difference is that checkpatch reported errors and warnings have been
>>> fixed.
>>>
>>> This library is used to implemenet RSA digital signature verification
>>> used in IMA/EVM integrity protection subsystem.
>>
>>> --- /dev/null
>>> +++ b/lib/mpi/longlong.h
>>
>>> + /* If udiv_qrnnd was not defined for this processor, use
>>> __udiv_qrnnd_c. */
>>> +#if !defined(udiv_qrnnd)
>>> +#define UDIV_NEEDS_NORMALIZATION 1
>>> +#define udiv_qrnnd __udiv_qrnnd_c
>>> +#endif
>>> +
>>> +#undef count_leading_zeros
>>
>> Why is this #undef here? It's not present in mpi/longlong.h from Ubuntu's
>> gnupg-1.4.10, and causing ...
>>
>>> +#if !defined(count_leading_zeros)
>>> + extern
>>> +#ifdef __STDC__
>>> + const
>>> +#endif
>>> + unsigned char __clz_tab[];
>>> +#define count_leading_zeros(count, x) \
>>> +do { \
>>> + UWtype __xr = (x); \
>>> + UWtype __a; \
>>> + \
>>> + if (W_TYPE_SIZE <= 32) { \
>>> + __a = __xr < ((UWtype) 1 << 2*__BITS4) \
>>> + ? (__xr < ((UWtype) 1 << __BITS4) ? 0 : __BITS4) \
>>> + : (__xr < ((UWtype) 1 << 3*__BITS4) ? 2*__BITS4 :
>>> 3*__BITS4); \
>>> + } \
>>> + else { \
>>> + for (__a = W_TYPE_SIZE - 8; __a > 0; __a -= 8) \
>>> + if (((__xr >> __a) & 0xff) != 0) \
>>> + break; \
>>> + } \
>>> + \
>>> + (count) = W_TYPE_SIZE - (__clz_tab[__xr >> __a] + __a); \
>>> +} while (0)
>>> + /* This version gives a well-defined value for zero. */
>>> +#define COUNT_LEADING_ZEROS_0 W_TYPE_SIZE
>>
>> lib/mpi/longlong.h:1483:1: warning: "COUNT_LEADING_ZEROS_0" redefined
>> lib/mpi/longlong.h:610:1: warning: this is the location of the previous
>> definition
>>
>> on m68k/allmodconfig.
>>
>> I'm also wondering why this warning is not seen on other arches, e.g. PPC
>> #defines COUNT_LEADING_ZEROS_0 to 32, just like m68k.
>>
>>> +#endif
>>
>> I suppose the plan is to clean up this header file, as lots of its
>> functionality is already present in the kernel sources in some other way
>> (e.g. arch/m68k/lib/muldi3.c)?
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Hello,
There are things to cleanup...
It takes a bit of time.
- 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 08/21] KEYS: Add signature verification facility [ver #3]
On Wed, Jan 18, 2012 at 5:13 PM, David Howells wrote: > Kasatkin, Dmitry wrote: > >> Yes. it is clear... >> Would it be possible to have pass data (uncompleted) hash? > > Yes, provided it's not finalised. Also, with the current code it would have > to be a shash, but I think I should be able to support the passing in of an > async hash by exporting the state from that and importing the state into a > shash using the crypto layer export and import functions. > I thought about export/import. But I think export/Import is hash driver implementation specific... Cannot use ahash state for shash... As you said in repose to later patch, you could provide some function to build a final metadata buffer out of signature to finalize the hash... - Dmitry > David -- 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 16/21] KEYS: PGP-based public key signature verification [ver #3]
On Wed, Jan 18, 2012 at 2:49 PM, David Howells wrote: > Kasatkin, Dmitry wrote: > >> Synchronous hash SHASH is used only for software hash implementation... >> HW acceleration is not supported by this hash. >> It is good for short data. >> But when calculating a hash over long data as files can be, >> async hash AHASH is a preferred choice as enables HW acceleration. > > Indeed. The asynchronous hash is a pain to use in the kernel, though, for a > couple of reasons: kernel addresses don't necessarily correspond to addresses > the h/w accel will see and you have to handle the h/w not signalling > completion. Herbert created shash to make it easier, and for module signing, > they're perfectly sufficient. > Well, from client side, API is not that more complicate. It is just about scatterlist. Rest is handled by particular driver/HW. I agree, modules are not that big and SHASH is perfect choice for that... >> As in my response to [PATCH 08/21] KEYS: Add signature verification facility >> [ver #3] It would be nice to have API to pass pre-computed hash, then client >> might tackle async peculiarities by itself... > > True. If you can give me the completed hash data, then I don't need to care > how you managed it. If you give me an uncompleted hash, I then have to deal > with the async hash in the kernel. > > It might make sense for me to provide an API call to give you the postamble > you > need to add to the hash to complete it. That call could also indicate which > hash you require and could also be combined with the call to find the > appropriate key. > Indeed, some blob with metadata to update before closing the hash would work well. PS.. As I understand, it is PGP spec which requires such processing. Otherwise, plain data hash could be used to produce another hash for signing, similar to what has been done in digsig project I have used the same approach for IMA. Thanks! > David -- 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 08/21] KEYS: Add signature verification facility [ver #3]
On Wed, Jan 18, 2012 at 2:26 PM, David Howells wrote: > Kasatkin, Dmitry wrote: > >> It would also nice to have an API to supply pre-computed data hash. For >> example IMA uses the same functionality to compute the hash of the file >> content, and then, based on security.ima type decided either verify it using >> just hash, or use digital signature. We could pass a hash as data. But may >> be we do not want to have extra operation and compute hash over hash. > > If I understand you correctly, you'd like to have the option to do the hashing > externally to this API? Would you supply the completed hash or just a hash > with the data in it, and require this API to complete it (ie. chuck metadata > into it)? > I meant just a hash of data.. Right, I remember, PGP finalizes hash with some additional metadata pgp_pkey_digest_signature() seems does it... > I don't think it should be hard. I could add an alternative to > verify_sig_add_data() perhaps. Either that or one function that does the lot > and takes the precomputed hash as input. There would be no need for the split > into four functions (begin, add_data, end, cancel) in such a case. The reason > for the split is so that the caller can invoke add_data several times with > non-contiguous bits of data. > Yes. it is clear... Would it be possible to have pass data (uncompleted) hash? > It might even make sense to expose the crypto hash object for direct access > rather than use add_data - but that then makes it hard to use crypto hardware > where you would just shovel the raw data into it and it does all the hashing > and cryptography in a black box. > > David > -- > 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 -- 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 16/21] KEYS: PGP-based public key signature verification [ver #3]
On Fri, Dec 2, 2011 at 8:45 PM, David Howells wrote:
> Provide handlers for PGP-based public-key algorithm signature verification.
> This does most of the work involved in signature verification as most of it is
> public-key algorithm agnostic. The public-key verification algorithm itself
> is just the last little bit and is supplied the complete hash data to process.
>
> This requires glue logic putting on top to make use of it - something the next
> patch provides.
>
> Signed-off-by: David Howells
> ---
>
> security/keys/Makefile | 3
> security/keys/pgp_parser.h | 6 +
> security/keys/pgp_pubkey_sig.c | 323
>
> 3 files changed, 331 insertions(+), 1 deletions(-)
> create mode 100644 security/keys/pgp_pubkey_sig.c
>
>
> diff --git a/security/keys/Makefile b/security/keys/Makefile
> index 242a087..fc1968e 100644
> --- a/security/keys/Makefile
> +++ b/security/keys/Makefile
> @@ -34,4 +34,5 @@ obj-$(CONFIG_CRYPTO_KEY_PGP_PARSER) += pgp_parser.o
> crypto_keys-y := crypto_type.o crypto_verify.o
>
> pgp_parser-y := \
> - pgp_key_parser.o
> + pgp_key_parser.o \
> + pgp_pubkey_sig.o
> diff --git a/security/keys/pgp_parser.h b/security/keys/pgp_parser.h
> index 1cda231..a6192ce 100644
> --- a/security/keys/pgp_parser.h
> +++ b/security/keys/pgp_parser.h
> @@ -21,3 +21,9 @@
> */
> extern const
> struct public_key_algorithm *pgp_public_key_algorithms[PGP_PUBKEY__LAST];
> +
> +/*
> + * pgp_pubkey_sig.c
> + */
> +extern struct crypto_key_verify_context *pgp_pkey_verify_sig_begin(
> + struct key *crypto_key, const u8 *sigdata, size_t siglen);
> diff --git a/security/keys/pgp_pubkey_sig.c b/security/keys/pgp_pubkey_sig.c
> new file mode 100644
> index 000..b4b7cb0
> --- /dev/null
> +++ b/security/keys/pgp_pubkey_sig.c
> @@ -0,0 +1,323 @@
> +/* Handling for PGP public key signature data [RFC 4880]
> + *
> + * Copyright (C) 2011 Red Hat, Inc. All Rights Reserved.
> + * Written by David Howells (dhowe...@redhat.com)
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public Licence
> + * as published by the Free Software Foundation; either version
> + * 2 of the Licence, or (at your option) any later version.
> + */
> +
> +#define pr_fmt(fmt) "PGPSIG: "fmt
> +#include
> +#include
> +#include
> +#include
> +#include "public_key.h"
> +#include "pgp_parser.h"
> +
> +const struct {
> + enum pkey_hash_algo algo : 8;
> +} pgp_pubkey_hash[PGP_HASH__LAST] = {
> + [PGP_HASH_MD5].algo = PKEY_HASH_MD5,
> + [PGP_HASH_SHA1].algo = PKEY_HASH_SHA1,
> + [PGP_HASH_RIPE_MD_160].algo = PKEY_HASH_RIPE_MD_160,
> + [PGP_HASH_SHA256].algo = PKEY_HASH_SHA256,
> + [PGP_HASH_SHA384].algo = PKEY_HASH_SHA384,
> + [PGP_HASH_SHA512].algo = PKEY_HASH_SHA512,
> + [PGP_HASH_SHA224].algo = PKEY_HASH_SHA224,
> +};
> +
> +static int pgp_pkey_verify_sig_add_data(struct crypto_key_verify_context
> *ctx,
> + const void *data, size_t datalen);
> +static int pgp_pkey_verify_sig_end(struct crypto_key_verify_context *ctx,
> + const u8 *sig, size_t siglen);
> +static void pgp_pkey_verify_sig_cancel(struct crypto_key_verify_context
> *ctx);
> +
> +struct pgp_pkey_sig_parse_context {
> + struct pgp_parse_context pgp;
> + struct pgp_sig_parameters params;
> +};
> +
> +static int pgp_pkey_parse_signature(struct pgp_parse_context *context,
> + enum pgp_packet_tag type,
> + u8 headerlen,
> + const u8 *data,
> + size_t datalen)
> +{
> + struct pgp_pkey_sig_parse_context *ctx =
> + container_of(context, struct pgp_pkey_sig_parse_context, pgp);
> +
> + return pgp_parse_sig_params(&data, &datalen, &ctx->params);
> +}
> +
> +/*
> + * Begin the process of verifying a DSA signature.
> + *
> + * This involves allocating the hash into which first the data and then the
> + * metadata will be put, and parsing the signature to check that it matches
> the
> + * key.
> + */
> +struct crypto_key_verify_context *pgp_pkey_verify_sig_begin(
> + struct key *crypto_key, const u8 *sigdata, size_t siglen)
> +{
> + struct pgp_pkey_sig_parse_context p;
> + struct public_key_signature *sig;
> + struct crypto_shash *tfm;
> + const struct public_key *key = crypto_key->payload.data;
> + size_t digest_size, desc_size;
> + int ret;
> +
> + kenter("{%d},,%zu", key_serial(crypto_key), siglen);
> +
> + if (!key) {
> + kleave(" = -ENOKEY [no public key]");
> + return ERR_PTR(-ENOKEY);
> + }
> +
> + p.pgp.types_of_interest = (1 << PGP_PKT_SIGNATURE);
> + p.pgp.process_packet = pgp_
Re: [PATCH 08/21] KEYS: Add signature verification facility [ver #3]
On Fri, Dec 2, 2011 at 8:44 PM, David Howells wrote: > Add a facility whereby a key subtype may be asked to verify a signature > against > the data it is purported to have signed. > > This adds four routines: > > (1) struct crypto_key_verify_context * > verify_sig_begin(struct key *keyring, const void *sig, size_t siglen); > > This sets up a verification context for the given signature using > information in that signature to select a key from the specified keyring > and to request a hash algorithm from the crypto layer. > > (2) int verify_sig_add_data(struct crypto_key_verify_context *ctx, > const void *data, size_t datalen); > > Incrementally supply data to be signed. May be called multiple times. > Hello, It would also nice to have an API to supply pre-computed data hash. For example IMA uses the same functionality to compute the hash of the file content, and then, based on security.ima type decided either verify it using just hash, or use digital signature. We could pass a hash as data. But may be we do not want to have extra operation and compute hash over hash. - Dmitry > (3) int verify_sig_end(struct crypto_key_verify_context *ctx, > const void *sig, size_t siglen); > > Complete the verification process and return the result. -EKEYREJECTED > will indicate that the verification failed and 0 will indicate success. > Other errors are also possible. > > (4) void verify_sig_cancel(struct crypto_key_verify_context *ctx); > > Cancel the verification process. > > Signed-off-by: David Howells > --- > > Documentation/security/keys-crypto.txt | 101 + > include/keys/crypto-subtype.h | 21 ++ > include/keys/crypto-type.h | 9 +++ > security/keys/Makefile | 2 - > security/keys/crypto_verify.c | 111 > > 5 files changed, 243 insertions(+), 1 deletions(-) > create mode 100644 security/keys/crypto_verify.c > > > diff --git a/Documentation/security/keys-crypto.txt > b/Documentation/security/keys-crypto.txt > index 97dee80..a964717 100644 > --- a/Documentation/security/keys-crypto.txt > +++ b/Documentation/security/keys-crypto.txt > @@ -7,6 +7,7 @@ Contents: > - Overview. > - Key identification. > - Accessing crypto keys. > + - Signature verification. > - Implementing crypto parsers. > - Implementing crypto subtypes. > > @@ -89,6 +90,65 @@ This gives access to the key type: > struct key_type key_type_crypto; > > > +SIGNATURE VERIFICATION > +-- > + > +The four operations that can perform cryptographic signature verification, > +using one of a set of keys to provide the public key: > + > + (1) Begin verification procedure. > + > + struct crypto_key_verify_context * > + verify_sig_begin(struct key *keyring, const void *sig, size_t siglen); > + > + This function sets up a verification context from the information in the > + signature and looks for a suitable key in the keyring. The signature > blob > + must be presented again at the end of the procedure. The keys will be > + checked against parameters in the signature, and if the matching one is > + not found then -ENOKEY will be returned. > + > + The hashing algorithm, if such a thing applies, will be determined from > + information in the signature and the appropriate crypto module will be > + used. -ENOPKG will be returned if the hash algorithm is unavailable. > + > + The return value is an opaque pointer to be passed to the other > functions, > + or a negative error code. > + > + (2) Indicate data to be verified. > + > + int verify_sig_add_data(struct crypto_key_verify_context *ctx, > + const void *data, size_t datalen); > + > + This function is used to shovel data to the verification procedure so > that > + it can load it into the hash, pass it to hardware or whatever is > + appropriate for the algorithm being employed. > + > + The data is not canonicalised for the document type specified in the > + signature. The caller must do that. > + > + It will return 0 if successful and a negative error code if not. > + > + (3) Complete the verification process. > + > + int verify_sig_end(struct crypto_key_verify_context *ctx, > + const void *sig, size_t siglen); > + > + This function performs the actual signature verification step and cleans > + up the resources allocated at the beginning. The signature must be > + presented again as some of the data therein may need to be added to the > + internal hash. > + > + It will return -EKEYREJECTED if the signature didn't match, 0 if > + successful and may return other errors as appropriate. > + > + (4) Cancel the verification process. > + > + void verify_sig_cancel(struct crypto_key_verify_cont
Re: [PATCH 07/21] KEYS: Create a key type that can be used for general cryptographic operations [ver #3]
On Tue, Jan 17, 2012 at 5:32 PM, David Howells wrote: > Mimi Zohar wrote: > >> Nice! Basically the 'crypto' key type ties crypto/ with security/keys. >> Other than the posted pgp key parser used for verifying kernel module >> signatures, I assume another use case could be to expose kernel >> cryptography to userspace. As there was a submission >> https://lkml.org/lkml/2010/8/20/103 to do just this, there must be >> userspace apps that would benefit. This architecture would address a >> number of concerns raised with the prior submission. (Refer to >> http://lwn.net/Articles/401548/.) > > :-) > >> You'd probably want to move the 'crypto' key type to its own directory. > > Yeah. > > I'd also like to see if Dmitry's work can be absorbes into this > infrastructure. > Hi David, Crypto keys is very nice idea. We thought some time ago about having dedicated key type for handling public key cryptography operations, but did not go that far. Also I did not want to mess-up with GnuPG formats and just made straight-forward RSA implementation, which can be handled by any crypto library, such as openssl. We can easily take GPG signing scheme into use for IMA/EVM when it gets to upstream. - Dmitry > David -- 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: crypto_ahash_setkey
On Wed, Nov 23, 2011 at 12:07 PM, Herbert Xu wrote: > On Wed, Nov 23, 2011 at 11:08:29AM +0200, Kasatkin, Dmitry wrote: >> >> Yes. I know that >> Work queue also uses WQ_NON_REENTRANT, so it should not be any races, >> and it should be possible to call crypto_ahash_setkey() without any problems. >> Ok... I found it out.. There is no magic here. For some reason work_task is called on different CPUs simultaneously. What is the purpose of WQ_NON_REENTRANT flag then? - Dmitry >> This problem happens on 64 bit kernel. >> It does not happen on my QEMU 32 bit kernel, >> >> I will do some more tests... > > Which particular hmac(sha1) implementation are you using? > > Cheers, > -- > Email: Herbert Xu > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt > -- 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: crypto_ahash_setkey
On Wed, Nov 23, 2011 at 8:08 AM, Steffen Klassert
wrote:
> Hi.
>
> On Wed, Nov 23, 2011 at 12:00:29AM +0200, Kasatkin, Dmitry wrote:
>> Hi,
>>
>> I have noticed very odd behavior with hmac calculation on my dual
>> core, 4 HTs PC.
>> I am using async hash API to to calculate hmac over the page.
>> I am using "hmac(sha1)" and the same key to calculate different pages.
>>
>> I have a work queue, which calculates the hmac like...
>>
>> int()
>> {
>> tfm = crypto_alloc_ahash(...);
>> }
>>
>> work_task()
>> {
>> crypto_ahash_setkey(tfm, key, keylen);
>> crypto_ahash_digest(req);
>> }
>>
>> HMAC result "sometimes" is incorrect.
>
> Looks like a race. HMAC precalculates the hash of the ipaded/opaded key
> and saves this hash on the transform. So the setkey method should be used
> just once in the initialization path.
>
>>
>> But when I move crypto_ahash_setkey() do the initialization code then
>> HMAC result is always correct...
>> (key is the same, so I can initialize it only once)
>>
>> int()
>> {
>> tfm = crypto_alloc_ahash(...);
>> crypto_ahash_setkey(tfm, key, keylen);
>> }
>
> That's how it should be. And in this case it works, as you
> already noticed :)
>
>
Thanks...
See my another reply...
--
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: crypto_ahash_setkey
Hi,
On Wed, Nov 23, 2011 at 9:44 AM, Herbert Xu wrote:
> Kasatkin, Dmitry wrote:
>> Hi,
>>
>> I have noticed very odd behavior with hmac calculation on my dual
>> core, 4 HTs PC.
>> I am using async hash API to to calculate hmac over the page.
>> I am using "hmac(sha1)" and the same key to calculate different pages.
>>
>> I have a work queue, which calculates the hmac like...
>>
>> int()
>> {
>> tfm = crypto_alloc_ahash(...);
>> }
>>
>> work_task()
>> {
>> crypto_ahash_setkey(tfm, key, keylen);
>> crypto_ahash_digest(req);
>> }
>>
>> HMAC result "sometimes" is incorrect.
>
> Is your tfm shared by multiple instances of work_task? The key
> is a property of the tfm, so you cannot have multiple users of a
> tfm all changing keys at the same time.
Yes. I know that
Work queue also uses WQ_NON_REENTRANT, so it should not be any races,
and it should be possible to call crypto_ahash_setkey() without any problems.
This problem happens on 64 bit kernel.
It does not happen on my QEMU 32 bit kernel,
I will do some more tests...
>
> The correct usage model allowing parallel use is to dedicate a
> tfm to each key.
>
Sure.
Thanks...
> Cheers,
> --
> Email: Herbert Xu
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
>
--
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
crypto_ahash_setkey
Hi,
I have noticed very odd behavior with hmac calculation on my dual
core, 4 HTs PC.
I am using async hash API to to calculate hmac over the page.
I am using "hmac(sha1)" and the same key to calculate different pages.
I have a work queue, which calculates the hmac like...
int()
{
tfm = crypto_alloc_ahash(...);
}
work_task()
{
crypto_ahash_setkey(tfm, key, keylen);
crypto_ahash_digest(req);
}
HMAC result "sometimes" is incorrect.
But when I move crypto_ahash_setkey() do the initialization code then
HMAC result is always correct...
(key is the same, so I can initialize it only once)
int()
{
tfm = crypto_alloc_ahash(...);
crypto_ahash_setkey(tfm, key, keylen);
}
work_task()
{
crypto_ahash_digest(req);
}
It seems that crypto_ahash_setkey() somehow sometimes does wrong things...
I hope my explanation is clear.
Any ideas why it might happen?
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 v2.2 1/7] crypto: GnuPG based MPI lib - source files (part 1)
On Mon, Nov 21, 2011 at 1:27 PM, James Morris wrote: > On Mon, 21 Nov 2011, Kasatkin, Dmitry wrote: > >> It can be easily split into 2 commits and one of them would not comply >> with mailing list limits. >> >> James, should I do anything about it? > > No, it's in my public tree now. > Ok. In fact it does not break bisect, because compilation is enabled in the 3rd patch. BR, Dmitry > > - James > -- > James Morris > > -- 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 -next] digsig: fix build errors
On Mon, Nov 21, 2011 at 8:12 AM, Randy Dunlap wrote: > From: Randy Dunlap > > Fix build errors by adding kconfig dependency on KEYS: > > lib/digsig.c:106:16: error: dereferencing pointer to incomplete type > lib/digsig.c:107:11: error: dereferencing pointer to incomplete type > lib/digsig.c:184:14: error: dereferencing pointer to incomplete type > lib/digsig.c:223:3: error: 'key_ref_t' undeclared (first use in this function) > lib/digsig.c:223:13: error: expected ';' before 'kref' > lib/digsig.c:224:3: error: 'kref' undeclared (first use in this function) > lib/digsig.c:224:3: error: implicit declaration of function 'keyring_search' > lib/digsig.c:231:3: error: implicit declaration of function 'request_key' > > and after changing lib/Kconfig: > warning: (INTEGRITY_DIGSIG) selects DIGSIG which has unmet direct > dependencies (CRYPTO && KEYS) > > Signed-off-by: Randy Dunlap > Cc: Dmitry Kasatkin > --- > lib/Kconfig | 4 ++-- > security/integrity/Kconfig | 2 +- > 2 files changed, 3 insertions(+), 3 deletions(-) > > --- next-2011-1121.orig/lib/Kconfig > +++ next-2011-1121/lib/Kconfig > @@ -294,10 +294,10 @@ config MPILIB_EXTRA > > config DIGSIG > tristate "In-kernel signature checker" > - depends on CRYPTO > + depends on CRYPTO && KEYS this patch was in /crypto dir before, now it is in /lib... I think CRYPTO is not needed at all at the moment.. > select MPILIB > help > Digital signature verification. Currently only RSA is supported. > - Implementation is done using GnuPG MPI library > + Implementation is done using GnuPG MPI library. > > endmenu > --- next-2011-1121.orig/security/integrity/Kconfig > +++ next-2011-1121/security/integrity/Kconfig > @@ -5,7 +5,7 @@ config INTEGRITY > > config INTEGRITY_DIGSIG > boolean "Digital signature verification using multiple keyrings" > - depends on INTEGRITY > + depends on INTEGRITY && CRYPTO && KEYS Is it really needed, because 2 lines bellow is "select DIGSIG", which will depend on KEYS?? > default n > select DIGSIG > help > Thanks! -- 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 v2.2 1/7] crypto: GnuPG based MPI lib - source files (part 1)
On Sat, Nov 19, 2011 at 5:33 AM, Stephen Rothwell wrote: > Hi all, > > On Wed, 19 Oct 2011 14:51:30 +0300 Dmitry Kasatkin > wrote: >> >> Adds the multi-precision-integer maths library which was originally taken >> from GnuPG and ported to the kernel by (among others) David Howells. >> This version is taken from Fedora kernel 2.6.32-71.14.1.el6. >> The difference is that checkpatch reported errors and warnings have been >> fixed. >> >> This library is used to implemenet RSA digital signature verification >> used in IMA/EVM integrity protection subsystem. >> >> Due to patch size limitation, the patch is divided into 4 parts. > > I just noticed that this has been added to the "next" branch of the > security tree (and thus into the next release of linux-next). I think > that these patches should be rearranged as in their current form, they > break bisection (since the files in this patch reference include files in > a latter patch). We generally prefer large patches to be broken up into > logical sub patches rather than just along file boundaries. > > In this case, even though it was broken up for review, it could have been > committed as one large commit (assuming that there is no sensible way to > break it up). Hi, It can be easily split into 2 commits and one of them would not comply with mailing list limits. James, should I do anything about it? Thanks, - Dmitry > -- > Cheers, > Stephen Rothwell s...@canb.auug.org.au > http://www.canb.auug.org.au/~sfr/ > -- 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 v2.1 1/7] crypto: GnuPG based MPI lib - source files (part 1)
On Mon, Oct 17, 2011 at 12:11 PM, Kasatkin, Dmitry
wrote:
> From Kernel Docbook
>
> Similar to EXPORT_SYMBOL() except that the
> symbols exported by EXPORT_SYMBOL_GPL() can
> only be seen by modules with a
> MODULE_LICENSE() that specifies a GPL
> compatible license. It implies that the function is considered
> an internal implementation issue, and not really an interface.
>
> "not really an interface"
>
> Should it really be EXPORT_SYMBOL_GPL?
>
> - Dmitry
>
> On Sat, Oct 15, 2011 at 3:28 AM, James Morris wrote:
>> On Fri, 14 Oct 2011, Dmitry Kasatkin wrote:
>>
>>> +MPI mpi_alloc(unsigned nlimbs)
>>> +{
>>> + MPI a;
>>> +
>>> + a = (MPI) kmalloc(sizeof *a, GFP_KERNEL);
>>
>> Generally, typedef structs are frowned upon in the kernel. I'd prefer to
>> see this (and any others) changed to a normal type.
>>
>> Also, kmalloc return values do not need to be cast, they're void *.
>>
>>> +EXPORT_SYMBOL(mpi_alloc);
>>
>> New interfaces should be EXPORT_SYMBOL_GPL.
>>
>>
>> --
>> James Morris
>>
>>
>
Hello James,
Also please let me know about other things so that I could fix them as well...
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 v2.1 1/7] crypto: GnuPG based MPI lib - source files (part 1)
>From Kernel Docbook
Similar to EXPORT_SYMBOL() except that the
symbols exported by EXPORT_SYMBOL_GPL() can
only be seen by modules with a
MODULE_LICENSE() that specifies a GPL
compatible license. It implies that the function is considered
an internal implementation issue, and not really an interface.
"not really an interface"
Should it really be EXPORT_SYMBOL_GPL?
- Dmitry
On Sat, Oct 15, 2011 at 3:28 AM, James Morris wrote:
> On Fri, 14 Oct 2011, Dmitry Kasatkin wrote:
>
>> +MPI mpi_alloc(unsigned nlimbs)
>> +{
>> + MPI a;
>> +
>> + a = (MPI) kmalloc(sizeof *a, GFP_KERNEL);
>
> Generally, typedef structs are frowned upon in the kernel. I'd prefer to
> see this (and any others) changed to a normal type.
>
> Also, kmalloc return values do not need to be cast, they're void *.
>
>> +EXPORT_SYMBOL(mpi_alloc);
>
> New interfaces should be EXPORT_SYMBOL_GPL.
>
>
> --
> James Morris
>
>
--
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 v2.1 4/7] crypto: GnuPG based MPI lib - additional sources (part 4)
On Sat, Oct 15, 2011 at 3:34 AM, James Morris wrote: > On Fri, 14 Oct 2011, Dmitry Kasatkin wrote: > >> +#if 0 /* not yet ported to MPI */ >> + >> +mpi_limb_t >> +mpihelp_udiv_w_sdiv(mpi_limp_t *rp, >> + mpi_limp_t *a1, mpi_limp_t *a0, mpi_limp_t *d) > > Drop this if it's not working. > > > -- > James Morris > > -- > To unsubscribe from this list: send the line "unsubscribe > linux-security-module" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > It is there for completeness and it will not be even compiled at all without CONFIG_MPILIB_EXTRA Still remove? - 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: [RFC v2.1 0/6] evm: digital signature verification extension
On Thu, Sep 29, 2011 at 3:42 AM, James Morris wrote: > On Thu, 29 Sep 2011, Herbert Xu wrote: > >> Well if James is OK with adding the user for this then I'm fine >> with adding the necessary infrastructure. > > Are you happy with the API? > > > -- > James Morris > > Hello, One comment earlier (some years ago) was to put MPI lib to the /lib folder. Indeed it is a math "library"... ksign.c can be also there.. Does /lib sounds better? It does not break anything. It is just enabling technology for IMA/EVM. And of course it will evolve further... - 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: [RFC v2.1 0/6] evm: digital signature verification extension
On Tue, Sep 27, 2011 at 2:15 AM, James Morris wrote: > On Mon, 26 Sep 2011, Kasatkin, Dmitry wrote: > >> It seems nobody wants to share their thoughts about it? >> Does this silence mean acceptance? >> Should I prepare final patches for merge? > > Not yet. > > I'd like to hear what the crypto folk think about the crypto. > > -- > James Morris > > Herbert, Can you say what you think? Thank you, 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: [RFC v2.1 0/6] evm: digital signature verification extension
On Tue, Sep 20, 2011 at 4:24 PM, Mimi Zohar wrote: > On Tue, 2011-09-13 at 17:20 +0300, Dmitry Kasatkin wrote: >> Hello, >> >> Changes to version 2.0: >> - MPI patch has been split to smaller in order to go to mailing lists. >> First 2 patches include only source and header files which are needed >> to build ksign verification. Headers and sources are split just to >> meet 100k kernel.org limit. >> Last patch adds all rest soures from original ported MPI library. >> >> Changes to version 1.1: >> - GnuPG MPI library has been refactored with lindent and checkpatch errors >> and warnings has been fixed. >> - creation of evm keyring has been remove. It is done now in user space. >> - related ksign and evm patches has been squashed. >> - patch descriptions has been updated. >> >> As EVM patches were recently merged to security-testing-2.6#next, >> it is a good time to resend evm signature verification patches for active >> discussion. Last time I forgot --cc linux-crypto. Here it is. >> >> This patchset introduces digital signature extensions for the IMA/EVM kernel >> integrity subsystem and is applied on the top of the EVM patches posted to >> LSM mailing list earlier. > > Hi Herbert > > Back in March 2011, in preparation for EVM, Dmitry posted the GnuPG MPI > library patch here on linux-crypto. The reason given for not upstreaming > the MPI library, at the time, was for lack of an in kernel user > (http://www.mail-archive.com/linux-crypto@vger.kernel.org/msg05613.html). > With the recent merging of the EVM patches in linux-next, via > security-testing-2.6/#next, that is changing. Any chance of re-opening > the discussion? > > thanks, > > Mimi > > -- > To unsubscribe from this list: send the line "unsubscribe > linux-security-module" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Hi, It seems nobody wants to share their thoughts about it? Does this silence mean acceptance? Should I prepare final patches for merge? BR, 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: [RFC v2.0 3/3] evm: digital signature support
Please ignore this patch. It was sent by mistake...
Check:
evm: digital signature verification support
- Dmitry
On Tue, Sep 6, 2011 at 4:11 PM, Dmitry Kasatkin
wrote:
> When building an image, which has to be flashed to different devices,
> an HMAC cannot be used to sign file metadata, as the HMAC key is different
> on every device. File metadata can be protected using digital signature.
> This patch enables RSA signature based integrity verification.
>
> Signed-off-by: Dmitry Kasatkin
> Acked-by: Mimi Zohar
> ---
> security/integrity/evm/Kconfig | 14
> security/integrity/evm/evm.h | 12
> security/integrity/evm/evm_crypto.c | 66 ++-
> security/integrity/evm/evm_main.c | 125
> +++
> 4 files changed, 187 insertions(+), 30 deletions(-)
>
> diff --git a/security/integrity/evm/Kconfig b/security/integrity/evm/Kconfig
> index 884617d..84eea75 100644
> --- a/security/integrity/evm/Kconfig
> +++ b/security/integrity/evm/Kconfig
> @@ -12,3 +12,17 @@ config EVM
> integrity attacks.
>
> If you are unsure how to answer this question, answer N.
> +
> +config EVM_DIGSIG
> + boolean "EVM Digital Signature support"
> + depends on EVM
> + default n
> + select CRYPTO_KSIGN_RSA
> + help
> + When building an image, which has to be flashed to different
> + devices, an HMAC cannot be used to sign file metadata, as
> + the HMAC key is different on every device.
> + File metadata can be protected using digital signature.
> + This option enables RSA signature based integrity verification.
> +
> + If unsure, say N.
> diff --git a/security/integrity/evm/evm.h b/security/integrity/evm/evm.h
> index d320f51..c885247 100644
> --- a/security/integrity/evm/evm.h
> +++ b/security/integrity/evm/evm.h
> @@ -12,14 +12,21 @@
> * File: evm.h
> *
> */
> +
> +#ifndef __INTEGRITY_EVM_H
> +#define __INTEGRITY_EVM_H
> +
> #include
> #include
> +
> #include "../integrity.h"
>
> extern int evm_initialized;
> extern char *evm_hmac;
> +extern char *evm_hash;
>
> extern struct crypto_shash *hmac_tfm;
> +extern struct crypto_shash *hash_tfm;
>
> /* List of EVM protected security xattrs */
> extern char *evm_config_xattrnames[];
> @@ -32,7 +39,12 @@ extern int evm_update_evmxattr(struct dentry *dentry,
> extern int evm_calc_hmac(struct dentry *dentry, const char *req_xattr_name,
> const char *req_xattr_value,
> size_t req_xattr_value_len, char *digest);
> +extern int evm_calc_hash(struct dentry *dentry, const char *req_xattr_name,
> + const char *req_xattr_value,
> + size_t req_xattr_value_len, char *digest);
> extern int evm_init_hmac(struct inode *inode, const struct xattr *xattr,
> char *hmac_val);
> extern int evm_init_secfs(void);
> extern void evm_cleanup_secfs(void);
> +
> +#endif
> diff --git a/security/integrity/evm/evm_crypto.c
> b/security/integrity/evm/evm_crypto.c
> index 5dd5b140..847a2d7 100644
> --- a/security/integrity/evm/evm_crypto.c
> +++ b/security/integrity/evm/evm_crypto.c
> @@ -26,34 +26,48 @@ static unsigned char evmkey[MAX_KEY_SIZE];
> static int evmkey_len = MAX_KEY_SIZE;
>
> struct crypto_shash *hmac_tfm;
> +struct crypto_shash *hash_tfm;
>
> -static struct shash_desc *init_desc(void)
> +static struct shash_desc *init_desc(const char type)
> {
> int rc;
> + char *algo;
> + struct crypto_shash **tfm;
> struct shash_desc *desc;
>
> - if (hmac_tfm == NULL) {
> - hmac_tfm = crypto_alloc_shash(evm_hmac, 0, CRYPTO_ALG_ASYNC);
> - if (IS_ERR(hmac_tfm)) {
> + if (type == EVM_XATTR_HMAC) {
> + tfm = &hmac_tfm;
> + algo = evm_hmac;
> + } else {
> + tfm = &hash_tfm;
> + algo = evm_hash;
> + }
> +
> + if (*tfm == NULL) {
> + *tfm = crypto_alloc_shash(algo, 0, CRYPTO_ALG_ASYNC);
> + if (IS_ERR(*tfm)) {
> pr_err("Can not allocate %s (reason: %ld)\n",
> - evm_hmac, PTR_ERR(hmac_tfm));
> - rc = PTR_ERR(hmac_tfm);
> - hmac_tfm = NULL;
> + algo, PTR_ERR(*tfm));
> + rc = PTR_ERR(*tfm);
> + *tfm = NULL;
> return ERR_PTR(rc);
> }
> }
>
> - desc = kmalloc(sizeof(*desc) + crypto_shash_descsize(hmac_tfm),
> + desc = kmalloc(sizeof(*desc) + crypto_shash_descsize(*tfm),
> GFP_KERNEL);
> if (!desc)
> return ERR_PTR(-ENOMEM);
>
> - desc->tfm = hmac_tfm;
> + desc->tfm = *tfm;
> desc->flags = CRYPTO_TFM_REQ_MAY_SLEEP;
>
> - rc = crypto_shash_setkey(hmac_tfm, evmkey, evmkey_len);
> -
