* Crypto Fixes for 4.7
From: Herbert Xu @ 2016-06-27 6:28 UTC (permalink / raw)
To: Linus Torvalds, David S. Miller, Linux Kernel Mailing List,
Linux Crypto Mailing List
In-Reply-To: <20160520084105.GA3959@gondor.apana.org.au>
Hi Linus:
This push fixes the following issue:
- Missing length check for user-space GETALG request.
- Bogus memmove length in ux500 driver.
- Incorrect priority setting for vmx driver.
- Incorrect ABI selection for vmx driver.
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus
Anton Blanchard (2):
crypto: vmx - Fix ABI detection
crypto: vmx - Increase priority of aes-cbc cipher
Linus Walleij (1):
crypto: ux500 - memmove the right size
Mathias Krause (1):
crypto: user - re-add size check for CRYPTO_MSG_GETALG
crypto/crypto_user.c | 1 +
drivers/crypto/ux500/hash/hash_core.c | 4 ++--
drivers/crypto/vmx/aes_cbc.c | 2 +-
drivers/crypto/vmx/aes_ctr.c | 2 +-
drivers/crypto/vmx/ppc-xlate.pl | 2 +-
5 files changed, 6 insertions(+), 5 deletions(-)
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCHv2 05/27] crypto: omap-sham: avoid executing tasklet where not needed
From: Tero Kristo @ 2016-06-27 5:04 UTC (permalink / raw)
To: Herbert Xu
Cc: linux-omap, linux-crypto, tony, davem, lokeshvutla,
linux-arm-kernel
In-Reply-To: <20160624103042.GA19571@gondor.apana.org.au>
On 24/06/16 13:30, Herbert Xu wrote:
> On Wed, Jun 22, 2016 at 04:23:38PM +0300, Tero Kristo wrote:
>> Some of the call paths of OMAP SHA driver can avoid executing the next
>> step of the crypto queue under tasklet; instead, execute the next step
>> directly via function call. This avoids a costly round-trip via the
>> scheduler giving a slight performance boost.
>>
>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>> ---
>> drivers/crypto/omap-sham.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
>> index 6247887..84a0027 100644
>> --- a/drivers/crypto/omap-sham.c
>> +++ b/drivers/crypto/omap-sham.c
>> @@ -242,6 +242,8 @@ static struct omap_sham_drv sham = {
>> .lock = __SPIN_LOCK_UNLOCKED(sham.lock),
>> };
>>
>> +static void omap_sham_done_task(unsigned long data);
>> +
>> static inline u32 omap_sham_read(struct omap_sham_dev *dd, u32 offset)
>> {
>> return __raw_readl(dd->io_base + offset);
>> @@ -1007,7 +1009,7 @@ static void omap_sham_finish_req(struct ahash_request *req, int err)
>> req->base.complete(&req->base, err);
>>
>> /* handle new request */
>> - tasklet_schedule(&dd->done_task);
>> + omap_sham_done_task((unsigned long)dd);
>> }
>
> Hmm, what guarnatees that you won't run out of stack doing this?
Good question, I had a deeper look at the driver and it seems you are
right... It may result in a recursion loop within the driver. I will dig
this further and break the recursion if it indeed can call itself
indefinitely.
My knowledge of the crypto stack (+ these drivers unfortunately) is
still pretty limited, I appreciate your reviews a lot.
-Tero
^ permalink raw reply
* Re: [PATCHv2 06/27] crypto: ahash: increase the maximum allowed statesize
From: Herbert Xu @ 2016-06-27 5:00 UTC (permalink / raw)
To: Tero Kristo
Cc: linux-omap, linux-crypto, tony, davem, lokeshvutla,
linux-arm-kernel
In-Reply-To: <5770B283.8000902@ti.com>
On Mon, Jun 27, 2016 at 07:58:43AM +0300, Tero Kristo wrote:
>
> Ok, I think I need to allocate the storage space locally then within
> the driver. Would it be ok to call kmalloc / free in the export /
> import implementation of the driver? The size of the unhashed buffer
> in omap-sham is unfortunately rather large.
The allocation should usually be done from the request_alloc
function, i.e., you set the reqsize and the user does the allocation
for you.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCHv2 06/27] crypto: ahash: increase the maximum allowed statesize
From: Tero Kristo @ 2016-06-27 4:58 UTC (permalink / raw)
To: Herbert Xu
Cc: linux-omap, linux-crypto, tony, davem, lokeshvutla,
linux-arm-kernel
In-Reply-To: <20160624103209.GA19607@gondor.apana.org.au>
On 24/06/16 13:32, Herbert Xu wrote:
> On Wed, Jun 22, 2016 at 04:23:39PM +0300, Tero Kristo wrote:
>> The statesize is used to determine the maximum size for saved ahash
>> context. In some cases, this can be much larger than what is currently
>> allocated for it, for example omap-sham driver uses a buffer size of
>> PAGE_SIZE. Increase the statesize to accommodate this.
>>
>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>
> Nack. The exported state is supposed to consist of the actual
> hash state, plus at most one block worth of unhashed data. It's
> limited so that we can store it on the stack.
>
> So no I'm not taking this patch.
>
Ok, I think I need to allocate the storage space locally then within the
driver. Would it be ok to call kmalloc / free in the export / import
implementation of the driver? The size of the unhashed buffer in
omap-sham is unfortunately rather large.
-Tero
^ permalink raw reply
* Re: [PATCH 7/7] random: add backtracking protection to the CRNG
From: Theodore Ts'o @ 2016-06-26 23:05 UTC (permalink / raw)
To: Pavel Machek
Cc: Linux Kernel Developers List, linux-crypto, smueller, herbert,
andi, sandyinchina, jsd, hpa
In-Reply-To: <20160626184753.GB11162@amd>
On Sun, Jun 26, 2016 at 08:47:53PM +0200, Pavel Machek wrote:
>
> You are basically trying to turn CRNG into one way hash function here,
> right? Do you have any explanation that it has the required
> properties?
Well, not really. A CRNG has the property that if you generate a
series of outputs: O_N-1, O_N, O_N+1, etc., knowledge of O_N does not
give you any special knowledge with respect to O_N+1 or O_N-1.
The anti-backtracking protection means that when we generate O_N, we
use O_N+1 to mutate the state used for the CRNG; specifically, we are
XOR'ing O_N+1 into the state. Now let's suppose that state gets
exposed. Even if you know O_N, that's not going to let you know
O_N+1, so knowledge of the exposed state post XOR with O_N+1 isn't
going to help you get back the original state.
More generally, if we assume ChaCha20 is secure, that means that you
can't derive the key even if you have known plaintext. The output of
the CRNG is basically the keystream --- what you have after you XOR
the ciphertext with the plaintext. If ChaCha20 is secure, knowledge
of large portions of the keystream should not help you determine the
key, which means is why knowledge of O_N-1, O_N, won't help you derive
either (a) the state of CRNG, aka the ChaCha20 key, or (b) O_N+1.
Cheers,
- Ted
^ permalink raw reply
* Re: [PATCH 5/7] random: replace non-blocking pool with a Chacha20-based CRNG
From: Theodore Ts'o @ 2016-06-26 22:51 UTC (permalink / raw)
To: Pavel Machek
Cc: Herbert Xu, Linux Kernel Developers List, linux-crypto, smueller,
andi, sandyinchina, jsd, hpa
In-Reply-To: <20160626184743.GA11162@amd>
On Sun, Jun 26, 2016 at 08:47:43PM +0200, Pavel Machek wrote:
> Ok, so lets say I'm writing some TLS server, and I know that traffic
> is currently heavy because it was heavy in last 5 minutes. Would it
> make sense for me to request 128M of randomness from /dev/urandom, and
> then use that internally, to avoid the syscall overhead?
Probably not. Keep in mind that even requesting a 256 bit key one at
a time, it's still only taking 1.7 microseconds. The time to do the
Diffie-Hellman will vary depending on whether you are doing DH in a
log field or a ECC field, but whether it's around 18-20ms or 3-4ms,
it's over *three* orders of magnitude more than the time it takes to
generate a random session key.
So trying to grab 1M of randomness and managing it in your TLS server
is almost certainly optimizing for The Wrong Thing. (Not to mention
the potential for disaster if that randomness gets stolen via some
kind of wild pointer bug, etc., etc.)
This is why I think it's a waste of time talknig about trying to use
AVX or SIMD optimized version of ChaCha20. Even if the cost to do the
XSAVE / XRESTORE doesn't crush the optimization of advantages of
ChaCha20, and if you ignore the costs of adding backtracking defenses,
etc., bloating the kernel by adding support for the crypto layer
doesn't make sense when using the generic ChaCha20 already gets you
down into the microsecond arena. You might be able to get the session
key generation down by another .3 or .4 microseconds, but even if you
cut it down by half to .9 microseconds, the public key operations and
the diffie-hellman operations are going to make such savings be almost
completely unnoticeable.
- Ted
^ permalink raw reply
* Re: [PATCH 5/7] random: replace non-blocking pool with a Chacha20-based CRNG
From: Stephan Mueller @ 2016-06-26 19:10 UTC (permalink / raw)
To: Pavel Machek
Cc: Theodore Ts'o, Herbert Xu, Linux Kernel Developers List,
linux-crypto, andi, sandyinchina, jsd, hpa
In-Reply-To: <20160626184743.GA11162@amd>
Am Sonntag, 26. Juni 2016, 20:47:43 schrieb Pavel Machek:
Hi Pavel,
> Hi!
>
> > Yes, I understand the argument that the networking stack is now
> > requiring the crypto layer --- but not all IOT devices may necessarily
> > require the IP stack (they might be using some alternate wireless
> > communications stack) and I'd much rather not make things worse.
> >
> >
> > The final thing is that it's not at all clear that the accelerated
> > implementation is all that important anyway. Consider the following
> > two results using the unaccelerated ChaCha20:
> >
> > % dd if=/dev/urandom bs=4M count=32 of=/dev/null
> > 32+0 records in
> > 32+0 records out
> > 134217728 bytes (134 MB, 128 MiB) copied, 1.18647 s, 113 MB/s
> >
> > % dd if=/dev/urandom bs=32 count=4194304 of=/dev/null
> > 4194304+0 records in
> > 4194304+0 records out
> > 134217728 bytes (134 MB, 128 MiB) copied, 7.08294 s, 18.9 MB/s
> >
> > So in both cases, we are reading 128M from the CRNG. In the first
> > case, we see the sort of speed we would get if we were using the CRNG
> > for some illegitimate, such as "dd if=/dev/urandom of=/dev/sdX bs=4M"
> > (because they were too lazy to type "apt-get install nwipe").
> >
> > In the second case, we see the use of /dev/urandom in a much more
> > reasonable, proper, real-world use case for /de/urandom, which is some
> > userspace process needing a 256 bit session key for a TLS connection,
> > or some such. In this case, we see that the other overheads of
> > providing the anti-backtracking protection, system call overhead,
> > etc., completely dominate the speed of the core crypto primitive.
> >
> > So even if the AVX optimized is 100% faster than the generic version,
> > it would change the time needed to create a 256 byte session key from
> > 1.68 microseconds to 1.55 microseconds. And this is ignoring the
>
> Ok, so lets say I'm writing some TLS server, and I know that traffic
> is currently heavy because it was heavy in last 5 minutes. Would it
> make sense for me to request 128M of randomness from /dev/urandom, and
> then use that internally, to avoid the syscall overhead?
>
> Ok, maybe 128M is a bit much because by requesting that much in single
> request i'd turn urandom into PRNG, but perhaps 1MB block makes sense?
I would definitely say that this is appropriate when you use the data stream
from urandom directly as keying material.
>
> And I guess even requesting 128M would make sense, as kernel can
> select best crypto implementation for CRNG, and I'd prefer to avoid
> that code in my application as it is hardware-specific...
The code in the server should only make sure it memset(0) any of the random
data immediately after use. This way even when the server dumps core, all you
see is *unused* random data which does not hurt.
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH 7/7] random: add backtracking protection to the CRNG
From: Pavel Machek @ 2016-06-26 18:47 UTC (permalink / raw)
To: Theodore Ts'o
Cc: Linux Kernel Developers List, linux-crypto, smueller, herbert,
andi, sandyinchina, jsd, hpa
In-Reply-To: <1465832919-11316-8-git-send-email-tytso@mit.edu>
On Mon 2016-06-13 11:48:39, Theodore Ts'o wrote:
> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
> ---
> drivers/char/random.c | 54 ++++++++++++++++++++++++++++++++++++++++++++++-----
> 1 file changed, 49 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/char/random.c b/drivers/char/random.c
> index d640865..963a6a9 100644
> --- a/drivers/char/random.c
> +++ b/drivers/char/random.c
> @@ -436,7 +436,8 @@ static int crng_init = 0;
> #define crng_ready() (likely(crng_init > 0))
> static void _extract_crng(struct crng_state *crng,
> __u8 out[CHACHA20_BLOCK_SIZE]);
> -static void extract_crng(__u8 out[CHACHA20_BLOCK_SIZE]);
> +static void _crng_backtrack_protect(struct crng_state *crng,
> + __u8 tmp[CHACHA20_BLOCK_SIZE], int used);
> static void process_random_ready_list(void);
You can do u8 and u32 in the code, we know we are in kernel.
> +/*
> + * Use the leftover bytes from the CRNG block output (if there is
> + * enough) to mutate the CRNG key to provide backtracking protection.
> + */
> +static void _crng_backtrack_protect(struct crng_state *crng,
> + __u8 tmp[CHACHA20_BLOCK_SIZE], int used)
> +{
> + unsigned long flags;
> + __u32 *s, *d;
> + int i;
> +
> + used = round_up(used, sizeof(__u32));
> + if (used + CHACHA20_KEY_SIZE > CHACHA20_BLOCK_SIZE) {
> + extract_crng(tmp);
> + used = 0;
> + }
> + spin_lock_irqsave(&crng->lock, flags);
> + s = (__u32 *) &tmp[used];
> + d = &crng->state[4];
> + for (i=0; i < 8; i++)
> + *d++ ^= *s++;
> + spin_unlock_irqrestore(&crng->lock, flags);
> +}
You are basically trying to turn CRNG into one way hash function here,
right? Do you have any explanation that it has the required
properties?
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [PATCH 5/7] random: replace non-blocking pool with a Chacha20-based CRNG
From: Pavel Machek @ 2016-06-26 18:47 UTC (permalink / raw)
To: Theodore Ts'o, Herbert Xu, Linux Kernel Developers List,
linux-crypto, smueller, andi, sandyinchina, jsd, hpa
In-Reply-To: <20160619231827.GB9848@thunk.org>
Hi!
> Yes, I understand the argument that the networking stack is now
> requiring the crypto layer --- but not all IOT devices may necessarily
> require the IP stack (they might be using some alternate wireless
> communications stack) and I'd much rather not make things worse.
>
>
> The final thing is that it's not at all clear that the accelerated
> implementation is all that important anyway. Consider the following
> two results using the unaccelerated ChaCha20:
>
> % dd if=/dev/urandom bs=4M count=32 of=/dev/null
> 32+0 records in
> 32+0 records out
> 134217728 bytes (134 MB, 128 MiB) copied, 1.18647 s, 113 MB/s
>
> % dd if=/dev/urandom bs=32 count=4194304 of=/dev/null
> 4194304+0 records in
> 4194304+0 records out
> 134217728 bytes (134 MB, 128 MiB) copied, 7.08294 s, 18.9 MB/s
>
> So in both cases, we are reading 128M from the CRNG. In the first
> case, we see the sort of speed we would get if we were using the CRNG
> for some illegitimate, such as "dd if=/dev/urandom of=/dev/sdX bs=4M"
> (because they were too lazy to type "apt-get install nwipe").
>
> In the second case, we see the use of /dev/urandom in a much more
> reasonable, proper, real-world use case for /de/urandom, which is some
> userspace process needing a 256 bit session key for a TLS connection,
> or some such. In this case, we see that the other overheads of
> providing the anti-backtracking protection, system call overhead,
> etc., completely dominate the speed of the core crypto primitive.
>
> So even if the AVX optimized is 100% faster than the generic version,
> it would change the time needed to create a 256 byte session key from
> 1.68 microseconds to 1.55 microseconds. And this is ignoring the
Ok, so lets say I'm writing some TLS server, and I know that traffic
is currently heavy because it was heavy in last 5 minutes. Would it
make sense for me to request 128M of randomness from /dev/urandom, and
then use that internally, to avoid the syscall overhead?
Ok, maybe 128M is a bit much because by requesting that much in single
request i'd turn urandom into PRNG, but perhaps 1MB block makes sense?
And I guess even requesting 128M would make sense, as kernel can
select best crypto implementation for CRNG, and I'd prefer to avoid
that code in my application as it is hardware-specific...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* [cryptodev:master 87/87] crypto/ecc.c:1018:1: warning: 'crypto_ecdh_shared_secret' uses dynamic stack allocation
From: kbuild test robot @ 2016-06-25 2:37 UTC (permalink / raw)
Cc: kbuild-all, linux-crypto, Herbert Xu
[-- Attachment #1: Type: text/plain, Size: 11591 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
head: 8f44df154de79a61b0e86734f51737b8cccf8dfe
commit: 8f44df154de79a61b0e86734f51737b8cccf8dfe [87/87] crypto: ecdh - make ecdh_shared_secret unique
config: s390-allyesconfig (attached as .config)
compiler: s390x-linux-gnu-gcc (Debian 5.3.1-8) 5.3.1 20160205
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 8f44df154de79a61b0e86734f51737b8cccf8dfe
# save the attached .config to linux build tree
make.cross ARCH=s390
All warnings (new ones prefixed by >>):
crypto/ecc.c: In function 'vli_mmod_fast':
crypto/ecc.c:532:1: warning: 'vli_mmod_fast' uses dynamic stack allocation
}
^
crypto/ecc.c: In function 'vli_mod_square_fast':
crypto/ecc.c:552:1: warning: 'vli_mod_square_fast' uses dynamic stack allocation
}
^
crypto/ecc.c: In function 'vli_mod_mult_fast':
crypto/ecc.c:542:1: warning: 'vli_mod_mult_fast' uses dynamic stack allocation
}
^
crypto/ecc.c: In function 'xycz_add_c':
crypto/ecc.c:840:1: warning: 'xycz_add_c' uses dynamic stack allocation
}
^
crypto/ecc.c: In function 'xycz_add':
crypto/ecc.c:783:1: warning: 'xycz_add' uses dynamic stack allocation
}
^
crypto/ecc.c: In function 'apply_z':
crypto/ecc.c:719:1: warning: 'apply_z' uses dynamic stack allocation
}
^
crypto/ecc.c: In function 'ecc_point_mult.isra.0':
crypto/ecc.c:895:1: warning: 'ecc_point_mult.isra.0' uses dynamic stack allocation
}
^
crypto/ecc.c: In function 'ecdh_make_pub_key':
crypto/ecc.c:967:1: warning: 'ecdh_make_pub_key' uses dynamic stack allocation
}
^
crypto/ecc.c: In function 'crypto_ecdh_shared_secret':
>> crypto/ecc.c:1018:1: warning: 'crypto_ecdh_shared_secret' uses dynamic stack allocation
}
^
vim +/crypto_ecdh_shared_secret +1018 crypto/ecc.c
3c4b2390 Salvatore Benedetto 2016-06-22 889 xycz_add(rx[nb], ry[nb], rx[1 - nb], ry[1 - nb], curve_prime, ndigits);
3c4b2390 Salvatore Benedetto 2016-06-22 890
3c4b2390 Salvatore Benedetto 2016-06-22 891 apply_z(rx[0], ry[0], z, curve_prime, ndigits);
3c4b2390 Salvatore Benedetto 2016-06-22 892
3c4b2390 Salvatore Benedetto 2016-06-22 893 vli_set(result->x, rx[0], ndigits);
3c4b2390 Salvatore Benedetto 2016-06-22 894 vli_set(result->y, ry[0], ndigits);
3c4b2390 Salvatore Benedetto 2016-06-22 @895 }
3c4b2390 Salvatore Benedetto 2016-06-22 896
3c4b2390 Salvatore Benedetto 2016-06-22 897 static inline void ecc_swap_digits(const u64 *in, u64 *out,
3c4b2390 Salvatore Benedetto 2016-06-22 898 unsigned int ndigits)
3c4b2390 Salvatore Benedetto 2016-06-22 899 {
3c4b2390 Salvatore Benedetto 2016-06-22 900 int i;
3c4b2390 Salvatore Benedetto 2016-06-22 901
3c4b2390 Salvatore Benedetto 2016-06-22 902 for (i = 0; i < ndigits; i++)
3c4b2390 Salvatore Benedetto 2016-06-22 903 out[i] = __swab64(in[ndigits - 1 - i]);
3c4b2390 Salvatore Benedetto 2016-06-22 904 }
3c4b2390 Salvatore Benedetto 2016-06-22 905
3c4b2390 Salvatore Benedetto 2016-06-22 906 int ecc_is_key_valid(unsigned int curve_id, unsigned int ndigits,
3c4b2390 Salvatore Benedetto 2016-06-22 907 const u8 *private_key, unsigned int private_key_len)
3c4b2390 Salvatore Benedetto 2016-06-22 908 {
3c4b2390 Salvatore Benedetto 2016-06-22 909 int nbytes;
3c4b2390 Salvatore Benedetto 2016-06-22 910 const struct ecc_curve *curve = ecc_get_curve(curve_id);
3c4b2390 Salvatore Benedetto 2016-06-22 911
3c4b2390 Salvatore Benedetto 2016-06-22 912 if (!private_key)
3c4b2390 Salvatore Benedetto 2016-06-22 913 return -EINVAL;
3c4b2390 Salvatore Benedetto 2016-06-22 914
3c4b2390 Salvatore Benedetto 2016-06-22 915 nbytes = ndigits << ECC_DIGITS_TO_BYTES_SHIFT;
3c4b2390 Salvatore Benedetto 2016-06-22 916
3c4b2390 Salvatore Benedetto 2016-06-22 917 if (private_key_len != nbytes)
3c4b2390 Salvatore Benedetto 2016-06-22 918 return -EINVAL;
3c4b2390 Salvatore Benedetto 2016-06-22 919
3c4b2390 Salvatore Benedetto 2016-06-22 920 if (vli_is_zero((const u64 *)&private_key[0], ndigits))
3c4b2390 Salvatore Benedetto 2016-06-22 921 return -EINVAL;
3c4b2390 Salvatore Benedetto 2016-06-22 922
3c4b2390 Salvatore Benedetto 2016-06-22 923 /* Make sure the private key is in the range [1, n-1]. */
3c4b2390 Salvatore Benedetto 2016-06-22 924 if (vli_cmp(curve->n, (const u64 *)&private_key[0], ndigits) != 1)
3c4b2390 Salvatore Benedetto 2016-06-22 925 return -EINVAL;
3c4b2390 Salvatore Benedetto 2016-06-22 926
3c4b2390 Salvatore Benedetto 2016-06-22 927 return 0;
3c4b2390 Salvatore Benedetto 2016-06-22 928 }
3c4b2390 Salvatore Benedetto 2016-06-22 929
3c4b2390 Salvatore Benedetto 2016-06-22 930 int ecdh_make_pub_key(unsigned int curve_id, unsigned int ndigits,
3c4b2390 Salvatore Benedetto 2016-06-22 931 const u8 *private_key, unsigned int private_key_len,
3c4b2390 Salvatore Benedetto 2016-06-22 932 u8 *public_key, unsigned int public_key_len)
3c4b2390 Salvatore Benedetto 2016-06-22 933 {
3c4b2390 Salvatore Benedetto 2016-06-22 934 int ret = 0;
3c4b2390 Salvatore Benedetto 2016-06-22 935 struct ecc_point *pk;
3c4b2390 Salvatore Benedetto 2016-06-22 936 u64 priv[ndigits];
3c4b2390 Salvatore Benedetto 2016-06-22 937 unsigned int nbytes;
3c4b2390 Salvatore Benedetto 2016-06-22 938 const struct ecc_curve *curve = ecc_get_curve(curve_id);
3c4b2390 Salvatore Benedetto 2016-06-22 939
3c4b2390 Salvatore Benedetto 2016-06-22 940 if (!private_key || !curve) {
3c4b2390 Salvatore Benedetto 2016-06-22 941 ret = -EINVAL;
3c4b2390 Salvatore Benedetto 2016-06-22 942 goto out;
3c4b2390 Salvatore Benedetto 2016-06-22 943 }
3c4b2390 Salvatore Benedetto 2016-06-22 944
3c4b2390 Salvatore Benedetto 2016-06-22 945 ecc_swap_digits((const u64 *)private_key, priv, ndigits);
3c4b2390 Salvatore Benedetto 2016-06-22 946
3c4b2390 Salvatore Benedetto 2016-06-22 947 pk = ecc_alloc_point(ndigits);
3c4b2390 Salvatore Benedetto 2016-06-22 948 if (!pk) {
3c4b2390 Salvatore Benedetto 2016-06-22 949 ret = -ENOMEM;
3c4b2390 Salvatore Benedetto 2016-06-22 950 goto out;
3c4b2390 Salvatore Benedetto 2016-06-22 951 }
3c4b2390 Salvatore Benedetto 2016-06-22 952
3c4b2390 Salvatore Benedetto 2016-06-22 953 ecc_point_mult(pk, &curve->g, priv, NULL, curve->p, ndigits);
3c4b2390 Salvatore Benedetto 2016-06-22 954 if (ecc_point_is_zero(pk)) {
3c4b2390 Salvatore Benedetto 2016-06-22 955 ret = -EAGAIN;
3c4b2390 Salvatore Benedetto 2016-06-22 956 goto err_free_point;
3c4b2390 Salvatore Benedetto 2016-06-22 957 }
3c4b2390 Salvatore Benedetto 2016-06-22 958
3c4b2390 Salvatore Benedetto 2016-06-22 959 nbytes = ndigits << ECC_DIGITS_TO_BYTES_SHIFT;
3c4b2390 Salvatore Benedetto 2016-06-22 960 ecc_swap_digits(pk->x, (u64 *)public_key, ndigits);
3c4b2390 Salvatore Benedetto 2016-06-22 961 ecc_swap_digits(pk->y, (u64 *)&public_key[nbytes], ndigits);
3c4b2390 Salvatore Benedetto 2016-06-22 962
3c4b2390 Salvatore Benedetto 2016-06-22 963 err_free_point:
3c4b2390 Salvatore Benedetto 2016-06-22 964 ecc_free_point(pk);
3c4b2390 Salvatore Benedetto 2016-06-22 965 out:
3c4b2390 Salvatore Benedetto 2016-06-22 966 return ret;
3c4b2390 Salvatore Benedetto 2016-06-22 967 }
3c4b2390 Salvatore Benedetto 2016-06-22 968
8f44df15 Stephen Rothwell 2016-06-24 969 int crypto_ecdh_shared_secret(unsigned int curve_id, unsigned int ndigits,
3c4b2390 Salvatore Benedetto 2016-06-22 970 const u8 *private_key, unsigned int private_key_len,
3c4b2390 Salvatore Benedetto 2016-06-22 971 const u8 *public_key, unsigned int public_key_len,
3c4b2390 Salvatore Benedetto 2016-06-22 972 u8 *secret, unsigned int secret_len)
3c4b2390 Salvatore Benedetto 2016-06-22 973 {
3c4b2390 Salvatore Benedetto 2016-06-22 974 int ret = 0;
3c4b2390 Salvatore Benedetto 2016-06-22 975 struct ecc_point *product, *pk;
3c4b2390 Salvatore Benedetto 2016-06-22 976 u64 priv[ndigits];
3c4b2390 Salvatore Benedetto 2016-06-22 977 u64 rand_z[ndigits];
3c4b2390 Salvatore Benedetto 2016-06-22 978 unsigned int nbytes;
3c4b2390 Salvatore Benedetto 2016-06-22 979 const struct ecc_curve *curve = ecc_get_curve(curve_id);
3c4b2390 Salvatore Benedetto 2016-06-22 980
3c4b2390 Salvatore Benedetto 2016-06-22 981 if (!private_key || !public_key || !curve) {
3c4b2390 Salvatore Benedetto 2016-06-22 982 ret = -EINVAL;
3c4b2390 Salvatore Benedetto 2016-06-22 983 goto out;
3c4b2390 Salvatore Benedetto 2016-06-22 984 }
3c4b2390 Salvatore Benedetto 2016-06-22 985
3c4b2390 Salvatore Benedetto 2016-06-22 986 nbytes = ndigits << ECC_DIGITS_TO_BYTES_SHIFT;
3c4b2390 Salvatore Benedetto 2016-06-22 987
3c4b2390 Salvatore Benedetto 2016-06-22 988 get_random_bytes(rand_z, nbytes);
3c4b2390 Salvatore Benedetto 2016-06-22 989
3c4b2390 Salvatore Benedetto 2016-06-22 990 pk = ecc_alloc_point(ndigits);
3c4b2390 Salvatore Benedetto 2016-06-22 991 if (!pk) {
3c4b2390 Salvatore Benedetto 2016-06-22 992 ret = -ENOMEM;
3c4b2390 Salvatore Benedetto 2016-06-22 993 goto out;
3c4b2390 Salvatore Benedetto 2016-06-22 994 }
3c4b2390 Salvatore Benedetto 2016-06-22 995
3c4b2390 Salvatore Benedetto 2016-06-22 996 product = ecc_alloc_point(ndigits);
3c4b2390 Salvatore Benedetto 2016-06-22 997 if (!product) {
3c4b2390 Salvatore Benedetto 2016-06-22 998 ret = -ENOMEM;
3c4b2390 Salvatore Benedetto 2016-06-22 999 goto err_alloc_product;
3c4b2390 Salvatore Benedetto 2016-06-22 1000 }
3c4b2390 Salvatore Benedetto 2016-06-22 1001
3c4b2390 Salvatore Benedetto 2016-06-22 1002 ecc_swap_digits((const u64 *)public_key, pk->x, ndigits);
3c4b2390 Salvatore Benedetto 2016-06-22 1003 ecc_swap_digits((const u64 *)&public_key[nbytes], pk->y, ndigits);
3c4b2390 Salvatore Benedetto 2016-06-22 1004 ecc_swap_digits((const u64 *)private_key, priv, ndigits);
3c4b2390 Salvatore Benedetto 2016-06-22 1005
3c4b2390 Salvatore Benedetto 2016-06-22 1006 ecc_point_mult(product, pk, priv, rand_z, curve->p, ndigits);
3c4b2390 Salvatore Benedetto 2016-06-22 1007
3c4b2390 Salvatore Benedetto 2016-06-22 1008 ecc_swap_digits(product->x, (u64 *)secret, ndigits);
3c4b2390 Salvatore Benedetto 2016-06-22 1009
3c4b2390 Salvatore Benedetto 2016-06-22 1010 if (ecc_point_is_zero(product))
3c4b2390 Salvatore Benedetto 2016-06-22 1011 ret = -EFAULT;
3c4b2390 Salvatore Benedetto 2016-06-22 1012
3c4b2390 Salvatore Benedetto 2016-06-22 1013 ecc_free_point(product);
3c4b2390 Salvatore Benedetto 2016-06-22 1014 err_alloc_product:
3c4b2390 Salvatore Benedetto 2016-06-22 1015 ecc_free_point(pk);
3c4b2390 Salvatore Benedetto 2016-06-22 1016 out:
3c4b2390 Salvatore Benedetto 2016-06-22 1017 return ret;
3c4b2390 Salvatore Benedetto 2016-06-22 @1018 }
:::::: The code at line 1018 was first introduced by commit
:::::: 3c4b23901a0c766879dff680cd6bdab47bcdbbd2 crypto: ecdh - Add ECDH software support
:::::: TO: Salvatore Benedetto <salvatore.benedetto@intel.com>
:::::: CC: Herbert Xu <herbert@gondor.apana.org.au>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 41745 bytes --]
^ permalink raw reply
* [cryptodev:master 84/87] security/keys/big_key.c:118:1: warning: 'big_key_crypt' uses dynamic stack allocation
From: kbuild test robot @ 2016-06-25 1:56 UTC (permalink / raw)
Cc: kbuild-all, linux-crypto, Herbert Xu
[-- Attachment #1: Type: text/plain, Size: 3014 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
head: 8f44df154de79a61b0e86734f51737b8cccf8dfe
commit: d56d72c6a0612be14ccb455c92886d2cb102c2ab [84/87] KEYS: Use skcipher for big keys
config: s390-allyesconfig (attached as .config)
compiler: s390x-linux-gnu-gcc (Debian 5.3.1-8) 5.3.1 20160205
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout d56d72c6a0612be14ccb455c92886d2cb102c2ab
# save the attached .config to linux build tree
make.cross ARCH=s390
All warnings (new ones prefixed by >>):
security/keys/big_key.c: In function 'big_key_crypt':
>> security/keys/big_key.c:118:1: warning: 'big_key_crypt' uses dynamic stack allocation
}
^
vim +/big_key_crypt +118 security/keys/big_key.c
d56d72c6 Herbert Xu 2016-06-22 102 skcipher_request_set_tfm(req, big_key_skcipher);
d56d72c6 Herbert Xu 2016-06-22 103 skcipher_request_set_callback(req, CRYPTO_TFM_REQ_MAY_SLEEP,
d56d72c6 Herbert Xu 2016-06-22 104 NULL, NULL);
13100a72 Kirill Marinushkin 2016-04-12 105
13100a72 Kirill Marinushkin 2016-04-12 106 sg_init_one(&sgio, data, datalen);
d56d72c6 Herbert Xu 2016-06-22 107 skcipher_request_set_crypt(req, &sgio, &sgio, datalen, NULL);
13100a72 Kirill Marinushkin 2016-04-12 108
13100a72 Kirill Marinushkin 2016-04-12 109 if (op == BIG_KEY_ENC)
d56d72c6 Herbert Xu 2016-06-22 110 ret = crypto_skcipher_encrypt(req);
13100a72 Kirill Marinushkin 2016-04-12 111 else
d56d72c6 Herbert Xu 2016-06-22 112 ret = crypto_skcipher_decrypt(req);
d56d72c6 Herbert Xu 2016-06-22 113
d56d72c6 Herbert Xu 2016-06-22 114 skcipher_request_zero(req);
13100a72 Kirill Marinushkin 2016-04-12 115
13100a72 Kirill Marinushkin 2016-04-12 116 error:
13100a72 Kirill Marinushkin 2016-04-12 117 return ret;
13100a72 Kirill Marinushkin 2016-04-12 @118 }
13100a72 Kirill Marinushkin 2016-04-12 119
13100a72 Kirill Marinushkin 2016-04-12 120 /*
002edaf7 David Howells 2014-07-18 121 * Preparse a big key
ab3c3587 David Howells 2013-09-24 122 */
002edaf7 David Howells 2014-07-18 123 int big_key_preparse(struct key_preparsed_payload *prep)
ab3c3587 David Howells 2013-09-24 124 {
146aa8b1 David Howells 2015-10-21 125 struct path *path = (struct path *)&prep->payload.data[big_key_path];
ab3c3587 David Howells 2013-09-24 126 struct file *file;
:::::: The code at line 118 was first introduced by commit
:::::: 13100a72f40f5748a04017e0ab3df4cf27c809ef Security: Keys: Big keys stored encrypted
:::::: TO: Kirill Marinushkin <k.marinushkin@gmail.com>
:::::: CC: David Howells <dhowells@redhat.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 41745 bytes --]
^ permalink raw reply
* Re: crypto: rsa - Do not gratuitously drop leading zeroes
From: Herbert Xu @ 2016-06-25 1:44 UTC (permalink / raw)
To: Tadeusz Struk
Cc: Andrzej Zaborowski, Linux Crypto Mailing List, Tudor Ambarus,
Stephan Mueller
In-Reply-To: <1e8d942b-a549-b8a7-58d0-19c375597cfb@intel.com>
On Fri, Jun 24, 2016 at 08:25:02AM -0700, Tadeusz Struk wrote:
> Yes, but now mpi_get_buffer() calls mpi_read_buffer() and it is also
> used by security/keys/dh.c
It appears to be using mpi_read_buffer gratuitously. It should
simply use mpi_get_buffer.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 5/8] KEYS: Provide software public key query function [ver #2]
From: Herbert Xu @ 2016-06-25 1:37 UTC (permalink / raw)
To: David Howells
Cc: Mat Martineau, dwmw2, tadeusz.struk, linux-security-module,
keyrings, linux-kernel, linux-crypto, Christoph Hellwig,
Theodore Ts'o, Linus Torvalds, James Morris
In-Reply-To: <7446.1466769962@warthog.procyon.org.uk>
On Fri, Jun 24, 2016 at 01:06:02PM +0100, David Howells wrote:
>
> The problem is that if I'm to produce consistency with, say, the TPM
> interface, then I have to deal in wrapped/padded data - leastways as far as I
> can tell from reading the docs.
So the TPM device is accessed through the same interface? Where is
the code for it?
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [cryptodev:master 79/87] crypto/ecc.c:532:1: warning: 'vli_mmod_fast' uses dynamic stack allocation
From: kbuild test robot @ 2016-06-25 1:19 UTC (permalink / raw)
Cc: kbuild-all, linux-crypto, Herbert Xu, Salvatore Benedetto
[-- Attachment #1: Type: text/plain, Size: 8725 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
head: 8f44df154de79a61b0e86734f51737b8cccf8dfe
commit: 3c4b23901a0c766879dff680cd6bdab47bcdbbd2 [79/87] crypto: ecdh - Add ECDH software support
config: s390-allyesconfig (attached as .config)
compiler: s390x-linux-gnu-gcc (Debian 5.3.1-8) 5.3.1 20160205
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 3c4b23901a0c766879dff680cd6bdab47bcdbbd2
# save the attached .config to linux build tree
make.cross ARCH=s390
All warnings (new ones prefixed by >>):
crypto/ecc.c: In function 'vli_mmod_fast':
>> crypto/ecc.c:532:1: warning: 'vli_mmod_fast' uses dynamic stack allocation
}
^
crypto/ecc.c: In function 'vli_mod_square_fast':
>> crypto/ecc.c:552:1: warning: 'vli_mod_square_fast' uses dynamic stack allocation
}
^
crypto/ecc.c: In function 'vli_mod_mult_fast':
>> crypto/ecc.c:542:1: warning: 'vli_mod_mult_fast' uses dynamic stack allocation
}
^
crypto/ecc.c: In function 'xycz_add_c':
>> crypto/ecc.c:840:1: warning: 'xycz_add_c' uses dynamic stack allocation
}
^
crypto/ecc.c: In function 'xycz_add':
>> crypto/ecc.c:783:1: warning: 'xycz_add' uses dynamic stack allocation
}
^
crypto/ecc.c: In function 'apply_z':
>> crypto/ecc.c:719:1: warning: 'apply_z' uses dynamic stack allocation
}
^
crypto/ecc.c: In function 'ecc_point_mult.isra.0':
>> crypto/ecc.c:895:1: warning: 'ecc_point_mult.isra.0' uses dynamic stack allocation
}
^
crypto/ecc.c: In function 'ecdh_make_pub_key':
>> crypto/ecc.c:967:1: warning: 'ecdh_make_pub_key' uses dynamic stack allocation
}
^
crypto/ecc.c: In function 'ecdh_shared_secret':
crypto/ecc.c:1018:1: warning: 'ecdh_shared_secret' uses dynamic stack allocation
}
^
vim +/vli_mmod_fast +532 crypto/ecc.c
526 default:
527 pr_err("unsupports digits size!\n");
528 return false;
529 }
530
531 return true;
> 532 }
533
534 /* Computes result = (left * right) % curve_prime. */
535 static void vli_mod_mult_fast(u64 *result, const u64 *left, const u64 *right,
536 const u64 *curve_prime, unsigned int ndigits)
537 {
538 u64 product[2 * ndigits];
539
540 vli_mult(product, left, right, ndigits);
541 vli_mmod_fast(result, product, curve_prime, ndigits);
> 542 }
543
544 /* Computes result = left^2 % curve_prime. */
545 static void vli_mod_square_fast(u64 *result, const u64 *left,
546 const u64 *curve_prime, unsigned int ndigits)
547 {
548 u64 product[2 * ndigits];
549
550 vli_square(product, left, ndigits);
551 vli_mmod_fast(result, product, curve_prime, ndigits);
> 552 }
553
554 #define EVEN(vli) (!(vli[0] & 1))
555 /* Computes result = (1 / p_input) % mod. All VLIs are the same size.
556 * See "From Euclid's GCD to Montgomery Multiplication to the Great Divide"
557 * https://labs.oracle.com/techrep/2001/smli_tr-2001-95.pdf
558 */
559 static void vli_mod_inv(u64 *result, const u64 *input, const u64 *mod,
560 unsigned int ndigits)
561 {
562 u64 a[ndigits], b[ndigits];
563 u64 u[ndigits], v[ndigits];
564 u64 carry;
565 int cmp_result;
566
567 if (vli_is_zero(input, ndigits)) {
568 vli_clear(result, ndigits);
569 return;
570 }
571
572 vli_set(a, input, ndigits);
573 vli_set(b, mod, ndigits);
574 vli_clear(u, ndigits);
575 u[0] = 1;
576 vli_clear(v, ndigits);
577
578 while ((cmp_result = vli_cmp(a, b, ndigits)) != 0) {
579 carry = 0;
580
581 if (EVEN(a)) {
582 vli_rshift1(a, ndigits);
583
584 if (!EVEN(u))
585 carry = vli_add(u, u, mod, ndigits);
586
587 vli_rshift1(u, ndigits);
588 if (carry)
589 u[ndigits - 1] |= 0x8000000000000000ull;
590 } else if (EVEN(b)) {
591 vli_rshift1(b, ndigits);
592
593 if (!EVEN(v))
594 carry = vli_add(v, v, mod, ndigits);
595
596 vli_rshift1(v, ndigits);
597 if (carry)
598 v[ndigits - 1] |= 0x8000000000000000ull;
599 } else if (cmp_result > 0) {
600 vli_sub(a, a, b, ndigits);
601 vli_rshift1(a, ndigits);
602
603 if (vli_cmp(u, v, ndigits) < 0)
604 vli_add(u, u, mod, ndigits);
605
606 vli_sub(u, u, v, ndigits);
607 if (!EVEN(u))
608 carry = vli_add(u, u, mod, ndigits);
609
610 vli_rshift1(u, ndigits);
611 if (carry)
612 u[ndigits - 1] |= 0x8000000000000000ull;
613 } else {
614 vli_sub(b, b, a, ndigits);
615 vli_rshift1(b, ndigits);
616
617 if (vli_cmp(v, u, ndigits) < 0)
618 vli_add(v, v, mod, ndigits);
619
620 vli_sub(v, v, u, ndigits);
621 if (!EVEN(v))
622 carry = vli_add(v, v, mod, ndigits);
623
624 vli_rshift1(v, ndigits);
625 if (carry)
626 v[ndigits - 1] |= 0x8000000000000000ull;
627 }
628 }
629
630 vli_set(result, u, ndigits);
631 }
632
633 /* ------ Point operations ------ */
634
635 /* Returns true if p_point is the point at infinity, false otherwise. */
636 static bool ecc_point_is_zero(const struct ecc_point *point)
637 {
638 return (vli_is_zero(point->x, point->ndigits) &&
639 vli_is_zero(point->y, point->ndigits));
640 }
641
642 /* Point multiplication algorithm using Montgomery's ladder with co-Z
643 * coordinates. From http://eprint.iacr.org/2011/338.pdf
644 */
645
646 /* Double in place */
647 static void ecc_point_double_jacobian(u64 *x1, u64 *y1, u64 *z1,
648 u64 *curve_prime, unsigned int ndigits)
649 {
650 /* t1 = x, t2 = y, t3 = z */
651 u64 t4[ndigits];
652 u64 t5[ndigits];
653
654 if (vli_is_zero(z1, ndigits))
655 return;
656
657 /* t4 = y1^2 */
658 vli_mod_square_fast(t4, y1, curve_prime, ndigits);
659 /* t5 = x1*y1^2 = A */
660 vli_mod_mult_fast(t5, x1, t4, curve_prime, ndigits);
661 /* t4 = y1^4 */
662 vli_mod_square_fast(t4, t4, curve_prime, ndigits);
663 /* t2 = y1*z1 = z3 */
664 vli_mod_mult_fast(y1, y1, z1, curve_prime, ndigits);
665 /* t3 = z1^2 */
666 vli_mod_square_fast(z1, z1, curve_prime, ndigits);
667
668 /* t1 = x1 + z1^2 */
669 vli_mod_add(x1, x1, z1, curve_prime, ndigits);
670 /* t3 = 2*z1^2 */
671 vli_mod_add(z1, z1, z1, curve_prime, ndigits);
672 /* t3 = x1 - z1^2 */
673 vli_mod_sub(z1, x1, z1, curve_prime, ndigits);
674 /* t1 = x1^2 - z1^4 */
675 vli_mod_mult_fast(x1, x1, z1, curve_prime, ndigits);
676
677 /* t3 = 2*(x1^2 - z1^4) */
678 vli_mod_add(z1, x1, x1, curve_prime, ndigits);
679 /* t1 = 3*(x1^2 - z1^4) */
680 vli_mod_add(x1, x1, z1, curve_prime, ndigits);
681 if (vli_test_bit(x1, 0)) {
682 u64 carry = vli_add(x1, x1, curve_prime, ndigits);
683
684 vli_rshift1(x1, ndigits);
685 x1[ndigits - 1] |= carry << 63;
686 } else {
687 vli_rshift1(x1, ndigits);
688 }
689 /* t1 = 3/2*(x1^2 - z1^4) = B */
690
691 /* t3 = B^2 */
692 vli_mod_square_fast(z1, x1, curve_prime, ndigits);
693 /* t3 = B^2 - A */
694 vli_mod_sub(z1, z1, t5, curve_prime, ndigits);
695 /* t3 = B^2 - 2A = x3 */
696 vli_mod_sub(z1, z1, t5, curve_prime, ndigits);
697 /* t5 = A - x3 */
698 vli_mod_sub(t5, t5, z1, curve_prime, ndigits);
699 /* t1 = B * (A - x3) */
700 vli_mod_mult_fast(x1, x1, t5, curve_prime, ndigits);
701 /* t4 = B * (A - x3) - y1^4 = y3 */
702 vli_mod_sub(t4, x1, t4, curve_prime, ndigits);
703
704 vli_set(x1, z1, ndigits);
705 vli_set(z1, y1, ndigits);
706 vli_set(y1, t4, ndigits);
707 }
708
709 /* Modify (x1, y1) => (x1 * z^2, y1 * z^3) */
710 static void apply_z(u64 *x1, u64 *y1, u64 *z, u64 *curve_prime,
711 unsigned int ndigits)
712 {
713 u64 t1[ndigits];
714
715 vli_mod_square_fast(t1, z, curve_prime, ndigits); /* z^2 */
716 vli_mod_mult_fast(x1, x1, t1, curve_prime, ndigits); /* x1 * z^2 */
717 vli_mod_mult_fast(t1, t1, z, curve_prime, ndigits); /* z^3 */
718 vli_mod_mult_fast(y1, y1, t1, curve_prime, ndigits); /* y1 * z^3 */
> 719 }
720
721 /* P = (x1, y1) => 2P, (x2, y2) => P' */
722 static void xycz_initial_double(u64 *x1, u64 *y1, u64 *x2, u64 *y2,
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 41745 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] hw_random: bcm2835: Add support for Broadcom BCM5301x
From: Florian Fainelli @ 2016-06-24 17:30 UTC (permalink / raw)
To: Herbert Xu
Cc: linux-crypto, yendapally.reddy, eric, bcm-kernel-feedback-list,
devicetre, hauke, zajec5, mpm, linux-arm-kernel
In-Reply-To: <20160624133122.GC21111@gondor.apana.org.au>
On 06/24/2016 06:31 AM, Herbert Xu wrote:
> On Wed, Jun 22, 2016 at 05:27:02PM -0700, Florian Fainelli wrote:
>> The Broadcom BCM5301x SoCs (Northstar) utilize the same random number
>> generator peripheral as Northstar Plus and BCM2835, but just like the
>> NSP SoC, we need to enable the interrupt.
>>
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>
> Patch applied.
>
Thanks! Do you mind taking patch 1 as well? I will take patch 3 via my
arm-soc tree.
--
Florian
^ permalink raw reply
* Re: [PATCH] hwrng: OMAP: Fix assumption that runtime_get_sync will always succeed
From: Nishanth Menon @ 2016-06-24 16:54 UTC (permalink / raw)
To: Herbert Xu, Matt Mackall, Deepak Saxena
Cc: linux-kernel, linux-crypto, linux-omap, linux-arm-kernel, s-anna,
Paul Walmsley
In-Reply-To: <1466787040-26184-2-git-send-email-nm@ti.com>
On 06/24/2016 11:50 AM, Nishanth Menon wrote:
> pm_runtime_get_sync does return a error value that must be checked for
> error conditions, else, due to various reasons, the device maynot be
> enabled and the system will crash due to lack of clock to the hardware
> module.
>
Oh crap! Apologies, please ignore the v1 patch which was unfortunately
reposted. Sorry for the spam - i was pretty sure I cleared out the old
patch, but looks I was wrong.
V2 of the patch is here: https://patchwork.kernel.org/patch/9197919/
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH] hwrng: OMAP: Fix assumption that runtime_get_sync will always succeed
From: Nishanth Menon @ 2016-06-24 16:50 UTC (permalink / raw)
To: Herbert Xu, Matt Mackall, Deepak Saxena
Cc: Nishanth Menon, Paul Walmsley, linux-omap, linux-kernel,
linux-crypto, linux-arm-kernel
In-Reply-To: <1466787040-26184-1-git-send-email-nm@ti.com>
pm_runtime_get_sync does return a error value that must be checked for
error conditions, else, due to various reasons, the device maynot be
enabled and the system will crash due to lack of clock to the hardware
module.
Before:
12.562784] [00000000] *pgd=fe193835
12.562792] Internal error: : 1406 [#1] SMP ARM
[...]
12.562864] CPU: 1 PID: 241 Comm: modprobe Not tainted 4.7.0-rc4-next-20160624 #2
12.562867] Hardware name: Generic DRA74X (Flattened Device Tree)
12.562872] task: ed51f140 ti: ed44c000 task.ti: ed44c000
12.562886] PC is at omap4_rng_init+0x20/0x84 [omap_rng]
12.562899] LR is at set_current_rng+0xc0/0x154 [rng_core]
[...]
After the proper checks:
[ 94.366705] omap_rng 48090000.rng: _od_fail_runtime_resume: FIXME:
missing hwmod/omap_dev info
[ 94.375767] omap_rng 48090000.rng: Failed to runtime_get device -19
[ 94.382351] omap_rng 48090000.rng: initialization failed.
Fixes: 665d92fa85b5 ("hwrng: OMAP: convert to use runtime PM")
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Issue seen with next-20160624
Full crash log: http://pastebin.ubuntu.com/17801376/
drivers/char/hw_random/omap-rng.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/char/hw_random/omap-rng.c b/drivers/char/hw_random/omap-rng.c
index 8a1432e8bb80..f30a1870cb64 100644
--- a/drivers/char/hw_random/omap-rng.c
+++ b/drivers/char/hw_random/omap-rng.c
@@ -384,7 +384,11 @@ static int omap_rng_probe(struct platform_device *pdev)
}
pm_runtime_enable(&pdev->dev);
- pm_runtime_get_sync(&pdev->dev);
+ ret = pm_runtime_get_sync(&pdev->dev);
+ if (ret) {
+ dev_err(&pdev->dev, "Failed to runtime_get device: %d\n", ret);
+ goto err_ioremap;
+ }
ret = (dev->of_node) ? of_get_omap_rng_device_details(priv, pdev) :
get_omap_rng_device_details(priv);
@@ -435,8 +439,14 @@ static int __maybe_unused omap_rng_suspend(struct device *dev)
static int __maybe_unused omap_rng_resume(struct device *dev)
{
struct omap_rng_dev *priv = dev_get_drvdata(dev);
+ int ret;
+
+ ret = pm_runtime_get_sync(dev);
+ if (ret) {
+ dev_err(dev, "Failed to runtime_get device: %d\n", ret);
+ return ret;
+ }
- pm_runtime_get_sync(dev);
priv->pdata->init(priv);
return 0;
--
2.9.0
^ permalink raw reply related
* [PATCH V2] hwrng: OMAP: Fix assumption that runtime_get_sync will always succeed
From: Nishanth Menon @ 2016-06-24 16:50 UTC (permalink / raw)
To: Herbert Xu, Matt Mackall, Deepak Saxena
Cc: Nishanth Menon, Paul Walmsley, linux-omap, linux-kernel,
linux-crypto, linux-arm-kernel
pm_runtime_get_sync does return a error value that must be checked for
error conditions, else, due to various reasons, the device maynot be
enabled and the system will crash due to lack of clock to the hardware
module.
Before:
12.562784] [00000000] *pgd=fe193835
12.562792] Internal error: : 1406 [#1] SMP ARM
[...]
12.562864] CPU: 1 PID: 241 Comm: modprobe Not tainted 4.7.0-rc4-next-20160624 #2
12.562867] Hardware name: Generic DRA74X (Flattened Device Tree)
12.562872] task: ed51f140 ti: ed44c000 task.ti: ed44c000
12.562886] PC is at omap4_rng_init+0x20/0x84 [omap_rng]
12.562899] LR is at set_current_rng+0xc0/0x154 [rng_core]
[...]
After the proper checks:
[ 94.366705] omap_rng 48090000.rng: _od_fail_runtime_resume: FIXME:
missing hwmod/omap_dev info
[ 94.375767] omap_rng 48090000.rng: Failed to runtime_get device -19
[ 94.382351] omap_rng 48090000.rng: initialization failed.
Fixes: 665d92fa85b5 ("hwrng: OMAP: convert to use runtime PM")
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Changes in V2:
- Added runtime_put_noidle when get_sync fails to ensure proper refcounting
V1: https://patchwork.kernel.org/patch/9197855/
Patch based on: next-20160624
Issue seen with next-20160624
Full crash log: http://pastebin.ubuntu.com/17801376/
drivers/char/hw_random/omap-rng.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/char/hw_random/omap-rng.c b/drivers/char/hw_random/omap-rng.c
index 8a1432e8bb80..01d4be2c354b 100644
--- a/drivers/char/hw_random/omap-rng.c
+++ b/drivers/char/hw_random/omap-rng.c
@@ -384,7 +384,12 @@ static int omap_rng_probe(struct platform_device *pdev)
}
pm_runtime_enable(&pdev->dev);
- pm_runtime_get_sync(&pdev->dev);
+ ret = pm_runtime_get_sync(&pdev->dev);
+ if (ret) {
+ dev_err(&pdev->dev, "Failed to runtime_get device: %d\n", ret);
+ pm_runtime_put_noidle(&pdev->dev);
+ goto err_ioremap;
+ }
ret = (dev->of_node) ? of_get_omap_rng_device_details(priv, pdev) :
get_omap_rng_device_details(priv);
@@ -435,8 +440,15 @@ static int __maybe_unused omap_rng_suspend(struct device *dev)
static int __maybe_unused omap_rng_resume(struct device *dev)
{
struct omap_rng_dev *priv = dev_get_drvdata(dev);
+ int ret;
+
+ ret = pm_runtime_get_sync(dev);
+ if (ret) {
+ dev_err(dev, "Failed to runtime_get device: %d\n", ret);
+ pm_runtime_put_noidle(dev);
+ return ret;
+ }
- pm_runtime_get_sync(dev);
priv->pdata->init(priv);
return 0;
--
2.9.0
^ permalink raw reply related
* Re: [PATCH] hwrng: OMAP: Fix assumption that runtime_get_sync will always succeed
From: Nishanth Menon @ 2016-06-24 16:46 UTC (permalink / raw)
To: Suman Anna, Herbert Xu, Matt Mackall, Deepak Saxena
Cc: linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Paul Walmsley
In-Reply-To: <576D6156.2050508@ti.com>
On 06/24/2016 11:35 AM, Suman Anna wrote:
[...]
>> diff --git a/drivers/char/hw_random/omap-rng.c b/drivers/char/hw_random/omap-rng.c
>> index 8a1432e8bb80..f30a1870cb64 100644
>> --- a/drivers/char/hw_random/omap-rng.c
>> +++ b/drivers/char/hw_random/omap-rng.c
>> @@ -384,7 +384,11 @@ static int omap_rng_probe(struct platform_device *pdev)
>> }
>>
>> pm_runtime_enable(&pdev->dev);
>> - pm_runtime_get_sync(&pdev->dev);
>> + ret = pm_runtime_get_sync(&pdev->dev);
>> + if (ret) {
>> + dev_err(&pdev->dev, "Failed to runtime_get device: %d\n", ret);
>> + goto err_ioremap;
>
> You need to also add a pm_runtime_put_noidle() on get_sync failures to
> balance the device's power usage_count.
>
Crap, yep, I should have known better. thanks for catching it.. v2
incoming..
--
Regards,
Nishanth Menon
^ permalink raw reply
* Re: [PATCH] hwrng: OMAP: Fix assumption that runtime_get_sync will always succeed
From: Suman Anna @ 2016-06-24 16:35 UTC (permalink / raw)
To: Menon, Nishanth, Herbert Xu, Matt Mackall, Deepak Saxena
Cc: linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Paul Walmsley
In-Reply-To: <1466783867-25743-1-git-send-email-nm@ti.com>
Hi Nishanth,
On 06/24/2016 10:57 AM, Menon, Nishanth wrote:
> pm_runtime_get_sync does return a error value that must be checked for
> error conditions, else, due to various reasons, the device maynot be
> enabled and the system will crash due to lack of clock to the hardware
> module.
>
> Before:
> 12.562784] [00000000] *pgd=fe193835
> 12.562792] Internal error: : 1406 [#1] SMP ARM
> [...]
> 12.562864] CPU: 1 PID: 241 Comm: modprobe Not tainted 4.7.0-rc4-next-20160624 #2
> 12.562867] Hardware name: Generic DRA74X (Flattened Device Tree)
> 12.562872] task: ed51f140 ti: ed44c000 task.ti: ed44c000
> 12.562886] PC is at omap4_rng_init+0x20/0x84 [omap_rng]
> 12.562899] LR is at set_current_rng+0xc0/0x154 [rng_core]
> [...]
>
> After the proper checks:
> [ 94.366705] omap_rng 48090000.rng: _od_fail_runtime_resume: FIXME:
> missing hwmod/omap_dev info
> [ 94.375767] omap_rng 48090000.rng: Failed to runtime_get device -19
> [ 94.382351] omap_rng 48090000.rng: initialization failed.
>
> Fixes: 665d92fa85b5 ("hwrng: OMAP: convert to use runtime PM")
> Cc: Paul Walmsley <paul@pwsan.com>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
>
> Patch based on: next-20160624
> Issue seen with next-20160624
> Full crash log: http://pastebin.ubuntu.com/17801376/
>
> drivers/char/hw_random/omap-rng.c | 14 ++++++++++++--
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/char/hw_random/omap-rng.c b/drivers/char/hw_random/omap-rng.c
> index 8a1432e8bb80..f30a1870cb64 100644
> --- a/drivers/char/hw_random/omap-rng.c
> +++ b/drivers/char/hw_random/omap-rng.c
> @@ -384,7 +384,11 @@ static int omap_rng_probe(struct platform_device *pdev)
> }
>
> pm_runtime_enable(&pdev->dev);
> - pm_runtime_get_sync(&pdev->dev);
> + ret = pm_runtime_get_sync(&pdev->dev);
> + if (ret) {
> + dev_err(&pdev->dev, "Failed to runtime_get device: %d\n", ret);
> + goto err_ioremap;
You need to also add a pm_runtime_put_noidle() on get_sync failures to
balance the device's power usage_count.
regards
Suman
> + }
>
> ret = (dev->of_node) ? of_get_omap_rng_device_details(priv, pdev) :
> get_omap_rng_device_details(priv);
> @@ -435,8 +439,14 @@ static int __maybe_unused omap_rng_suspend(struct device *dev)
> static int __maybe_unused omap_rng_resume(struct device *dev)
> {
> struct omap_rng_dev *priv = dev_get_drvdata(dev);
> + int ret;
> +
> + ret = pm_runtime_get_sync(dev);
> + if (ret) {
> + dev_err(dev, "Failed to runtime_get device: %d\n", ret);
> + return ret;
> + }
>
> - pm_runtime_get_sync(dev);
> priv->pdata->init(priv);
>
> return 0;
>
^ permalink raw reply
* [PATCH] hwrng: OMAP: Fix assumption that runtime_get_sync will always succeed
From: Nishanth Menon @ 2016-06-24 15:57 UTC (permalink / raw)
To: Herbert Xu, Matt Mackall, Deepak Saxena
Cc: linux-kernel, linux-crypto, linux-omap, linux-arm-kernel,
Nishanth Menon, Paul Walmsley
pm_runtime_get_sync does return a error value that must be checked for
error conditions, else, due to various reasons, the device maynot be
enabled and the system will crash due to lack of clock to the hardware
module.
Before:
12.562784] [00000000] *pgd=fe193835
12.562792] Internal error: : 1406 [#1] SMP ARM
[...]
12.562864] CPU: 1 PID: 241 Comm: modprobe Not tainted 4.7.0-rc4-next-20160624 #2
12.562867] Hardware name: Generic DRA74X (Flattened Device Tree)
12.562872] task: ed51f140 ti: ed44c000 task.ti: ed44c000
12.562886] PC is at omap4_rng_init+0x20/0x84 [omap_rng]
12.562899] LR is at set_current_rng+0xc0/0x154 [rng_core]
[...]
After the proper checks:
[ 94.366705] omap_rng 48090000.rng: _od_fail_runtime_resume: FIXME:
missing hwmod/omap_dev info
[ 94.375767] omap_rng 48090000.rng: Failed to runtime_get device -19
[ 94.382351] omap_rng 48090000.rng: initialization failed.
Fixes: 665d92fa85b5 ("hwrng: OMAP: convert to use runtime PM")
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Patch based on: next-20160624
Issue seen with next-20160624
Full crash log: http://pastebin.ubuntu.com/17801376/
drivers/char/hw_random/omap-rng.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/char/hw_random/omap-rng.c b/drivers/char/hw_random/omap-rng.c
index 8a1432e8bb80..f30a1870cb64 100644
--- a/drivers/char/hw_random/omap-rng.c
+++ b/drivers/char/hw_random/omap-rng.c
@@ -384,7 +384,11 @@ static int omap_rng_probe(struct platform_device *pdev)
}
pm_runtime_enable(&pdev->dev);
- pm_runtime_get_sync(&pdev->dev);
+ ret = pm_runtime_get_sync(&pdev->dev);
+ if (ret) {
+ dev_err(&pdev->dev, "Failed to runtime_get device: %d\n", ret);
+ goto err_ioremap;
+ }
ret = (dev->of_node) ? of_get_omap_rng_device_details(priv, pdev) :
get_omap_rng_device_details(priv);
@@ -435,8 +439,14 @@ static int __maybe_unused omap_rng_suspend(struct device *dev)
static int __maybe_unused omap_rng_resume(struct device *dev)
{
struct omap_rng_dev *priv = dev_get_drvdata(dev);
+ int ret;
+
+ ret = pm_runtime_get_sync(dev);
+ if (ret) {
+ dev_err(dev, "Failed to runtime_get device: %d\n", ret);
+ return ret;
+ }
- pm_runtime_get_sync(dev);
priv->pdata->init(priv);
return 0;
--
2.9.0
^ permalink raw reply related
* Re: crypto: rsa - Do not gratuitously drop leading zeroes
From: Tadeusz Struk @ 2016-06-24 15:25 UTC (permalink / raw)
To: Herbert Xu
Cc: Andrzej Zaborowski, Linux Crypto Mailing List, Tudor Ambarus,
Stephan Mueller
In-Reply-To: <20160624142814.GA21730@gondor.apana.org.au>
On 06/24/2016 07:28 AM, Herbert Xu wrote:
> Didn't we add mpi_read_buffer specifically for akcipher before
> we switched over to SGs? If nobody is using it we should just
> delete it.
Yes, but now mpi_get_buffer() calls mpi_read_buffer() and it is also
used by security/keys/dh.c
Thanks,
--
TS
^ permalink raw reply
* Re: crypto: rsa - Do not gratuitously drop leading zeroes
From: Herbert Xu @ 2016-06-24 14:28 UTC (permalink / raw)
To: Tadeusz Struk
Cc: Andrzej Zaborowski, Linux Crypto Mailing List, Tudor Ambarus,
Stephan Mueller
In-Reply-To: <1f2459d0-aea9-f595-18f6-854177f0eb8d@intel.com>
On Thu, Jun 23, 2016 at 08:25:05AM -0700, Tadeusz Struk wrote:
>
> The reason why mpi_write_to_sgl() strips the leading zeros is only
> because we said that it needs to work in the same way as the
> mpi_read_buffer(), which does remove it for whatever reason.
> So should we now change the mpi_read_buffer() as well?
Didn't we add mpi_read_buffer specifically for akcipher before
we switched over to SGs? If nobody is using it we should just
delete it.
> We also need to change the qat rsa implementation because it does remove
> zeros as well, but it will be very easy to do.
The way it's done with my patches you don't have to do the conversion
right away because it'll cope with either stripping or not stripping
leading zeroes. But yes it should simplify the code in qat so please
send in patches when you have time.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] MAINTAINERS: update maintainer for qat
From: Tadeusz Struk @ 2016-06-24 14:01 UTC (permalink / raw)
To: herbert; +Cc: linux-crypto, Tadeusz Struk
Add Giovanni and Salvatore who will take over the qat maintenance.
Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com>
---
MAINTAINERS | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index f4a9c13..5d813a3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9292,7 +9292,8 @@ L: rtc-linux@googlegroups.com
S: Maintained
QAT DRIVER
-M: Tadeusz Struk <tadeusz.struk@intel.com>
+M: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
+M: Salvatore Benedetto <salvatore.benedetto@intel.com>
L: qat-linux@intel.com
S: Supported
F: drivers/crypto/qat/
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 2/3] hw_random: bcm2835: Add support for Broadcom BCM5301x
From: Herbert Xu @ 2016-06-24 13:31 UTC (permalink / raw)
To: Florian Fainelli
Cc: linux-crypto, yendapally.reddy, eric, bcm-kernel-feedback-list,
devicetre, hauke, zajec5, mpm, linux-arm-kernel
In-Reply-To: <1466641623-3491-3-git-send-email-f.fainelli@gmail.com>
On Wed, Jun 22, 2016 at 05:27:02PM -0700, Florian Fainelli wrote:
> The Broadcom BCM5301x SoCs (Northstar) utilize the same random number
> generator peripheral as Northstar Plus and BCM2835, but just like the
> NSP SoC, we need to enable the interrupt.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Patch applied.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox