* Re: getrandom waits for a long time when /dev/random is insufficiently read from
From: Alex Xu @ 2016-07-29 14:14 UTC (permalink / raw)
To: Stephan Mueller; +Cc: Linux Crypto Mailing List, virtualization
In-Reply-To: <2622345.NpnZjxROFX@tauon.atsec.com>
On Fri, 29 Jul 2016 15:12:30 +0200
Stephan Mueller <smueller@chronox.de> wrote as excerpted:
> Am Freitag, 29. Juli 2016, 09:03:45 CEST schrieb Alex Xu:
> > In my opinion, assuming I am not doing something terribly wrong,
> > this constitutes a bug in the kernel's handling of getrandom calls
> > at boot, possibly only when the primary source of entropy is
> > virtio.
>
> Nope, I do not think that this is true:
>
> - /dev/random returns one byte for one byte of entropy received, but
> it has a lower limit of 64 bits
>
> - getrandom behaves like /dev/urandom (i.e. nonblocking) except
> during boot where it waits until the RNG has collected 128 bits
> before operating like a DRNG that is seeded once in a while when
> entropy comes in.
>
>
> Ciao
> Stephan
I don't follow. Assuming you are correct and this is the issue, then
reading 128 bits (16 bytes) from /dev/random should "exhaust the
supply" and then both reads from /dev/random and calling getrandom
should block.
That, however, is not the behavior I observed, which is that reading
any amount from /dev/random will never block (since it is fed
from /dev/urandom on the host side) whereas calling getrandom will
always block unless /dev/random is read from first.
Moreover, as long as virtio-rng is available (and fed
from /dev/urandom), /proc/sys/kernel/random/entropy_avail is always 961
immediately after booting, which is more than enough to satisfy a
one-byte read. After reading 1 byte, the estimate decreases to 896 or
897, but after reading 29 more bytes it increases to 1106.
Again, these observations are consistent with the conjecture that the
issue arises since virtio-rng is a "pull" source of entropy whereas
most other methods (e.g. interrupt timing) are "push" sources. I
suspect that a similar issue occurs if RDRAND is the only source of
entropy.
I also tried running rngd in the guest which resolved the issue but
seems entirely stupid to me, even moreso since
http://rhelblog.redhat.com/2015/03/09/red-hat-enterprise-linux-virtual-machines-access-to-random-numbers-made-easy/
says that "The use of rngd is now not required and the guest kernel
itself fetches entropy from the host when the available entropy falls
below a specific threshold.".
^ permalink raw reply
* Re: getrandom waits for a long time when /dev/random is insufficiently read from
From: Stephan Mueller @ 2016-07-29 13:12 UTC (permalink / raw)
To: Alex Xu; +Cc: Nikos Mavrogiannopoulos, Linux Crypto Mailing List,
virtualization
In-Reply-To: <20160729090345.798c3e6f.alex_y_xu@yahoo.ca>
Am Freitag, 29. Juli 2016, 09:03:45 CEST schrieb Alex Xu:
Hi Alex,
> On Fri, 29 Jul 2016 12:24:27 +0200
>
> Nikos Mavrogiannopoulos <nmav@gnutls.org> wrote:
> > On Fri, Jul 29, 2016 at 7:40 AM, Stephan Mueller
> >
> > <smueller@chronox.de> wrote:
> > > And finally, you have a coding error that is very very common but
> > > fatal when reading from /dev/random: you do not account for short
> > > reads which implies that your loop continues even in the case of
> > > short reads.
> > >
> > > Fix your code with something like the following:
> > > int read_random(char *buf, size_t buflen)
> > > {
> > >
> > > int fd = 0;
> > > ssize_t ret = 0;
> > > size_t len = 0;
> > >
> > > fd = open("/dev/random", O_RDONLY|O_CLOEXEC);
> > > if(0 > fd)
> > >
> > > return fd;
> > >
> > > do {
> > >
> > > ret = read(fd, (buf + len), (buflen - len));
> > > if (0 < ret)
> > >
> > > len += ret;
> > >
> > > } while ((0 < ret || EINTR == errno || ERESTART == errno)
> > >
> > > && buflen > len);
> >
> > Unless there is a documentation error, the same is required when using
> > getrandom(). It can also return short as well as to be interrupted.
> >
> > regards,
> > Nikos
>
> I am aware that (according to the documentation) both random(4) and
> getrandom(2) may not return the full size of the read. However, that is
> (as far as I know) not relevant to the point that I am making.
>
> What I am saying is that based on my understanding of random(4) and
> getrandom(2), at boot, given the same buffer size, reading
> from /dev/random should have the same behavior as calling getrandom
> passing no flags.
/dev/random can return after at least 64 bits received in the input_pool
whereas getrandom waits for 128 bits.
>
> The buffer size can also be set to 1 with similar results, but the
> iteration number for success must be then increased to a large number.
> IME 30 worked consistently while 29 hung; your results may vary.
>
> The interesting thing is though, if GRND_RANDOM is passed to getrandom,
> then it does not hang and returns 1 byte immediately (whether or not
> GRND_NONBLOCK is set).
Sure, because there is one byte in the input_pool at the time user space
boots. Note again, /dev/random waits until having 64 bits.
>
> 1, 2..29: reads all return 1 byte, getrandom pauses for 90-110 secs then
> returns 1 byte
> 30+: reads all return 1 byte, getrandom immediately returns 1 byte
> -r 0: getrandom immediately returns 1 byte
> -r 1, -r 2, -r 128, -r 256: reads all return 1 byte, getrandom
> immediately returns 1 byte
>
I would say that this is expected.
> Moving the open and close calls outside of the loop produces the same
> results. Writing 4096 bytes to /dev/urandom also has no effect.
Sure, it does not update the input_pool. Only the IOCTL can update the
input_pool from user space.
>
> In my opinion, assuming I am not doing something terribly wrong, this
> constitutes a bug in the kernel's handling of getrandom calls at boot,
> possibly only when the primary source of entropy is virtio.
Nope, I do not think that this is true:
- /dev/random returns one byte for one byte of entropy received, but it has a
lower limit of 64 bits
- getrandom behaves like /dev/urandom (i.e. nonblocking) except during boot
where it waits until the RNG has collected 128 bits before operating like a
DRNG that is seeded once in a while when entropy comes in.
Ciao
Stephan
^ permalink raw reply
* Re: getrandom waits for a long time when /dev/random is insufficiently read from
From: Alex Xu @ 2016-07-29 13:03 UTC (permalink / raw)
To: Nikos Mavrogiannopoulos
Cc: Stephan Mueller, Linux Crypto Mailing List, virtualization
In-Reply-To: <CAJU7zaL8G28chcwEEYAquApm2ncPaBjKky4UPaWVy=6B+-rsCA@mail.gmail.com>
On Fri, 29 Jul 2016 12:24:27 +0200
Nikos Mavrogiannopoulos <nmav@gnutls.org> wrote:
> On Fri, Jul 29, 2016 at 7:40 AM, Stephan Mueller
> <smueller@chronox.de> wrote:
> > And finally, you have a coding error that is very very common but
> > fatal when reading from /dev/random: you do not account for short
> > reads which implies that your loop continues even in the case of
> > short reads.
> >
> > Fix your code with something like the following:
> > int read_random(char *buf, size_t buflen)
> > {
> > int fd = 0;
> > ssize_t ret = 0;
> > size_t len = 0;
> >
> > fd = open("/dev/random", O_RDONLY|O_CLOEXEC);
> > if(0 > fd)
> > return fd;
> > do {
> > ret = read(fd, (buf + len), (buflen - len));
> > if (0 < ret)
> > len += ret;
> > } while ((0 < ret || EINTR == errno || ERESTART == errno)
> > && buflen > len);
>
> Unless there is a documentation error, the same is required when using
> getrandom(). It can also return short as well as to be interrupted.
>
> regards,
> Nikos
I am aware that (according to the documentation) both random(4) and
getrandom(2) may not return the full size of the read. However, that is
(as far as I know) not relevant to the point that I am making.
What I am saying is that based on my understanding of random(4) and
getrandom(2), at boot, given the same buffer size, reading
from /dev/random should have the same behavior as calling getrandom
passing no flags.
The buffer size can also be set to 1 with similar results, but the
iteration number for success must be then increased to a large number.
IME 30 worked consistently while 29 hung; your results may vary.
The interesting thing is though, if GRND_RANDOM is passed to getrandom,
then it does not hang and returns 1 byte immediately (whether or not
GRND_NONBLOCK is set).
The following revised program demonstrates this:
#include <fcntl.h>
#include <linux/random.h>
#include <stdlib.h>
#include <string.h>
#include <syscall.h>
#include <unistd.h>
int main(int argc, char *argv[]) {
char buf[1];
int gr_flags;
const char *iters;
if (!strcmp(argv[1], "-r")) {
gr_flags = GRND_RANDOM;
iters = argv[2];
} else {
gr_flags = 0;
iters = argv[1];
}
for (int i = 0; i < atoi(iters); i++) {
int fd;
if ((fd = open("/dev/random", O_RDONLY)) == -1)
return 2;
if (read(fd, buf, 1) != 1)
return 3;
if (close(fd) == -1)
return 4;
}
if (syscall(SYS_getrandom, buf, 1, gr_flags) != 1)
return 5;
return 0;
}
Again, making the buffer size 1 resolves the complaint regarding short
reads.
With the same command line as my original email, running this in QEMU
results in:
1, 2..29: reads all return 1 byte, getrandom pauses for 90-110 secs then
returns 1 byte
30+: reads all return 1 byte, getrandom immediately returns 1 byte
-r 0: getrandom immediately returns 1 byte
-r 1, -r 2, -r 128, -r 256: reads all return 1 byte, getrandom
immediately returns 1 byte
Moving the open and close calls outside of the loop produces the same
results. Writing 4096 bytes to /dev/urandom also has no effect.
In my opinion, assuming I am not doing something terribly wrong, this
constitutes a bug in the kernel's handling of getrandom calls at boot,
possibly only when the primary source of entropy is virtio.
^ permalink raw reply
* Re: [PATCH] crypto: marvell: Don't copy IV vectors from the _process op for ciphers
From: Herbert Xu @ 2016-07-29 10:37 UTC (permalink / raw)
To: Romain Perier
Cc: boris.brezillon, arno, davem, linux-crypto, thomas.petazzoni,
jason, andrew, sebastian.hesselbarth, gregory.clement
In-Reply-To: <1469699983-21370-1-git-send-email-romain.perier@free-electrons.com>
Romain Perier <romain.perier@free-electrons.com> wrote:
> The IV output vectors should only be copied from the _complete operation
> and not from the _process operation, i.e only from the operation that is
> designed to copy the result of the request to the right location. This
> copy is already done in the _complete operation, so this commit removes
> the duplicated code in the _process op.
>
> Fixes: 3610d6cd5231 ("crypto: marvell - Add a complete...")
> Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
Patch applied. 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: getrandom waits for a long time when /dev/random is insufficiently read from
From: Nikos Mavrogiannopoulos @ 2016-07-29 10:24 UTC (permalink / raw)
To: Stephan Mueller; +Cc: Alex Xu, Linux Crypto Mailing List, virtualization
In-Reply-To: <2481163.nONN48TG9I@tauon.atsec.com>
On Fri, Jul 29, 2016 at 7:40 AM, Stephan Mueller <smueller@chronox.de> wrote:
> And finally, you have a coding error that is very very common but fatal when
> reading from /dev/random: you do not account for short reads which implies
> that your loop continues even in the case of short reads.
>
> Fix your code with something like the following:
> int read_random(char *buf, size_t buflen)
> {
> int fd = 0;
> ssize_t ret = 0;
> size_t len = 0;
>
> fd = open("/dev/random", O_RDONLY|O_CLOEXEC);
> if(0 > fd)
> return fd;
> do {
> ret = read(fd, (buf + len), (buflen - len));
> if (0 < ret)
> len += ret;
> } while ((0 < ret || EINTR == errno || ERESTART == errno)
> && buflen > len);
Unless there is a documentation error, the same is required when using
getrandom(). It can also return short as well as to be interrupted.
regards,
Nikos
^ permalink raw reply
* [PATCH] crypto/testmgr.c: fix !x==y confusion
From: yanjiang.jin @ 2016-07-29 8:32 UTC (permalink / raw)
To: herbert, davem; +Cc: linux-kernel, linux-crypto, jinyanjiang
From: Yanjiang Jin <yanjiang.jin@windriver.com>
"if (!ret == template[i].fail)" is confusing to compilers (gcc5):
crypto/testmgr.c: In function '__test_aead':
crypto/testmgr.c:531:12: warning: logical not is only applied to the
left hand side of comparison [-Wlogical-not-parentheses]
if (!ret == template[i].fail) {
^
Let there be 'if (template[i].fail == !ret) '.
Signed-off-by: Yanjiang Jin <yanjiang.jin@windriver.com>
---
crypto/testmgr.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 5c9d5a5..c2a8bd3 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -665,7 +665,7 @@ static int __test_aead(struct crypto_aead *tfm, int enc,
memcpy(key, template[i].key, template[i].klen);
ret = crypto_aead_setkey(tfm, key, template[i].klen);
- if (!ret == template[i].fail) {
+ if (template[i].fail == !ret) {
pr_err("alg: aead%s: setkey failed on test %d for %s: flags=%x\n",
d, j, algo, crypto_aead_get_flags(tfm));
goto out;
@@ -770,7 +770,7 @@ static int __test_aead(struct crypto_aead *tfm, int enc,
memcpy(key, template[i].key, template[i].klen);
ret = crypto_aead_setkey(tfm, key, template[i].klen);
- if (!ret == template[i].fail) {
+ if (template[i].fail == !ret) {
pr_err("alg: aead%s: setkey failed on chunk test %d for %s: flags=%x\n",
d, j, algo, crypto_aead_get_flags(tfm));
goto out;
@@ -1023,7 +1023,7 @@ static int test_cipher(struct crypto_cipher *tfm, int enc,
ret = crypto_cipher_setkey(tfm, template[i].key,
template[i].klen);
- if (!ret == template[i].fail) {
+ if (template[i].fail == !ret) {
printk(KERN_ERR "alg: cipher: setkey failed "
"on test %d for %s: flags=%x\n", j,
algo, crypto_cipher_get_flags(tfm));
@@ -1133,7 +1133,7 @@ static int __test_skcipher(struct crypto_skcipher *tfm, int enc,
ret = crypto_skcipher_setkey(tfm, template[i].key,
template[i].klen);
- if (!ret == template[i].fail) {
+ if (template[i].fail == !ret) {
pr_err("alg: skcipher%s: setkey failed on test %d for %s: flags=%x\n",
d, j, algo, crypto_skcipher_get_flags(tfm));
goto out;
@@ -1211,7 +1211,7 @@ static int __test_skcipher(struct crypto_skcipher *tfm, int enc,
ret = crypto_skcipher_setkey(tfm, template[i].key,
template[i].klen);
- if (!ret == template[i].fail) {
+ if (template[i].fail == !ret) {
pr_err("alg: skcipher%s: setkey failed on chunk test %d for %s: flags=%x\n",
d, j, algo, crypto_skcipher_get_flags(tfm));
goto out;
--
1.9.1
^ permalink raw reply related
* Re: getrandom waits for a long time when /dev/random is insufficiently read from
From: Stephan Mueller @ 2016-07-29 5:40 UTC (permalink / raw)
To: Alex Xu; +Cc: linux-crypto, virtualization
In-Reply-To: <20160728180732.12d38880@alex-desktop>
Am Donnerstag, 28. Juli 2016, 18:07:32 CEST schrieb Alex Xu:
Hi Alex,
> Linux 4.6, also tried 4.7, qemu 2.6, using this C program:
I am not sure what problem you are referring to, but that is an expected
behavior.
You get partial reads when reading from /dev/random with a minimum of 64
bits. On the other hand getrandom(2) is woken up after the input_pool
received 128 bits of entropy.
In you strace you see that after reading 16 bytes from /dev/random, the
getrandom unblocks and starts delivering.
Note, in virtualized environments the current Linux /dev/random
implementation collects massively less entropy compared to a bare-metal
system. Hence the long wait time of your 90 to 100 secs until getrandom
unblocks.
Besides, even without reading from /dev/random, your getrandom will wait that
long.
And finally, you have a coding error that is very very common but fatal when
reading from /dev/random: you do not account for short reads which implies
that your loop continues even in the case of short reads.
Fix your code with something like the following:
int read_random(char *buf, size_t buflen)
{
int fd = 0;
ssize_t ret = 0;
size_t len = 0;
fd = open("/dev/random", O_RDONLY|O_CLOEXEC);
if(0 > fd)
return fd;
do {
ret = read(fd, (buf + len), (buflen - len));
if (0 < ret)
len += ret;
} while ((0 < ret || EINTR == errno || ERESTART == errno)
&& buflen > len);
...
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH 2/8] KEYS: Provide keyctls to drive the new key type ops for asymmetric keys [ver #2]
From: Mat Martineau @ 2016-07-28 23:21 UTC (permalink / raw)
To: David Howells
Cc: dwmw2, tadeusz.struk, linux-security-module, keyrings,
linux-kernel, linux-crypto
In-Reply-To: <146668966955.2977.16073224235350760987.stgit@warthog.procyon.org.uk>
On Thu, 23 Jun 2016, David Howells wrote:
> diff --git a/include/uapi/linux/keyctl.h b/include/uapi/linux/keyctl.h
> index 8ac2c5fbc8fc..93ebd25b1427 100644
> --- a/include/uapi/linux/keyctl.h
> +++ b/include/uapi/linux/keyctl.h
> @@ -60,6 +60,11 @@
> #define KEYCTL_INVALIDATE 21 /* invalidate a key */
> #define KEYCTL_GET_PERSISTENT 22 /* get a user's persistent keyring */
> #define KEYCTL_DH_COMPUTE 23 /* Compute Diffie-Hellman values */
> +#define KEYCTL_PKEY_QUERY 24 /* Query public key parameters */
> +#define KEYCTL_PKEY_ENCRYPT 25 /* Encrypt a blob using a public key */
> +#define KEYCTL_PKEY_DECRYPT 26 /* Decrypt a blob using a public key */
> +#define KEYCTL_PKEY_SIGN 27 /* Create a public key signature */
> +#define KEYCTL_PKEY_VERIFY 28 /* Verify a public key signature */
>
> /* keyctl structures */
> struct keyctl_dh_params {
> @@ -73,4 +78,24 @@ struct keyctl_dh_params {
> #define KEYCTL_SUPPORTS_SIGN 0x04
> #define KEYCTL_SUPPORTS_VERIFY 0x08
>
> +struct keyctl_pkey_query {
> + __u32 supported_ops; /* Which ops are supported */
> + __u32 key_size; /* Size of the key in bits */
> + __u16 max_data_size; /* Maximum size of raw data to sign in bytes */
> + __u16 max_sig_size; /* Maximum size of signature in bytes */
> + __u16 max_enc_size; /* Maximum size of encrypted blob in bytes */
> + __u16 max_dec_size; /* Maximum size of decrypted blob in bytes */
> + __u32 __spare[10];
> +};
It would also be useful to return pkey_algo so userspace can see which
algorithm is in use for the given public key. The public key algorithm is
printed in /proc/keys, but is not returned by KEYCTL_PKEY_QUERY or
KEYCTL_DESCRIBE.
Does it make sense to add the information from key->type->describe() to
KEYCTL_PKEY_QUERY or KEYCTL_DESCRIBE? Or add something new like
KEYCTL_DESCRIBE_TYPE?
--
Mat Martineau
Intel OTC
^ permalink raw reply
* getrandom waits for a long time when /dev/random is insufficiently read from
From: Alex Xu @ 2016-07-28 22:07 UTC (permalink / raw)
To: linux-crypto, virtualization
Linux 4.6, also tried 4.7, qemu 2.6, using this C program:
#include <fcntl.h>
#include <stdlib.h>
#include <syscall.h>
#include <unistd.h>
int main(int argc, char *argv[]) {
char buf[16];
int fd;
if (argc != 2)
return 1;
for (int i = 0; i < atoi(argv[1]); i++) {
sleep(1);
if ((fd = open("/dev/random", O_RDONLY)) == -1)
return 2;
if (read(fd, buf, sizeof(buf)) < 1)
return 3;
if (close(fd) == -1)
return 4;
}
sleep(2);
if (syscall(SYS_getrandom, buf, sizeof(buf), 0) == -1)
return 5;
return 0;
}
$ qemu-system-x86_64 -nodefaults -machine q35,accel=kvm -nographic -object rng-random,id=rng0,filename=/dev/urandom -device virtio-rng-pci,rng=rng0 -kernel linux-4.7/arch/x86/boot/bzImage -fsdev local,path="$PWD/root",security_model=none,id=root -device virtio-9p-pci,fsdev=root,mount_tag=/dev/root -device virtio-serial -chardev stdio,id=stdio -device virtconsole,chardev=stdio -monitor none -append "root=/dev/root rw rootfstype=9p rootflags=trans=virtio console=hvc0 init=/strace /test 2"
execve("/test", ["/test", "2"], [/* 2 vars */]) = 0
arch_prctl(ARCH_SET_FS, 0x601098) = 0
set_tid_address(0x6010d0) = 29
nanosleep({1, 0}, 0x7ffcdb7ea6b0) = 0
open("/dev/random", O_RDONLY) = 3
read(3, "P'\333\362\352\247\212\272\357E?\343", 16) = 12
close(3) = 0
nanosleep({1, 0}, 0x7ffcdb7ea6b0) = 0
open("/dev/random", O_RDONLY) = 3
read(3, ">>9\252]\332T\322dL\203\231C\255\303\376", 16) = 16
close(3) = 0
nanosleep({2, 0}, 0x7ffcdb7ea6e0) = 0
getrandom(<some time later>[ 89.166661] random: nonblocking pool is initialized
"\217\0\206\220\36t\3\353\t\227\377\356\315\320\2452", 16, 0) = 16
exit_group(0) = ?
+++ exited with 0 +++
Identical command but replaced 2 iterations with 3:
$ qemu-system-x86_64 -nodefaults -machine q35,accel=kvm -nographic -object rng-random,id=rng0,filename=/dev/urandom -device virtio-rng-pci,rng=rng0 -kernel linux-4.7/arch/x86/boot/bzImage -fsdev local,path="$PWD/root",security_model=none,id=root -device virtio-9p-pci,fsdev=root,mount_tag=/dev/root -device virtio-serial -chardev stdio,id=stdio -device virtconsole,chardev=stdio -monitor none -append "root=/dev/root rw rootfstype=9p rootflags=trans=virtio console=hvc0 init=/strace /test 3"
execve("/test", ["/test", "3"], [/* 2 vars */]) = 0
arch_prctl(ARCH_SET_FS, 0x601098) = 0
set_tid_address(0x6010d0) = 29
nanosleep({1, 0}, 0x7ffc9e13fb70) = 0
open("/dev/random", O_RDONLY) = 3
read(3, ">\202\264\350\226\364\364\320'-\200\16", 16) = 12
close(3) = 0
nanosleep({1, 0}, 0x7ffc9e13fb70) = 0
open("/dev/random", O_RDONLY) = 3
read(3, "\377:\2076\213q0E\307\377\\\234\217\"g\254", 16) = 16
close(3) = 0
nanosleep({1, 0}, 0x7ffc9e13fb70) = 0
open("/dev/random", O_RDONLY) = 3
read(3, [ 3.312266] random: nonblocking pool is initialized
"O\2112g\375\25]\270\347\v\34XP", 16) = 13
close(3) = 0
nanosleep({2, 0}, 0x7ffc9e13fba0) = 0
getrandom("\215\317\207/\324\6\300\216\332zN\351a\323\231\36", 16, 0) = 16
exit_group(0) = ?
+++ exited with 0 +++
(irrelevant kernel messages have been removed for clarity)
Removing the calls to "sleep" produces similar results except without
sleeping or the corresponding strace output. Running both commands
repeatedly also produces similar results; the timing of the getrandom
return and "random: nonblocking pool is initialized" message
is different for each run, but it always takes 90-100 seconds.
Sorry if these aren't the right lists or if this is a known issue.
Please CC me on replies.
^ permalink raw reply
* [GIT PULL] /dev/random driver fix for 4.8
From: Theodore Ts'o @ 2016-07-28 15:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, linux-crypto, heiko.carstens, schwidefsky
The following changes since commit 86a574de4590ffe6fd3f3ca34cdcf655a78e36ec:
random: strengthen input validation for RNDADDTOENTCNT (2016-07-03 17:09:33 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random.git tags/random_for_linus_stable
for you to fetch changes up to 59b8d4f1f5d26e4ca92172ff6dcd1492cdb39613:
random: use for_each_online_node() to iterate over NUMA nodes (2016-07-27 23:30:25 -0400)
----------------------------------------------------------------
Fix a boot failure on systems with non-contiguous NUMA id's.
----------------------------------------------------------------
Theodore Ts'o (1):
random: use for_each_online_node() to iterate over NUMA nodes
drivers/char/random.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
^ permalink raw reply
* Re: [PATCH] crypto: marvell: Don't copy IV vectors from the _process op for ciphers
From: Boris Brezillon @ 2016-07-28 10:09 UTC (permalink / raw)
To: Romain Perier
Cc: Arnaud Ebalard, David S. Miller, linux-crypto, Thomas Petazzoni,
Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory Clement
In-Reply-To: <1469699983-21370-1-git-send-email-romain.perier@free-electrons.com>
On Thu, 28 Jul 2016 11:59:43 +0200
Romain Perier <romain.perier@free-electrons.com> wrote:
> The IV output vectors should only be copied from the _complete operation
> and not from the _process operation, i.e only from the operation that is
> designed to copy the result of the request to the right location. This
> copy is already done in the _complete operation, so this commit removes
> the duplicated code in the _process op.
>
> Fixes: 3610d6cd5231 ("crypto: marvell - Add a complete...")
> Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> ---
> drivers/crypto/marvell/cipher.c | 11 +----------
> 1 file changed, 1 insertion(+), 10 deletions(-)
>
> diff --git a/drivers/crypto/marvell/cipher.c b/drivers/crypto/marvell/cipher.c
> index 8391aba..d19dc96 100644
> --- a/drivers/crypto/marvell/cipher.c
> +++ b/drivers/crypto/marvell/cipher.c
> @@ -139,20 +139,11 @@ static int mv_cesa_ablkcipher_process(struct crypto_async_request *req,
> struct ablkcipher_request *ablkreq = ablkcipher_request_cast(req);
> struct mv_cesa_ablkcipher_req *creq = ablkcipher_request_ctx(ablkreq);
> struct mv_cesa_req *basereq = &creq->base;
> - unsigned int ivsize;
> - int ret;
>
> if (mv_cesa_req_get_type(basereq) == CESA_STD_REQ)
> return mv_cesa_ablkcipher_std_process(ablkreq, status);
>
> - ret = mv_cesa_dma_process(basereq, status);
> - if (ret)
> - return ret;
> -
> - ivsize = crypto_ablkcipher_ivsize(crypto_ablkcipher_reqtfm(ablkreq));
> - memcpy_fromio(ablkreq->info, basereq->chain.last->data, ivsize);
> -
> - return 0;
> + return mv_cesa_dma_process(basereq, status);
> }
>
> static void mv_cesa_ablkcipher_step(struct crypto_async_request *req)
^ permalink raw reply
* [PATCH] crypto: marvell: Don't copy IV vectors from the _process op for ciphers
From: Romain Perier @ 2016-07-28 9:59 UTC (permalink / raw)
To: Boris Brezillon, Arnaud Ebalard
Cc: David S. Miller, linux-crypto, Thomas Petazzoni, Jason Cooper,
Andrew Lunn, Sebastian Hesselbarth, Gregory Clement
The IV output vectors should only be copied from the _complete operation
and not from the _process operation, i.e only from the operation that is
designed to copy the result of the request to the right location. This
copy is already done in the _complete operation, so this commit removes
the duplicated code in the _process op.
Fixes: 3610d6cd5231 ("crypto: marvell - Add a complete...")
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
---
drivers/crypto/marvell/cipher.c | 11 +----------
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/crypto/marvell/cipher.c b/drivers/crypto/marvell/cipher.c
index 8391aba..d19dc96 100644
--- a/drivers/crypto/marvell/cipher.c
+++ b/drivers/crypto/marvell/cipher.c
@@ -139,20 +139,11 @@ static int mv_cesa_ablkcipher_process(struct crypto_async_request *req,
struct ablkcipher_request *ablkreq = ablkcipher_request_cast(req);
struct mv_cesa_ablkcipher_req *creq = ablkcipher_request_ctx(ablkreq);
struct mv_cesa_req *basereq = &creq->base;
- unsigned int ivsize;
- int ret;
if (mv_cesa_req_get_type(basereq) == CESA_STD_REQ)
return mv_cesa_ablkcipher_std_process(ablkreq, status);
- ret = mv_cesa_dma_process(basereq, status);
- if (ret)
- return ret;
-
- ivsize = crypto_ablkcipher_ivsize(crypto_ablkcipher_reqtfm(ablkreq));
- memcpy_fromio(ablkreq->info, basereq->chain.last->data, ivsize);
-
- return 0;
+ return mv_cesa_dma_process(basereq, status);
}
static void mv_cesa_ablkcipher_step(struct crypto_async_request *req)
--
2.8.1
^ permalink raw reply related
* Re: lib/mpi: BUG: sleeping function called from invalid context on next-20160726
From: Nicolai Stange @ 2016-07-28 7:40 UTC (permalink / raw)
To: Herbert Xu; +Cc: Nicolai Stange, linux-crypto, linux-kernel
In-Reply-To: <20160728052917.GA811@gondor.apana.org.au>
Herbert Xu <herbert@gondor.apana.org.au> writes:
> On Wed, Jul 27, 2016 at 11:05:05PM +0200, Nicolai Stange wrote:
>>
>> with linux-next-20160726, I get this:
>>
>> BUG: sleeping function called from invalid context at /mnt/scratch/nic/linux-next/mm/slab.h:388
>
> Does this patch help?
Yes, works like a charm now!
>> I would have sent a patch, but there is another point which puzzles me
>> in mpi_read_raw_from_sgl():
>>
>> [...]
>> const u8 *buff;
>> [...]
>> sg_miter_start(&miter, sgl, ents, SG_MITER_ATOMIC | SG_MITER_FROM_SG);
>>
>> lzeros = 0;
>> len = 0;
>> while (nbytes > 0) {
>> while (len && !*buff) {
>> lzeros++;
>> len--;
>> buff++;
>> }
>>
>>
>> Thus, buff isn't initialized before its first use? Or am I misreading
>> something here?
>
> On the first entry len is zero therefore we will go to the end of the
> loop and initialise buff.
Hah! Thanks, although being obvious, I didn't see this...
Thanks,
Nicolai
^ permalink raw reply
* Re: lib/mpi: BUG: sleeping function called from invalid context on next-20160726
From: Herbert Xu @ 2016-07-28 5:29 UTC (permalink / raw)
To: Nicolai Stange; +Cc: linux-crypto, linux-kernel
In-Reply-To: <87d1lyiygu.fsf@gmail.com>
On Wed, Jul 27, 2016 at 11:05:05PM +0200, Nicolai Stange wrote:
>
> with linux-next-20160726, I get this:
>
> BUG: sleeping function called from invalid context at /mnt/scratch/nic/linux-next/mm/slab.h:388
Does this patch help?
> I would have sent a patch, but there is another point which puzzles me
> in mpi_read_raw_from_sgl():
>
> [...]
> const u8 *buff;
> [...]
> sg_miter_start(&miter, sgl, ents, SG_MITER_ATOMIC | SG_MITER_FROM_SG);
>
> lzeros = 0;
> len = 0;
> while (nbytes > 0) {
> while (len && !*buff) {
> lzeros++;
> len--;
> buff++;
> }
>
>
> Thus, buff isn't initialized before its first use? Or am I misreading
> something here?
On the first entry len is zero therefore we will go to the end of the
loop and initialise buff. Anyway, it will no longer be as confusing
with this patch applied.
Thanks,
---8<---
Subject: lib/mpi: Fix SG miter leak
In mpi_read_raw_from_sgl we may leak the SG miter resouces after
reading the leading zeroes. This patch fixes this by stopping the
iteration once the leading zeroes have been read.
Fixes: 127827b9c295 ("lib/mpi: Do not do sg_virt")
Reported-by: Nicolai Stange <nicstange@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/lib/mpi/mpicoder.c b/lib/mpi/mpicoder.c
index c6272ae..5a0f75a 100644
--- a/lib/mpi/mpicoder.c
+++ b/lib/mpi/mpicoder.c
@@ -363,6 +363,9 @@ MPI mpi_read_raw_from_sgl(struct scatterlist *sgl, unsigned int nbytes)
lzeros = 0;
}
+ miter.consumed = lzeros;
+ sg_miter_stop(&miter);
+
nbytes -= lzeros;
nbits = nbytes * 8;
if (nbits > MAX_EXTERN_MPI_BITS) {
@@ -390,7 +393,10 @@ MPI mpi_read_raw_from_sgl(struct scatterlist *sgl, unsigned int nbytes)
z = BYTES_PER_MPI_LIMB - nbytes % BYTES_PER_MPI_LIMB;
z %= BYTES_PER_MPI_LIMB;
- for (;;) {
+ while (sg_miter_next(&miter)) {
+ buff = miter.addr;
+ len = miter.length;
+
for (x = 0; x < len; x++) {
a <<= 8;
a |= *buff++;
@@ -400,12 +406,6 @@ MPI mpi_read_raw_from_sgl(struct scatterlist *sgl, unsigned int nbytes)
}
}
z += x;
-
- if (!sg_miter_next(&miter))
- break;
-
- buff = miter.addr;
- len = miter.length;
}
return val;
--
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 related
* Re: [PATCH] crypto: marvell - Update cache with input sg only when it is unmapped
From: Herbert Xu @ 2016-07-28 5:21 UTC (permalink / raw)
To: Romain Perier
Cc: boris.brezillon, arno, davem, linux-crypto, thomas.petazzoni,
jason, andrew, sebastian.hesselbarth, gregory.clement
In-Reply-To: <1469195184-4700-1-git-send-email-romain.perier@free-electrons.com>
Romain Perier <romain.perier@free-electrons.com> wrote:
> So far, the cache of the ahash requests was updated from the 'complete'
> operation. This complete operation is called from mv_cesa_tdma_process
> before the cleanup operation, which means that the content of req->src
> can be read and copied when it is still mapped. This commit fixes the
> issue by moving this cache update from mv_cesa_ahash_complete to
> mv_cesa_ahash_req_cleanup, so the copy is done once the sglist is
> unmapped.
>
> Fixes: 1bf6682cb31d ("crypto: marvell - Add a complete operation for..")
> Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
Patch applied. 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] crypto: marvell - Don't chain at DMA level when backlog is disabled
From: Herbert Xu @ 2016-07-28 5:19 UTC (permalink / raw)
To: Romain Perier
Cc: boris.brezillon, arno, davem, linux-crypto, thomas.petazzoni,
jason, andrew, sebastian.hesselbarth, gregory.clement
In-Reply-To: <1469191255-17443-1-git-send-email-romain.perier@free-electrons.com>
Romain Perier <romain.perier@free-electrons.com> wrote:
> The flag CRYPTO_TFM_REQ_MAY_BACKLOG is optional and can be set from the
> user to put requests into the backlog queue when the main cryptographic
> queue is full. Before calling mv_cesa_tdma_chain we must check the value
> of the return status to be sure that the current request has been
> correctly queued or added to the backlog.
>
> Fixes: 85030c5168f1 ("crypto: marvell - Add support for chaining...")
> Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
Patch applied. 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] crypto: marvell - Fix memory leaks in TDMA chain for cipher requests
From: Herbert Xu @ 2016-07-28 5:18 UTC (permalink / raw)
To: Romain Perier
Cc: boris.brezillon, arno, davem, linux-crypto, thomas.petazzoni,
jason, andrew, sebastian.hesselbarth, gregory.clement
In-Reply-To: <1469191239-17296-1-git-send-email-romain.perier@free-electrons.com>
Romain Perier <romain.perier@free-electrons.com> wrote:
> So far in mv_cesa_ablkcipher_dma_req_init, if an error is thrown while
> the tdma chain is built there is a memory leak. This issue exists
> because the chain is assigned later at the end of the function, so the
> cleanup function is called with the wrong version of the chain.
>
> Fixes: db509a45339f ("crypto: marvell/cesa - add TDMA support")
> Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
Patch applied. 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
* Loan Offer
From: Quick Loans @ 2016-07-28 1:33 UTC (permalink / raw)
To: Recipients
Instant cash Loan with same day payout on all kinds of Loan are available at Quick Financial Home were loan is offered at 2% per annul.
^ permalink raw reply
* Re: [GIT PULL] /dev/random driver changes for 4.8
From: Linus Torvalds @ 2016-07-27 22:05 UTC (permalink / raw)
To: Theodore Ts'o, Linus Torvalds, Linux Kernel Mailing List,
Linux Crypto Mailing List
In-Reply-To: <20160727131237.GF9284@thunk.org>
On Wed, Jul 27, 2016 at 6:12 AM, Theodore Ts'o <tytso@mit.edu> wrote:
>
> Are you planning on pulling the random tree this cycle? I'm not sure
> if you wanted to let it soak for a few days in linux-next, or whether
> you want to wait another full release cycle
It's next in line in my queue, so unless it blows up spectacularly in
my face I'm pulling it this cycle. It's not liek the pull request
looks particularly scary,
Linus
^ permalink raw reply
* lib/mpi: BUG: sleeping function called from invalid context on next-20160726
From: Nicolai Stange @ 2016-07-27 21:05 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto, linux-kernel, Nicolai Stange
Hi,
with linux-next-20160726, I get this:
BUG: sleeping function called from invalid context at /mnt/scratch/nic/linux-next/mm/slab.h:388
in_atomic(): 1, irqs_disabled(): 0, pid: 369, name: systemd-udevd
no locks held by systemd-udevd/369.
CPU: 2 PID: 369 Comm: systemd-udevd Not tainted 4.7.0-rc1+ #248
Hardware name: Dell Inc. Latitude E6540/0725FP, BIOS A10 06/26/2014
0000000000000286 00000000899a9b52 ffff88003f53b8f8 ffffffff814472d5
ffff8800c0752680 ffffffff81c557d8 ffff88003f53b920 ffffffff810dfba9
ffffffff81c557d8 0000000000000184 0000000000000000 ffff88003f53b948
Call Trace:
[<ffffffff814472d5>] dump_stack+0x86/0xc1
[<ffffffff810dfba9>] ___might_sleep+0x179/0x230
[<ffffffff810dfca9>] __might_sleep+0x49/0x80
[<ffffffff8125f1f1>] kmem_cache_alloc_trace+0x1d1/0x2e0
[<ffffffff81479b20>] ? mpi_alloc+0x20/0x80
[<ffffffff81479b20>] mpi_alloc+0x20/0x80
[<ffffffff81477475>] mpi_read_raw_from_sgl+0xd5/0x1e0
[<ffffffff813e99f6>] rsa_verify+0x66/0x100
[<ffffffff813ea1be>] pkcs1pad_verify+0xae/0xf0
[<ffffffff81404889>] public_key_verify_signature+0x1f9/0x290
[<ffffffff81404935>] public_key_verify_signature_2+0x15/0x20
[<ffffffff8140458c>] verify_signature+0x3c/0x50
[<ffffffff8140680d>] pkcs7_validate_trust+0x11d/0x230
[<ffffffff811eb132>] verify_pkcs7_signature+0xa2/0x150
[<ffffffff8115747d>] mod_verify_sig+0xdd/0x130
[<ffffffff811541cc>] load_module+0x16c/0x2970
[<ffffffff8128b95b>] ? vfs_read+0x11b/0x130
[<ffffffff81292342>] ? kernel_read_file+0x152/0x170
[<ffffffff81156c66>] SYSC_finit_module+0xe6/0x120
[<ffffffff81156cbe>] SyS_finit_module+0xe/0x10
[<ffffffff81003fe7>] do_syscall_64+0x67/0x190
[<ffffffff8189ab3f>] entry_SYSCALL64_slow_path+0x25/0x25
Reason is 127827b9c295 ("lib/mpi: Do not do sg_virt") which makes
mpi_read_raw_from_sgl() calling mpi_alloc() while having a sg entry
mapped via kmap_atomic() and thus, preemption disabled.
I would have sent a patch, but there is another point which puzzles me
in mpi_read_raw_from_sgl():
[...]
const u8 *buff;
[...]
sg_miter_start(&miter, sgl, ents, SG_MITER_ATOMIC | SG_MITER_FROM_SG);
lzeros = 0;
len = 0;
while (nbytes > 0) {
while (len && !*buff) {
lzeros++;
len--;
buff++;
}
Thus, buff isn't initialized before its first use? Or am I misreading
something here?
Thanks,
Nicolai
^ permalink raw reply
* Re: [GIT PULL] /dev/random driver changes for 4.8
From: Theodore Ts'o @ 2016-07-27 13:12 UTC (permalink / raw)
To: Linus Torvalds, linux-kernel, linux-crypto
In-Reply-To: <20160725064424.GA29098@thunk.org>
On Mon, Jul 25, 2016 at 02:44:24AM -0400, Theodore Ts'o wrote:
> The following changes since commit 1a695a905c18548062509178b98bc91e67510864:
>
> Linux 4.7-rc1 (2016-05-29 09:29:24 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random.git tags/random_for_linus
>
> for you to fetch changes up to 86a574de4590ffe6fd3f3ca34cdcf655a78e36ec:
>
> random: strengthen input validation for RNDADDTOENTCNT (2016-07-03 17:09:33 -0400)
Hi Linus,
Are you planning on pulling the random tree this cycle? I'm not sure
if you wanted to let it soak for a few days in linux-next, or whether
you want to wait another full release cycle, given that the random
tree had gotten dropped from linux-next some time ago without my
realizing it. (The code has actually been soaking for 1.5 releases,
since I wanted to give it lots of soak time, but of course, it would
have been more helpful if it actually was in linux-next. Sigh...)
- Ted
^ permalink raw reply
* Re: [PATCH] DH support: add KDF handling support
From: Stephan Mueller @ 2016-07-27 9:11 UTC (permalink / raw)
To: David Howells; +Cc: Mat Martineau, keyrings, linux-crypto
In-Reply-To: <9263.1469606131@warthog.procyon.org.uk>
Am Mittwoch, 27. Juli 2016, 08:55:31 CEST schrieb David Howells:
Hi David,
> Mat Martineau <mathew.j.martineau@linux.intel.com> wrote:
> > > Though, shall I stuff the wrapper code back into the existing dh_compute
> > > functions or can I leave them as separate functions?
> >
> > I'm not sure. In the existing code there's one keyctl wrapper per keyctl
> > command. A combined wrapper would need some extra logic to decide whether
> > kdfparams is passed in or not, which is different from existing code.
>
> You shouldn't change the existing keyctl wrappers. Feel free to add another
> one with extra arguments.
I created dh_compute_kdf and dh_compute_kdf_oi where the latter takes the
other information from STDIN.
>
> David
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH] DH support: add KDF handling support
From: David Howells @ 2016-07-27 7:55 UTC (permalink / raw)
To: Mat Martineau; +Cc: dhowells, Stephan Mueller, keyrings, linux-crypto
In-Reply-To: <alpine.OSX.2.20.1607141618170.69287@istotlan-mobl1.amr.corp.intel.com>
Mat Martineau <mathew.j.martineau@linux.intel.com> wrote:
> > Though, shall I stuff the wrapper code back into the existing dh_compute
> > functions or can I leave them as separate functions?
>
> I'm not sure. In the existing code there's one keyctl wrapper per keyctl
> command. A combined wrapper would need some extra logic to decide whether
> kdfparams is passed in or not, which is different from existing code.
You shouldn't change the existing keyctl wrappers. Feel free to add another
one with extra arguments.
David
^ permalink raw reply
* [PATCH 10/10] crypto: ccp - Enable use of the additional CCP
From: Gary R Hook @ 2016-07-27 0:10 UTC (permalink / raw)
To: linux-crypto; +Cc: thomas.lendacky, herbert, davem
In-Reply-To: <20160727000652.24944.44919.stgit@taos>
A second CCP is available, identical to the first, with
its ownn PCI ID. Make it available for use by the crypto
subsystem, as well as for DMA activity and random
number generation.
This device is not pre-configured at at boot time. The
driver must configure it (during the probe) for use.
Signed-off-by: Gary R Hook <gary.hook@amd.com>
---
drivers/crypto/ccp/ccp-dev-v5.c | 37 ++++++++++++++++++++++++++++++++++++-
drivers/crypto/ccp/ccp-dev.h | 8 ++++++++
drivers/crypto/ccp/ccp-pci.c | 2 ++
3 files changed, 46 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/ccp/ccp-dev-v5.c b/drivers/crypto/ccp/ccp-dev-v5.c
index 4086714..f499e34 100644
--- a/drivers/crypto/ccp/ccp-dev-v5.c
+++ b/drivers/crypto/ccp/ccp-dev-v5.c
@@ -835,7 +835,7 @@ static int ccp5_init(struct ccp_device *ccp)
/* Register the DMA engine support */
ret = ccp_dmaengine_register(ccp);
if (ret)
- goto e_hwrng;
+ goto e_kthread;
return 0;
@@ -952,6 +952,33 @@ static void ccp5_config(struct ccp_device *ccp)
iowrite32(0x00001249, ccp->io_regs + CMD5_REQID_CONFIG_OFFSET);
}
+static void ccp5other_config(struct ccp_device *ccp)
+{
+ int i;
+ u32 rnd;
+
+ /* We own all of the queues on the NTB CCP */
+
+ iowrite32(0x00012D57, ccp->io_regs + CMD5_TRNG_CTL_OFFSET);
+ iowrite32(0x00000003, ccp->io_regs + CMD5_CONFIG_0_OFFSET);
+ for (i = 0; i < 12; i++) {
+ rnd = ioread32(ccp->io_regs + TRNG_OUT_REG);
+ iowrite32(rnd, ccp->io_regs + CMD5_AES_MASK_OFFSET);
+ }
+
+ iowrite32(0x0000001F, ccp->io_regs + CMD5_QUEUE_MASK_OFFSET);
+ iowrite32(0x00005B6D, ccp->io_regs + CMD5_QUEUE_PRIO_OFFSET);
+ iowrite32(0x00000000, ccp->io_regs + CMD5_CMD_TIMEOUT_OFFSET);
+
+ iowrite32(0x3FFFFFFF, ccp->io_regs + LSB_PRIVATE_MASK_LO_OFFSET);
+ iowrite32(0x000003FF, ccp->io_regs + LSB_PRIVATE_MASK_HI_OFFSET);
+
+ iowrite32(0x00108823, ccp->io_regs + CMD5_CLK_GATE_CTL_OFFSET);
+
+ ccp5_config(ccp);
+}
+
+/* Version 5 adds some function, but is essentially the same as v5 */
static const struct ccp_actions ccp5_actions = {
.aes = ccp5_perform_aes,
.xts_aes = ccp5_perform_xts_aes,
@@ -974,3 +1001,11 @@ struct ccp_vdata ccpv5 = {
.bar = 2,
.offset = 0x0,
};
+
+struct ccp_vdata ccpv5other = {
+ .version = CCP_VERSION(5, 0),
+ .setup = ccp5other_config,
+ .perform = &ccp5_actions,
+ .bar = 2,
+ .offset = 0x0,
+};
diff --git a/drivers/crypto/ccp/ccp-dev.h b/drivers/crypto/ccp/ccp-dev.h
index d04bd61..ebc9365 100644
--- a/drivers/crypto/ccp/ccp-dev.h
+++ b/drivers/crypto/ccp/ccp-dev.h
@@ -63,7 +63,9 @@
/* ------------------------ CCP Version 5 Specifics ------------------------ */
#define CMD5_QUEUE_MASK_OFFSET 0x00
+#define CMD5_QUEUE_PRIO_OFFSET 0x04
#define CMD5_REQID_CONFIG_OFFSET 0x08
+#define CMD5_CMD_TIMEOUT_OFFSET 0x10
#define LSB_PUBLIC_MASK_LO_OFFSET 0x18
#define LSB_PUBLIC_MASK_HI_OFFSET 0x1C
#define LSB_PRIVATE_MASK_LO_OFFSET 0x20
@@ -83,6 +85,11 @@
#define CMD5_Q_ABORT_BASE 0x0114
#define CMD5_Q_AX_CACHE_BASE 0x0118
+#define CMD5_CONFIG_0_OFFSET 0x6000
+#define CMD5_TRNG_CTL_OFFSET 0x6008
+#define CMD5_AES_MASK_OFFSET 0x6010
+#define CMD5_CLK_GATE_CTL_OFFSET 0x603C
+
/* Address offset between two virtual queue registers */
#define CMD5_Q_STATUS_INCR 0x1000
@@ -634,5 +641,6 @@ struct ccp_vdata {
extern struct ccp_vdata ccpv3;
extern struct ccp_vdata ccpv5;
+extern struct ccp_vdata ccpv5other;
#endif
diff --git a/drivers/crypto/ccp/ccp-pci.c b/drivers/crypto/ccp/ccp-pci.c
index 064e20f..239cbf2 100644
--- a/drivers/crypto/ccp/ccp-pci.c
+++ b/drivers/crypto/ccp/ccp-pci.c
@@ -232,6 +232,7 @@ static int ccp_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
if (ccp->vdata->setup)
ccp->vdata->setup(ccp);
+
ret = ccp->vdata->perform->init(ccp);
if (ret)
goto e_iomap;
@@ -325,6 +326,7 @@ static int ccp_pci_resume(struct pci_dev *pdev)
static const struct pci_device_id ccp_pci_table[] = {
{ PCI_VDEVICE(AMD, 0x1537), (kernel_ulong_t)&ccpv3 },
{ PCI_VDEVICE(AMD, 0x1456), (kernel_ulong_t)&ccpv5 },
+ { PCI_VDEVICE(AMD, 0x1468), (kernel_ulong_t)&ccpv5other },
/* Last entry must be zero */
{ 0, }
};
^ permalink raw reply related
* [PATCH 08/10] crypto: ccp - Add support for the RNG in a version 5 CCP
From: Gary R Hook @ 2016-07-27 0:10 UTC (permalink / raw)
To: linux-crypto; +Cc: thomas.lendacky, herbert, davem
In-Reply-To: <20160727000652.24944.44919.stgit@taos>
Signed-off-by: Gary R Hook <gary.hook@amd.com>
---
drivers/crypto/ccp/ccp-dev-v3.c | 13 ++++---------
drivers/crypto/ccp/ccp-dev-v5.c | 7 +++++++
drivers/crypto/ccp/ccp-dev.c | 23 +++++++++++++++++++++++
drivers/crypto/ccp/ccp-dev.h | 2 ++
4 files changed, 36 insertions(+), 9 deletions(-)
diff --git a/drivers/crypto/ccp/ccp-dev-v3.c b/drivers/crypto/ccp/ccp-dev-v3.c
index ff2d2a4..578522d 100644
--- a/drivers/crypto/ccp/ccp-dev-v3.c
+++ b/drivers/crypto/ccp/ccp-dev-v3.c
@@ -432,14 +432,9 @@ static int ccp_init(struct ccp_device *ccp)
dev_dbg(dev, "Registering device...\n");
ccp_add_device(ccp);
- /* Register the RNG */
- ccp->hwrng.name = ccp->rngname;
- ccp->hwrng.read = ccp_trng_read;
- ret = hwrng_register(&ccp->hwrng);
- if (ret) {
- dev_err(dev, "error registering hwrng (%d)\n", ret);
+ ret = ccp_register_rng(ccp);
+ if (ret)
goto e_kthread;
- }
/* Register the DMA engine support */
ret = ccp_dmaengine_register(ccp);
@@ -449,7 +444,7 @@ static int ccp_init(struct ccp_device *ccp)
return 0;
e_hwrng:
- hwrng_unregister(&ccp->hwrng);
+ ccp_unregister_rng(ccp);
e_kthread:
for (i = 0; i < ccp->cmd_q_count; i++)
@@ -475,7 +470,7 @@ static void ccp_destroy(struct ccp_device *ccp)
ccp_dmaengine_unregister(ccp);
/* Unregister the RNG */
- hwrng_unregister(&ccp->hwrng);
+ ccp_unregister_rng(ccp);
/* Remove this device from the list of available units */
ccp_del_device(ccp);
diff --git a/drivers/crypto/ccp/ccp-dev-v5.c b/drivers/crypto/ccp/ccp-dev-v5.c
index 16dad96..ddce220 100644
--- a/drivers/crypto/ccp/ccp-dev-v5.c
+++ b/drivers/crypto/ccp/ccp-dev-v5.c
@@ -828,6 +828,10 @@ static int ccp5_init(struct ccp_device *ccp)
/* Put this on the unit list to make it available */
ccp_add_device(ccp);
+ ret = ccp_register_rng(ccp);
+ if (ret)
+ goto e_kthread;
+
return 0;
e_kthread:
@@ -852,6 +856,9 @@ static void ccp5_destroy(struct ccp_device *ccp)
struct ccp_cmd *cmd;
unsigned int i;
+ /* Unregister the RNG */
+ ccp_unregister_rng(ccp);
+
/* Remove this device from the list of available units first */
ccp_del_device(ccp);
diff --git a/drivers/crypto/ccp/ccp-dev.c b/drivers/crypto/ccp/ccp-dev.c
index 6b44730..38a98d8 100644
--- a/drivers/crypto/ccp/ccp-dev.c
+++ b/drivers/crypto/ccp/ccp-dev.c
@@ -119,6 +119,29 @@ void ccp_del_device(struct ccp_device *ccp)
write_unlock_irqrestore(&ccp_unit_lock, flags);
}
+
+
+int ccp_register_rng(struct ccp_device *ccp)
+{
+ int ret = 0;
+
+ dev_dbg(ccp->dev, "Registering RNG...\n");
+ /* Register an RNG */
+ ccp->hwrng.name = ccp->rngname;
+ ccp->hwrng.read = ccp_trng_read;
+ ret = hwrng_register(&ccp->hwrng);
+ if (ret)
+ dev_err(ccp->dev, "error registering hwrng (%d)\n", ret);
+
+ return ret;
+}
+
+void ccp_unregister_rng(struct ccp_device *ccp)
+{
+ if (ccp->hwrng.name)
+ hwrng_unregister(&ccp->hwrng);
+}
+
static struct ccp_device *ccp_get_device(void)
{
unsigned long flags;
diff --git a/drivers/crypto/ccp/ccp-dev.h b/drivers/crypto/ccp/ccp-dev.h
index 5ff4a73..d04bd61 100644
--- a/drivers/crypto/ccp/ccp-dev.h
+++ b/drivers/crypto/ccp/ccp-dev.h
@@ -601,6 +601,8 @@ int ccp_trng_read(struct hwrng *rng, void *data, size_t max, bool wait);
int ccp_run_cmd(struct ccp_cmd_queue *cmd_q, struct ccp_cmd *cmd);
+int ccp_register_rng(struct ccp_device *ccp);
+void ccp_unregister_rng(struct ccp_device *ccp);
int ccp_dmaengine_register(struct ccp_device *ccp);
void ccp_dmaengine_unregister(struct ccp_device *ccp);
^ permalink raw reply related
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