hwrng: pseries - port to new read API and fix stack corruption

PATCH In review Greg Kurz 3 participants 5 messages Oct 31, 2014 – Nov 6, 2014

Subsystems (3)

Stable branch PowerPC Hardware random number generator core

lore

Share & tools

lore

Greg Kurz

author

2014-10-31 06:50 UTC #0 lore raw

PATCH 1/1 hwrng: pseries - port to new read API and fix stack corruption

The add_early_randomness() function in drivers/char/hw_random/core.c passes a 16-byte buffer to pseries_rng_data_read(). Unfortunately, plpar_hcall() returns four 64-bit values and trashes 16 bytes on the stack.

This bug has been lying around for a long time. It got unveiled by:

commit d3cc7996473a7bdd33256029988ea690754e4e2a

Author: Amit Shah <[email protected]>
Date:   Thu Jul 10 15:42:34 2014 +0530

hwrng: fetch randomness only after device init

It may trig a oops while loading or unloading the pseries-rng module for both PowerVM and PowerKVM guests.

This patch does two things:
- pass an intermediate well sized buffer to plpar_hcall(). This is acceptalbe since we're not on a hot path.
- move to the new read API so that we know the return buffer size for sure.

Signed-off-by Greg Kurz <[email protected]>

---

Cc'ing stable as I could reproduce back to 3.15.10

 drivers/char/hw_random/pseries-rng.c |   11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

drivers/char/hw_random/pseries-rng.c +7 -4

index 6226aa0..bcf86f9 100644
@@ -25,18 +25,21 @@
 #include <asm/vio.h>
 
 
-static int pseries_rng_data_read(struct hwrng *rng, u32 *data)
+static int pseries_rng_read(struct hwrng *rng, void *data, size_t max, bool wait)
 {
+	u64 buffer[PLPAR_HCALL_BUFSIZE];
+	size_t size = max < 8 ? max : 8;
 	int rc;
 
-	rc = plpar_hcall(H_RANDOM, (unsigned long *)data);
+	rc = plpar_hcall(H_RANDOM, (unsigned long *)buffer);
 	if (rc != H_SUCCESS) {
 		pr_err_ratelimited("H_RANDOM call failed %d\n", rc);
 		return -EIO;
 	}
+	memcpy(data, buffer, size);
 
 	/* The hypervisor interface returns 64 bits */
-	return 8;
+	return size;
 }
 
 /**

@@ -55,7 +58,7 @@ static unsigned long pseries_rng_get_desired_dma(struct vio_dev *vdev)
 
 static struct hwrng pseries_rng = {
 	.name		= KBUILD_MODNAME,
-	.data_read	= pseries_rng_data_read,
+	.read		= pseries_rng_read,
 };
 
 static int __init pseries_rng_probe(struct vio_dev *dev,

Michael Ellerman

reviewer

2014-10-31 07:00 UTC #1 lore raw

Quoted 3 lines · Greg Kurz

The add_early_randomness() function in drivers/char/hw_random/core.c passes a 16-byte buffer to pseries_rng_data_read(). Unfortunately, plpar_hcall() returns four 64-bit values and trashes 16 bytes on the stack.

Hmm, thanks. I thought I'd fixed that, but I guess I never sent the patch :}

Quoted 6 lines

This bug has been lying around for a long time. It got unveiled by:
commit d3cc7996473a7bdd33256029988ea690754e4e2a
Author: Amit Shah <[email protected]>
Date:   Thu Jul 10 15:42:34 2014 +0530

Quoted 8 lines

hwrng: fetch randomness only after device init
It may trig a oops while loading or unloading the pseries-rng module for both PowerVM and PowerKVM guests.
This patch does two things:
- pass an intermediate well sized buffer to plpar_hcall(). This is acceptalbe since we're not on a hot path.

Well probably, can you do a before and after test of dd if=/dev/hwrng ?

Quoted 1 line

Cc'ing stable as I could reproduce back to 3.15.10

The right way to CC stable for a patch that isn't yet in upstream is to add:

CC [email protected]

Before your Signed-off-by. They will then pick it up once it's merged into Linus' tree. See Documentation/stable_kernel_rules.txt

cheers

Greg Kurz

author

2014-10-31 09:31 UTC #2 lore raw

Quoted 7 lines · On Fri, 31 Oct 2014 18:00:12 +1100 Michael Ellerman <[email protected]> wrote:

Quoted 3 lines · Greg Kurz
The add_early_randomness() function in drivers/char/hw_random/core.c passes a 16-byte buffer to pseries_rng_data_read(). Unfortunately, plpar_hcall() returns four 64-bit values and trashes 16 bytes on the stack.
Hmm, thanks. I thought I'd fixed that, but I guess I never sent the patch :}

Heh so many patches ! :)

Quoted 8 lines

Quoted 8 lines
This bug has been lying around for a long time. It got unveiled by:
commit d3cc7996473a7bdd33256029988ea690754e4e2a
Author: Amit Shah <[email protected]>
Date:   Thu Jul 10 15:42:34 2014 +0530
hwrng: fetch randomness only after device init

Quoted 9 lines

Quoted 6 lines
It may trig a oops while loading or unloading the pseries-rng module for both PowerVM and PowerKVM guests.
This patch does two things:
- pass an intermediate well sized buffer to plpar_hcall(). This is acceptalbe since we're not on a hot path.
Well probably, can you do a before and after test of dd if=/dev/hwrng ?

I had to do this to be able to run the before test:

@@ -78,7 +78,7 @@ static size_t rng_buffer_size(void)

static void add_early_randomness(struct hwrng *rng) {
- unsigned char bytes[16];
+ unsigned char bytes[32];

I ran tests for 128 MB and 1G several times in a PowerKVM guest on a POWER8 box.

Before:

[root@fedora20-ppc64 ~]# time dd if=/dev/hwrng of=/dev/null bs=1024 count=131072 131072+0 records in
131072+0 records out
134217728 bytes (134 MB) copied, 17.0503 s, 7.9 MB/s

real    0m17.051s
user    0m0.024s
sys     0m16.797s

[root@fedora20-ppc64 ~]# time dd if=/dev/hwrng of=/dev/null bs=1024 count=1048576 1048576+0 records in
1048576+0 records out
1073741824 bytes (1.1 GB) copied, 136.374 s, 7.9 MB/s

real    2m16.376s
user    0m0.189s
sys     2m14.367s

After:

[root@fedora20-ppc64 ~]# time dd if=/dev/hwrng of=/dev/null bs=1024 count=131072 131072+0 records in
131072+0 records out
134217728 bytes (134 MB) copied, 17.0502 s, 7.9 MB/s

real    0m17.051s
user    0m0.024s
sys     0m16.797s

[root@fedora20-ppc64 ~]# time dd if=/dev/hwrng of=/dev/null bs=1024 count=1048576 1048576+0 records in
1048576+0 records out
1073741824 bytes (1.1 GB) copied, 136.432 s, 7.9 MB/s

real    2m16.433s
user    0m0.188s
sys     2m14.370s

It shows no degradation of performance.

Quoted 11 lines

Quoted 1 line
Cc'ing stable as I could reproduce back to 3.15.10
The right way to CC stable for a patch that isn't yet in upstream is to add:
CC [email protected]
Before your Signed-off-by. They will then pick it up once it's merged into Linus' tree. See Documentation/stable_kernel_rules.txt
cheers

Oops... should I repost then ?

Thanks.

--
Greg

Herbert Xu

maintainer

2014-10-31 09:36 UTC #3 lore raw

Quoted 7 lines · Greg Kurz

Quoted 7 lines
Quoted 2 lines
Cc'ing stable as I could reproduce back to 3.15.10
The right way to CC stable for a patch that isn't yet in upstream is to add:
CC [email protected]

Quoted 7 lines

Quoted 5 lines
Before your Signed-off-by. They will then pick it up once it's merged into Linus' tree. See Documentation/stable_kernel_rules.txt
cheers
Oops... should I repost then ?

Don't worry, I can fix this up.

Cheers,

Signature · 3 lines

Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Herbert Xu

maintainer

2014-11-06 15:13 UTC #4 lore raw

In reply to Greg Kurz

Quoted 15 lines · Greg Kurz

The add_early_randomness() function in drivers/char/hw_random/core.c passes a 16-byte buffer to pseries_rng_data_read(). Unfortunately, plpar_hcall() returns four 64-bit values and trashes 16 bytes on the stack.
This bug has been lying around for a long time. It got unveiled by:
commit d3cc7996473a7bdd33256029988ea690754e4e2a
Author: Amit Shah <[email protected]>
Date:   Thu Jul 10 15:42:34 2014 +0530
hwrng: fetch randomness only after device init
It may trig a oops while loading or unloading the pseries-rng module for both PowerVM and PowerKVM guests.

Quoted 6 lines

This patch does two things:
- pass an intermediate well sized buffer to plpar_hcall(). This is acceptalbe since we're not on a hot path.
- move to the new read API so that we know the return buffer size for sure.
Signed-off-by Greg Kurz <[email protected]>

Patch applied to crypto.

Thanks,

Signature · 3 lines

Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt