* [PATCH] hw_random: Improve description of the ->read() interface
From: Daniel Thompson @ 2016-08-18 12:37 UTC (permalink / raw)
To: Matt Mackall, Herbert Xu
Cc: Daniel Thompson, linux-crypto, linux-kernel, patches,
linaro-kernel, LABBE Corentin, PrasannaKumar Muralidharan
Currently, very few RNG drivers support single byte reads using the
->read() interface. Of the 14 drivers in drivers/char/hw_random that
support this interface only three of these actually support max == 1.
The other behaviours vary between return 0, return 2, return 4 and return
-EIO).
This is not a problem in practice because the core hw_random code never
performs a read shorter than 16 bytes. The documentation for this function
already contrains the alignment of the buffer pointer, so let's also
guarantee that the buffer is at least as large as its alignment.
This constraint is intended to be the weakest guarantee neccessary to
allow driver writers to safely simplify their code.
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
---
include/linux/hw_random.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/linux/hw_random.h b/include/linux/hw_random.h
index 4f7d8f4b1e9a..34a0dc18f327 100644
--- a/include/linux/hw_random.h
+++ b/include/linux/hw_random.h
@@ -29,7 +29,9 @@
* Returns the number of lower random bytes in "data".
* Must not be NULL. *OBSOLETE*
* @read: New API. drivers can fill up to max bytes of data
- * into the buffer. The buffer is aligned for any type.
+ * into the buffer. The buffer is aligned for any type
+ * and max is guaranteed to be >= to that alignment
+ * (either 4 or 8 depending on architecture).
* @priv: Private data, for use by the RNG driver.
* @quality: Estimation of true entropy in RNG's bitstream
* (per mill).
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v6 0/5] /dev/random - a new approach
From: Pavel Machek @ 2016-08-18 18:39 UTC (permalink / raw)
To: Theodore Ts'o, Stephan Mueller, herbert, sandyinchina,
Jason Cooper, John Denker, H. Peter Anvin, Joe Perches,
George Spelvin, linux-crypto, linux-kernel
In-Reply-To: <20160818172712.GA22054@thunk.org>
On Thu 2016-08-18 13:27:12, Theodore Ts'o wrote:
> On Wed, Aug 17, 2016 at 11:42:55PM +0200, Pavel Machek wrote:
> >
> > Actually.. I'm starting to believe that getting enough entropy before
> > userspace starts is more important than pretty much anything else.
> >
> > We only "need" 64-bits of entropy, AFAICT. If it passes statistical
> > tests, I'd use it... for initial bringup.
>
> Definitely not 64 bits. Back in *1996* the estimate was that we
> needed at least 75-bits in order to be protected against brute force
> attacks. It's been two *deacdes* years later, and granted Moore's law
> has ceased to apply in the last couple of years, but I'm sure 64 bits
> is not enough.
>
> What is your specific concern vis-a-vis when userspace starts? We now
> print a warning if someone tries to draw from /dev/urandom, and so it
> should be easy to see if someone is doing something dangerous. The
Well, warning is nice, but I'm afraid it is not going to stop everyone.
> have only been known cases (at last as far asI know where) where some
> software was doing something as *insane* as to create keys right out
> of the box was. One was ssh, and at least on a modern Debian system,
> that doesn't happen until fairly late in the process:
It is more widespread than that:
rapsberry pi:
https://www.raspberrypi.org/forums/viewtopic.php?t=126892
But this is the scary part. Not limited to ssh. "We perform the
largest ever network survey of TLS and SSH servers and present
evidence that vulnerable keys are surprisingly widespread. We find
that 0.75% of TLS certificates share keys due to insufficient entropy
during key generation, and we suspect that another 1.70% come from the
same faulty implementations and may be susceptible to compromise.
Even more alarmingly, we are able to obtain RSA private keys for 0.50%
of TLS hosts and 0.03% of SSH hosts, because their public keys shared
nontrivial common factors due to entropy problems, and DSA private
keys for 1.03% of SSH hosts, because of insufficient signature
randomness"
https://factorable.net/weakkeys12.conference.pdf
Responsible devices were Gigaset SX762, ADTran Total Access
businessgrade phone/network routers, IBM RSA II remote administration
cards, BladeCenter devices, Juniper Networks Branch SRX devices,
... "We used the techniques described in Section 3.2 to identify
apparently vulnerable devices from 27 manufacturers. These include
enterprise-grade routers from Cisco; server management cards from
Dell, Hewlett-Packard, and IBM; virtual-private-network (VPN) devices;
building security systems; network attached storage devices; and
several kinds of consumer routers and VoIP products."
> The other was HP, which was generating an RSA key very shortly after
> the first time the printer was powered on.
Its definitely more than two incidents.
> > We can switch to more conservative estimates when system is fully
> > running. But IMO it is very important to get _some_ randomness at the
> > begining...
>
> We're doing this already in the latest getrandom(2) implementation.
> For the purposes of initializing the crng, we assume that each
> interrupt has a single bit of entropy. So it requires 128 initerrupts
> for getrandom(2) to be fully initialized. I'm actually worried that
> this is too high as it is for architectures that don't have a
> fine-grained clock. Given that on many of these embedded platforms
> there is a oscillator which drives all of the clocks and subsystems,
> it just doesn't make *sense* that than each interrupt could result in
> 5-6 bits of entropy, no matter what a magical statistical formula
> might say.
>From my point of view, it would make sense to factor time from RTC and
mac addresses into the initial hash. Situation in the paper was so bad
some devices had _completely identical_ keys. We should be able to do
better than that.
BTW... 128 interrupts... that's 1.3 seconds, right? Would it make
sense to wait two seconds if urandom use is attempted before it is
ready?
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* [PATCH -next] crypto: fix missing unlock on error in sun4i_hash()
From: Wei Yongjun @ 2016-08-18 22:42 UTC (permalink / raw)
To: Corentin Labbe, Herbert Xu, David S. Miller, Maxime Ripard,
Chen-Yu Tsai
Cc: Wei Yongjun, linux-crypto, linux-arm-kernel
Add the missing unlock before return from function sun4i_hash()
in the error handling case.
Fixes: 477d9b2e591b ("crypto: sun4i-ss - unify update/final function")
Signed-off-by: Wei Yongjun <weiyj.lk@gmail.com>
---
drivers/crypto/sunxi-ss/sun4i-ss-hash.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-hash.c b/drivers/crypto/sunxi-ss/sun4i-ss-hash.c
index 2ee3b59..de66f47 100644
--- a/drivers/crypto/sunxi-ss/sun4i-ss-hash.c
+++ b/drivers/crypto/sunxi-ss/sun4i-ss-hash.c
@@ -245,6 +245,7 @@ int sun4i_hash(struct ahash_request *areq)
if (end > areq->nbytes || areq->nbytes - end > 63) {
dev_err(ss->dev, "ERROR: Bound error %u %u\n",
end, areq->nbytes);
+ spin_unlock(&ss->slock);
return -EINVAL;
}
} else {
^ permalink raw reply related
* Re: [PATCH] Add Ingenic JZ4780 hardware RNG driver
From: Rob Herring @ 2016-08-19 0:59 UTC (permalink / raw)
To: PrasannaKumar Muralidharan
Cc: mpm, herbert, mark.rutland, ralf, davem, geert, akpm, gregkh,
mchehab, linux, boris.brezillon, harvey.hunt, alex.smith,
daniel.thompson, lee.jones, f.fainelli, kieran, krzk,
joshua.henderson, yendapally.reddy, narmstrong, wangkefeng.wang,
chunkeey, noltari, linus.walleij, pankaj.dev, mathieu.poirier,
linux-crypto, devicetree, linux-kernel, linux-mips
In-Reply-To: <1471448151-20850-1-git-send-email-prasannatsmkumar@gmail.com>
On Wed, Aug 17, 2016 at 09:05:51PM +0530, PrasannaKumar Muralidharan wrote:
> This patch adds support for hardware random number generator present in
> JZ4780 SoC.
>
> Signed-off-by: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
> ---
> .../devicetree/bindings/rng/ingenic,jz4780-rng.txt | 12 +++
Acked-by: Rob Herring <robh@kernel.org>
> MAINTAINERS | 5 +
> arch/mips/boot/dts/ingenic/jz4780.dtsi | 7 +-
> drivers/char/hw_random/Kconfig | 14 +++
> drivers/char/hw_random/Makefile | 1 +
> drivers/char/hw_random/jz4780-rng.c | 105 +++++++++++++++++++++
> 6 files changed, 143 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/rng/ingenic,jz4780-rng.txt
> create mode 100644 drivers/char/hw_random/jz4780-rng.c
^ permalink raw reply
* Re: [PATCH v6 0/5] /dev/random - a new approach
From: Theodore Ts'o @ 2016-08-18 17:27 UTC (permalink / raw)
To: Pavel Machek
Cc: Stephan Mueller, herbert, sandyinchina, Jason Cooper, John Denker,
H. Peter Anvin, Joe Perches, George Spelvin, linux-crypto,
linux-kernel
In-Reply-To: <20160817214254.GA22438@amd>
On Wed, Aug 17, 2016 at 11:42:55PM +0200, Pavel Machek wrote:
>
> Actually.. I'm starting to believe that getting enough entropy before
> userspace starts is more important than pretty much anything else.
>
> We only "need" 64-bits of entropy, AFAICT. If it passes statistical
> tests, I'd use it... for initial bringup.
Definitely not 64 bits. Back in *1996* the estimate was that we
needed at least 75-bits in order to be protected against brute force
attacks. It's been two *deacdes* years later, and granted Moore's law
has ceased to apply in the last couple of years, but I'm sure 64 bits
is not enough.
What is your specific concern vis-a-vis when userspace starts? We now
print a warning if someone tries to draw from /dev/urandom, and so it
should be easy to see if someone is doing something dangerous. The
have only been known cases (at last as far asI know where) where some
software was doing something as *insane* as to create keys right out
of the box was. One was ssh, and at least on a modern Debian system,
that doesn't happen until fairly late in the process:
% systemd-analyze critical-chain ssh.service
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.
ssh.service +888ms
└─network.target @31.473s
└─wpa_supplicant.service @32.958s +770ms
└─basic.target @19.479s
└─sockets.target @19.479s
└─acpid.socket @19.479s
└─sysinit.target @19.414s
└─systemd-timesyncd.service @18.079s +1.330s
└─systemd-tmpfiles-setup.service @17.512s +78ms
└─local-fs.target @17.501s
└─run-user-15806.mount @43.047s
└─local-fs-pre.target @16.616s
└─systemd-tmpfiles-setup-dev.service @755ms +930ms
└─kmod-static-nodes.service @729ms +17ms
└─system.slice @653ms
└─-.slice @608ms
The other was HP, which was generating an RSA key very shortly after
the first time the printer was powered on.
> We can switch to more conservative estimates when system is fully
> running. But IMO it is very important to get _some_ randomness at the
> begining...
We're doing this already in the latest getrandom(2) implementation.
For the purposes of initializing the crng, we assume that each
interrupt has a single bit of entropy. So it requires 128 initerrupts
for getrandom(2) to be fully initialized. I'm actually worried that
this is too high as it is for architectures that don't have a
fine-grained clock. Given that on many of these embedded platforms
there is a oscillator which drives all of the clocks and subsystems,
it just doesn't make *sense* that than each interrupt could result in
5-6 bits of entropy, no matter what a magical statistical formula
might say.
(Creation of some completely determinsitic sequences that cause the
magical statistcal formulas to claim a vast number of entropy bits is
left as an exercise to the reader.)
Cheers,
- Ted
^ permalink raw reply
* [PATCH] crypto: qat - fix aes-xts key sizes
From: Giovanni Cabiddu @ 2016-08-18 18:53 UTC (permalink / raw)
To: herbert; +Cc: linux-crypto, Giovanni Cabiddu
Increase value of supported key sizes for qat_aes_xts.
aes-xts keys consists of keys of equal size concatenated.
Reported-by: Wenqian Yu <wenqian.yu@intel.com>
Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
---
drivers/crypto/qat/qat_common/qat_algs.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/qat/qat_common/qat_algs.c b/drivers/crypto/qat/qat_common/qat_algs.c
index 769148d..20f35df 100644
--- a/drivers/crypto/qat/qat_common/qat_algs.c
+++ b/drivers/crypto/qat/qat_common/qat_algs.c
@@ -1260,8 +1260,8 @@ static struct crypto_alg qat_algs[] = { {
.setkey = qat_alg_ablkcipher_xts_setkey,
.decrypt = qat_alg_ablkcipher_decrypt,
.encrypt = qat_alg_ablkcipher_encrypt,
- .min_keysize = AES_MIN_KEY_SIZE,
- .max_keysize = AES_MAX_KEY_SIZE,
+ .min_keysize = 2 * AES_MIN_KEY_SIZE,
+ .max_keysize = 2 * AES_MAX_KEY_SIZE,
.ivsize = AES_BLOCK_SIZE,
},
},
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH v6 0/5] /dev/random - a new approach
From: Theodore Ts'o @ 2016-08-19 2:49 UTC (permalink / raw)
To: Pavel Machek
Cc: Stephan Mueller, herbert, sandyinchina, Jason Cooper, John Denker,
H. Peter Anvin, Joe Perches, George Spelvin, linux-crypto,
linux-kernel
In-Reply-To: <20160818183923.GA24817@amd>
On Thu, Aug 18, 2016 at 08:39:23PM +0200, Pavel Machek wrote:
>
> But this is the scary part. Not limited to ssh. "We perform the
> largest ever network survey of TLS and SSH servers and present
> evidence that vulnerable keys are surprisingly widespread. We find
> that 0.75% of TLS certificates share keys due to insufficient entropy
> during key generation, and we suspect that another 1.70% come from the
> same faulty implementations and may be susceptible to compromise.
> Even more alarmingly, we are able to obtain RSA private keys for 0.50%
> of TLS hosts and 0.03% of SSH hosts, because their public keys shared
> nontrivial common factors due to entropy problems, and DSA private
> keys for 1.03% of SSH hosts, because of insufficient signature
> randomness"
>
> https://factorable.net/weakkeys12.conference.pdf
That's a very old paper, and we've made a lot of changes since then.
Before that we weren't accumulating entropy from the interrupt
handler, but only from spinning disk drives, some network interrupts
(but not from all NIC's; it was quite arbitrary), and keyboard and
mouse interrupts. So hours and hours could go by and you still
wouldn't have accumulated much entropy.
> From my point of view, it would make sense to factor time from RTC and
> mac addresses into the initial hash. Situation in the paper was so bad
> some devices had _completely identical_ keys. We should be able to do
> better than that.
We fixed that **years** ago. In fact, the authors shared with me an
early look at that paper and I implemented add_device_entropy() over
the July 4th weekend back in 2012. So we are indeed mixing in MAC
addresses and the hardware clock (if it is initialized that early).
In fact that was one of the first things that I did. Note that this
doesn't really add much entropy, but it does prevent the GCD attack
from demonstrating completely identical keys. Hence, we had
remediations in the mainline kernel before the factorable.net paper
was published (not that really helped with devices with embedded
Linux, especially since device manufactures don't see anything wrong
with shipping machines with kernels that are years and years out of
date --- OTOH, these systems were probably also shipping with dozens
of known exploitable holes in userspace, if that's any comfort.
Probably not much if you were planning on deploying lots of IOT
devices in your home network. :-)
> BTW... 128 interrupts... that's 1.3 seconds, right? Would it make
> sense to wait two seconds if urandom use is attempted before it is
> ready?
That really depends on the system. We can't assume that people are
using systems with a 100Hz clock interrupt. More often than not
people are using tickless kernels these days. That's actually the
problem with changing /dev/urandom to block until things are
initialized.
If you do that, then on some system Python will use /dev/urandom to
initialize a salt used by the Python dictionaries, to protect against
DOS attacks when Python is used to run web scripts. This is a
completely irrelevant reason when Python is being used for systemd
generator scripts in early boot, and if /dev/urandom were to block,
then the system ends up doing nothing, and on a tickless kernels hours
and hours can go by on a VM and Python would still be blocked on
/dev/urandom. And since none of the system scripts are running, there
are no interrupts, and so Python ends up blocking on /dev/urandom for
a very long time. (Eventually someone will start trying to brute
force passwords on the VM's ssh port, assuming that the VM's firewall
rules allow this, and that will cause interrupts that will eventually
initialize /dev/urandom. But that could take hours.)
And this, boys and girls, is why we can't make /dev/urandom block
until its pool is initialized. There's too great of a chance that we
will break userspace, and then Linus will yell at us and revert the
commit.
- Ted
^ permalink raw reply
* Re: [PATCH -next] crypto: fix missing unlock on error in sun4i_hash()
From: Corentin LABBE @ 2016-08-19 5:40 UTC (permalink / raw)
To: Wei Yongjun, Herbert Xu, David S. Miller, Maxime Ripard,
Chen-Yu Tsai
Cc: linux-crypto, linux-arm-kernel
In-Reply-To: <1471560130-5265-1-git-send-email-weiyj.lk@gmail.com>
On 19/08/2016 00:42, Wei Yongjun wrote:
> Add the missing unlock before return from function sun4i_hash()
> in the error handling case.
>
> Fixes: 477d9b2e591b ("crypto: sun4i-ss - unify update/final function")
> Signed-off-by: Wei Yongjun <weiyj.lk@gmail.com>
> ---
> drivers/crypto/sunxi-ss/sun4i-ss-hash.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-hash.c b/drivers/crypto/sunxi-ss/sun4i-ss-hash.c
> index 2ee3b59..de66f47 100644
> --- a/drivers/crypto/sunxi-ss/sun4i-ss-hash.c
> +++ b/drivers/crypto/sunxi-ss/sun4i-ss-hash.c
> @@ -245,6 +245,7 @@ int sun4i_hash(struct ahash_request *areq)
> if (end > areq->nbytes || areq->nbytes - end > 63) {
> dev_err(ss->dev, "ERROR: Bound error %u %u\n",
> end, areq->nbytes);
> + spin_unlock(&ss->slock);
> return -EINVAL;
> }
> } else {
>
Hello
Thanks for the finding, but it is better in that case to use the goto release_ss since it need also to stop the device.
Regards
LABBE Corentin
^ permalink raw reply
* Re: [PATCH v6 0/5] /dev/random - a new approach
From: Herbert Xu @ 2016-08-19 5:56 UTC (permalink / raw)
To: Theodore Ts'o, Pavel Machek, Stephan Mueller, sandyinchina,
Jason Cooper, John Denker, H. Peter Anvin, Joe Perches,
George Spelvin, linux-crypto, linux-kernel
In-Reply-To: <20160819024947.GA10888@thunk.org>
On Thu, Aug 18, 2016 at 10:49:47PM -0400, Theodore Ts'o wrote:
>
> That really depends on the system. We can't assume that people are
> using systems with a 100Hz clock interrupt. More often than not
> people are using tickless kernels these days. That's actually the
> problem with changing /dev/urandom to block until things are
> initialized.
Couldn't we disable tickless until urandom has been seeded? In fact
perhaps we should accelerate the timer interrupt rate until it has
been seeded?
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: [PATCHv3 net-next 0/4] crypto/chcr: Add support for Chelsio Crypto Driver
From: David Miller @ 2016-08-19 6:11 UTC (permalink / raw)
To: hariprasad
Cc: netdev, linux-crypto, herbert, atul.gupta, yeshaswi, jlulla,
harsh
In-Reply-To: <1471417386-14026-1-git-send-email-hariprasad@chelsio.com>
From: Hariprasad Shenai <hariprasad@chelsio.com>
Date: Wed, 17 Aug 2016 12:33:02 +0530
> This patch series adds support for Chelsio Crypto driver.
Herbert, what do you want to do with this? I can push it via
net-next if you like.
^ permalink raw reply
* Re: [PATCHv3 net-next 3/4] chcr: Support for Chelsio's Crypto Hardware
From: Herbert Xu @ 2016-08-19 6:15 UTC (permalink / raw)
To: Hariprasad Shenai
Cc: netdev, linux-crypto, davem, atul.gupta, yeshaswi, jlulla, harsh
In-Reply-To: <1471417386-14026-4-git-send-email-hariprasad@chelsio.com>
On Wed, Aug 17, 2016 at 12:33:05PM +0530, Hariprasad Shenai wrote:
> The Chelsio's Crypto Hardware can perform the following operations:
> SHA1, SHA224, SHA256, SHA384 and SHA512, HMAC(SHA1), HMAC(SHA224),
> HMAC(SHA256), HMAC(SHA384), HAMC(SHA512), AES-128-CBC, AES-192-CBC,
> AES-256-CBC, AES-128-XTS, AES-256-XTS
>
> This patch implements the driver for above mentioned features. This
> driver is an Upper Layer Driver which is attached to Chelsio's LLD
> (cxgb4) and uses the queue allocated by the LLD for sending the crypto
> requests to the Hardware and receiving the responses from it.
>
> The crypto operations can be performed by Chelsio's hardware from the
> userspace applications and/or from within the kernel space using the
> kernel's crypto API.
>
> The above mentioned crypto features have been tested using kernel's
> tests mentioned in testmgr.h. They also have been tested from user
> space using libkcapi and Openssl.
>
> Signed-off-by: Atul Gupta <atul.gupta@chelsio.com>
> Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
--
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: [PATCHv3 net-next 0/4] crypto/chcr: Add support for Chelsio Crypto Driver
From: Herbert Xu @ 2016-08-19 6:15 UTC (permalink / raw)
To: David Miller
Cc: hariprasad, netdev, linux-crypto, atul.gupta, yeshaswi, jlulla,
harsh
In-Reply-To: <20160818.231101.728993368913367217.davem@davemloft.net>
On Thu, Aug 18, 2016 at 11:11:01PM -0700, David Miller wrote:
> From: Hariprasad Shenai <hariprasad@chelsio.com>
> Date: Wed, 17 Aug 2016 12:33:02 +0530
>
> > This patch series adds support for Chelsio Crypto driver.
>
> Herbert, what do you want to do with this? I can push it via
> net-next if you like.
Sure thing, the crypto part looks good to me. Thanks Dave!
--
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: [PATCHv3 net-next 0/4] crypto/chcr: Add support for Chelsio Crypto Driver
From: David Miller @ 2016-08-19 7:01 UTC (permalink / raw)
To: herbert
Cc: hariprasad, netdev, linux-crypto, atul.gupta, yeshaswi, jlulla,
harsh
In-Reply-To: <20160819061543.GA20764@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Fri, 19 Aug 2016 14:15:43 +0800
> On Thu, Aug 18, 2016 at 11:11:01PM -0700, David Miller wrote:
>> From: Hariprasad Shenai <hariprasad@chelsio.com>
>> Date: Wed, 17 Aug 2016 12:33:02 +0530
>>
>> > This patch series adds support for Chelsio Crypto driver.
>>
>> Herbert, what do you want to do with this? I can push it via
>> net-next if you like.
>
> Sure thing, the crypto part looks good to me. Thanks Dave!
Great, done.
^ permalink raw reply
* Re: [PATCH v6 0/5] /dev/random - a new approach
From: Pavel Machek @ 2016-08-19 7:48 UTC (permalink / raw)
To: Theodore Ts'o, Stephan Mueller, herbert, sandyinchina,
Jason Cooper, John Denker, H. Peter Anvin, Joe Perches,
George Spelvin, linux-crypto, linux-kernel
In-Reply-To: <20160819024947.GA10888@thunk.org>
Hi!
> > From my point of view, it would make sense to factor time from RTC and
> > mac addresses into the initial hash. Situation in the paper was so bad
> > some devices had _completely identical_ keys. We should be able to do
> > better than that.
>
> We fixed that **years** ago. In fact, the authors shared with me an
> early look at that paper and I implemented add_device_entropy() over
> the July 4th weekend back in 2012. So we are indeed mixing in MAC
> addresses and the hardware clock (if it is initialized that early).
> In fact that was one of the first things that I did. Note that this
Ok, thanks.
> > BTW... 128 interrupts... that's 1.3 seconds, right? Would it make
> > sense to wait two seconds if urandom use is attempted before it is
> > ready?
>
> That really depends on the system. We can't assume that people are
> using systems with a 100Hz clock interrupt. More often than not
> people are using tickless kernels these days. That's actually the
> problem with changing /dev/urandom to block until things are
> initialized.
Ok, let me check:
config HZ_PERIODIC
config NO_HZ_IDLE
config NO_HZ_FULL
in HZ_PERIODIC, there should be no problem.
NO_HZ_IDLE... should not be a problem either. We can easily make sure
that cpu's are not idle, something like
while (not_enough_entropy())
schedule()
NO_HZ_FULL.... first, help text seems to imply that timer ticks still
happen when cpu is in kernel, and second, there is always one CPU that
handles timer ticks. So we are still ok.
So I believe we should add the wait to urandom. One second delay in
rare cases sounds better than alternatives.
Best regards,
Pavel
PS: Are there systems where the timer interrupt is the only source of time?
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [PATCH] Add Ingenic JZ4780 hardware RNG driver
From: Jeffrey Walton @ 2016-08-19 9:47 UTC (permalink / raw)
To: PrasannaKumar Muralidharan
Cc: linux-crypto, devicetree, linux-kernel, linux-mips
In-Reply-To: <1471448151-20850-1-git-send-email-prasannatsmkumar@gmail.com>
On Wed, Aug 17, 2016 at 11:35 AM, PrasannaKumar Muralidharan
<prasannatsmkumar@gmail.com> wrote:
> This patch adds support for hardware random number generator present in
> JZ4780 SoC.
>
> Signed-off-by: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
> ---
> .../devicetree/bindings/rng/ingenic,jz4780-rng.txt | 12 +++
> MAINTAINERS | 5 +
> arch/mips/boot/dts/ingenic/jz4780.dtsi | 7 +-
> drivers/char/hw_random/Kconfig | 14 +++
> drivers/char/hw_random/Makefile | 1 +
> drivers/char/hw_random/jz4780-rng.c | 105 +++++++++++++++++++++
> 6 files changed, 143 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/rng/ingenic,jz4780-rng.txt
> create mode 100644 drivers/char/hw_random/jz4780-rng.c
>
> diff --git a/Documentation/devicetree/bindings/rng/ingenic,jz4780-rng.txt b/Documentation/devicetree/bindings/rng/ingenic,jz4780-rng.txt
> new file mode 100644
> index 0000000..03abf56
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/rng/ingenic,jz4780-rng.txt
> @@ -0,0 +1,12 @@
> +Ingenic jz4780 RNG driver
> +
> +Required properties:
> +- compatible : Should be "ingenic,jz4780-rng"
> +- reg : Specifies base physical address and size of the registers.
> +
> +Example:
> +
> +rng: rng@100000D8 {
> + compatible = "ingenic,jz4780-rng";
> + reg = <0x100000D8 0x8>;
> +};
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 08e9efe..c0c66eb 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6002,6 +6002,11 @@ M: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com>
> S: Maintained
> F: drivers/dma/dma-jz4780.c
>
> +INGENIC JZ4780 HW RNG Driver
> +M: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
> +S: Maintained
> +F: drivers/char/hw_random/jz4780-rng.c
> +
> INTEGRITY MEASUREMENT ARCHITECTURE (IMA)
> M: Mimi Zohar <zohar@linux.vnet.ibm.com>
> M: Dmitry Kasatkin <dmitry.kasatkin@gmail.com>
> diff --git a/arch/mips/boot/dts/ingenic/jz4780.dtsi b/arch/mips/boot/dts/ingenic/jz4780.dtsi
> index b868b42..f11d139 100644
> --- a/arch/mips/boot/dts/ingenic/jz4780.dtsi
> +++ b/arch/mips/boot/dts/ingenic/jz4780.dtsi
> @@ -36,7 +36,7 @@
>
> cgu: jz4780-cgu@10000000 {
> compatible = "ingenic,jz4780-cgu";
> - reg = <0x10000000 0x100>;
> + reg = <0x10000000 0xD8>;
>
> clocks = <&ext>, <&rtc>;
> clock-names = "ext", "rtc";
> @@ -44,6 +44,11 @@
> #clock-cells = <1>;
> };
>
> + rng: jz4780-rng@100000D8 {
> + compatible = "ingenic,jz4780-rng";
> + reg = <0x100000D8 0x8>;
> + };
> +
> uart0: serial@10030000 {
> compatible = "ingenic,jz4780-uart";
> reg = <0x10030000 0x100>;
> diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
> index 56ad5a59..c336fe8 100644
> --- a/drivers/char/hw_random/Kconfig
> +++ b/drivers/char/hw_random/Kconfig
> @@ -294,6 +294,20 @@ config HW_RANDOM_POWERNV
>
> If unsure, say Y.
>
> +config HW_RANDOM_JZ4780
> + tristate "JZ4780 HW random number generator support"
> + depends on MACH_INGENIC
> + depends on HAS_IOMEM
> + default HW_RANDOM
> + ---help---
> + This driver provides kernel-side support for the Random Number
> + Generator hardware found on JZ4780 SOCs.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called jz4780-rng.
> +
> + If unsure, say Y.
> +
> config HW_RANDOM_EXYNOS
> tristate "EXYNOS HW random number generator support"
> depends on ARCH_EXYNOS || COMPILE_TEST
> diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
> index 04bb0b0..a155066 100644
> --- a/drivers/char/hw_random/Makefile
> +++ b/drivers/char/hw_random/Makefile
> @@ -26,6 +26,7 @@ obj-$(CONFIG_HW_RANDOM_PSERIES) += pseries-rng.o
> obj-$(CONFIG_HW_RANDOM_POWERNV) += powernv-rng.o
> obj-$(CONFIG_HW_RANDOM_EXYNOS) += exynos-rng.o
> obj-$(CONFIG_HW_RANDOM_HISI) += hisi-rng.o
> +obj-$(CONFIG_HW_RANDOM_JZ4780) += jz4780-rng.o
> obj-$(CONFIG_HW_RANDOM_TPM) += tpm-rng.o
> obj-$(CONFIG_HW_RANDOM_BCM2835) += bcm2835-rng.o
> obj-$(CONFIG_HW_RANDOM_IPROC_RNG200) += iproc-rng200.o
> diff --git a/drivers/char/hw_random/jz4780-rng.c b/drivers/char/hw_random/jz4780-rng.c
> new file mode 100644
> index 0000000..c9d2cde
> --- /dev/null
> +++ b/drivers/char/hw_random/jz4780-rng.c
> @@ -0,0 +1,105 @@
> +/*
> + * jz4780-rng.c - Random Number Generator driver for J4780
> + *
> + * Copyright 2016 (C) PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include <linux/hw_random.h>
> +#include <linux/device.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/io.h>
> +#include <linux/platform_device.h>
> +#include <linux/err.h>
> +
> +#define REG_RNG_CTRL 0x0
> +#define REG_RNG_DATA 0x4
> +
> +struct jz4780_rng {
> + struct device *dev;
> + struct hwrng rng;
> + void __iomem *mem;
> +};
> +
> +static u32 jz4780_rng_readl(struct jz4780_rng *rng, u32 offset)
> +{
> + return readl(rng->mem + offset);
> +}
> +
> +static void jz4780_rng_writel(struct jz4780_rng *rng, u32 val, u32 offset)
> +{
> + writel(val, rng->mem + offset);
> +}
> +
> +static int jz4780_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
> +{
> + struct jz4780_rng *jz4780_rng = container_of(rng, struct jz4780_rng,
> + rng);
> + u32 *data = buf;
> + *data = jz4780_rng_readl(jz4780_rng, REG_RNG_DATA);
> + return 4;
> +}
> +
> +static int jz4780_rng_probe(struct platform_device *pdev)
> +{
> + struct jz4780_rng *jz4780_rng;
> + struct resource *res;
> + resource_size_t size;
> + int ret;
> +
> + jz4780_rng = devm_kzalloc(&pdev->dev, sizeof(struct jz4780_rng),
> + GFP_KERNEL);
> + if (!jz4780_rng)
> + return -ENOMEM;
> +
> + jz4780_rng->dev = &pdev->dev;
> + jz4780_rng->rng.name = "jz4780";
> + jz4780_rng->rng.read = jz4780_rng_read;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + size = resource_size(res);
> +
> + jz4780_rng->mem = devm_ioremap(&pdev->dev, res->start, size);
> + if (IS_ERR(jz4780_rng->mem))
> + return PTR_ERR(jz4780_rng->mem);
> +
> + platform_set_drvdata(pdev, jz4780_rng);
> + jz4780_rng_writel(jz4780_rng, 1, REG_RNG_CTRL);
> + ret = hwrng_register(&jz4780_rng->rng);
> +
> + return ret;
> +}
> +
> +static int jz4780_rng_remove(struct platform_device *pdev)
> +{
> + struct jz4780_rng *jz4780_rng = platform_get_drvdata(pdev);
> +
> + jz4780_rng_writel(jz4780_rng, 0, REG_RNG_CTRL);
> + hwrng_unregister(&jz4780_rng->rng);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id jz4780_rng_dt_match[] = {
> + { .compatible = "ingenic,jz4780-rng", },
> + { },
> +};
> +MODULE_DEVICE_TABLE(of, jz4780_rng_dt_match);
> +
> +static struct platform_driver jz4780_rng_driver = {
> + .driver = {
> + .name = "jz4780-rng",
> + .of_match_table = jz4780_rng_dt_match,
> + },
> + .probe = jz4780_rng_probe,
> + .remove = jz4780_rng_remove,
> +};
> +module_platform_driver(jz4780_rng_driver);
> +
> +MODULE_DESCRIPTION("Ingenic JZ4780 H/W Random Number Generator driver");
> +MODULE_AUTHOR("PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>");
> +MODULE_LICENSE("GPL");
> --
Please forgive my ignorance Prasanna...
For the JZ4780 I have, there are two registers in play. The first is
the control register which enables/disables the RNG. The control
register is named ERNG. The second register is the data register, and
it produces the random stream. The data register is named RNG. ERNG is
located at 0x100000D8 and RNG is located at 0x100000DC. This kind of
confuses me because I don't see where 0x100000D8 is ever added to
those values (maybe its in the descriptor?):
+#define REG_RNG_CTRL 0x0
+#define REG_RNG_DATA 0x4
Also, testing with a userland PoC for the device, you have to throttle
reads from RNG register. If reads occur with a 0 delay, then the
random value appears fixed. If the delay is too small, then you can
watch random values being shifted-in in a barrel like fashion.
Unfortunately, the manual did not discuss how long to wait for a value
to be ready. I found spinning in a loop for 5000 was too small and
witnessed the shifting; while spinning in a loop for 10000 avoided the
shift observation. I don't what number of JIFFIES that translates to.
Finally, from looking at the native Ingenic driver (which was not very
impressive), they enabled/disabled the RNG register on demand. There
was also a [possible related] note in the manual about not applying
VCC for over a second. I can only say "possibly related" because I was
not sure if the register was part of the controller they were
discussing. The userland PoC worked fine when enabling/disabling the
RNG register. So I'm not sure about this (from jz4780_rng_probe):
+ platform_set_drvdata(pdev, jz4780_rng);
+ jz4780_rng_writel(jz4780_rng, 1, REG_RNG_CTRL);
+ ret = hwrng_register(&jz4780_rng->rng);
And this (from jz4780_rng_remove):
+ jz4780_rng_writel(jz4780_rng, 0, REG_RNG_CTRL);
+ hwrng_unregister(&jz4780_rng->rng);
Anyway, I hope that helps you avoid some land mines (if they are present).
Jeff
^ permalink raw reply
* Re: [PATCH] Add Ingenic JZ4780 hardware RNG driver
From: Jeffrey Walton @ 2016-08-19 10:55 UTC (permalink / raw)
To: PrasannaKumar Muralidharan
Cc: linux-crypto, devicetree, linux-kernel, linux-mips
In-Reply-To: <1471448151-20850-1-git-send-email-prasannatsmkumar@gmail.com>
On Wed, Aug 17, 2016 at 11:35 AM, PrasannaKumar Muralidharan
<prasannatsmkumar@gmail.com> wrote:
> This patch adds support for hardware random number generator present in
> JZ4780 SoC.
>
> Signed-off-by: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
> ---
> ...
> +static int jz4780_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
> +{
> + struct jz4780_rng *jz4780_rng = container_of(rng, struct jz4780_rng,
> + rng);
> + u32 *data = buf;
> + *data = jz4780_rng_readl(jz4780_rng, REG_RNG_DATA);
> + return 4;
> +}
My bad, I should have spotted this earlier....
i686, x86_64 and some ARM will sometimes define a macro indicating
unaligned data access is allowed. For example, see
__ARM_FEATURE_UNALIGNED (cf.,
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0774f/chr1383660321827.html)
. MIPSEL does not define such a macro.
# MIPS ci20 creator with GCC 4.6
$ gcc -march=native -dM -E - </dev/null | grep -i align
#define __BIGGEST_ALIGNMENT__ 8
If the MIPS CPU does not tolerate unaligned data access, then the
following could SIGBUS:
> + u32 *data = buf;
> + *data = jz4780_rng_readl(jz4780_rng, REG_RNG_DATA);
If GCC emits code that uses the MIPS unaligned load and store
instructions, then there's probably going to be a performance penalty.
Regardless of what the CPU tolerates, I believe unaligned data access
is undefined behavior in C/C++. I believe you should memcpy the value
into the buffer.
Jeff
^ permalink raw reply
* [PATCH] crypto/xor: skip speed test if the xor function is selected automatically
From: Martin Schwidefsky @ 2016-08-19 12:19 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, linux-crypto; +Cc: Martin Schwidefsky
If the architecture selected the xor function with XOR_SELECT_TEMPLATE
the speed result of the do_xor_speed benchmark is of limited value.
The speed measurement increases the bootup time a little, which can
makes a difference for kernels used in container like virtual machines.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
---
crypto/xor.c | 40 +++++++++++++++++++---------------------
1 file changed, 19 insertions(+), 21 deletions(-)
diff --git a/crypto/xor.c b/crypto/xor.c
index 35d6b3a..b8975d9 100644
--- a/crypto/xor.c
+++ b/crypto/xor.c
@@ -109,6 +109,18 @@ calibrate_xor_blocks(void)
void *b1, *b2;
struct xor_block_template *f, *fastest;
+ fastest = NULL;
+
+#ifdef XOR_SELECT_TEMPLATE
+ fastest = XOR_SELECT_TEMPLATE(fastest);
+ if (fastest) {
+ printk(KERN_INFO "xor: automatically using best "
+ "checksumming function %-10s\n",
+ fastest->name);
+ goto out;
+ }
+#endif
+
/*
* Note: Since the memory is not actually used for _anything_ but to
* test the XOR speed, we don't really want kmemcheck to warn about
@@ -126,36 +138,22 @@ calibrate_xor_blocks(void)
* all the possible functions, just test the best one
*/
- fastest = NULL;
-
-#ifdef XOR_SELECT_TEMPLATE
- fastest = XOR_SELECT_TEMPLATE(fastest);
-#endif
-
#define xor_speed(templ) do_xor_speed((templ), b1, b2)
- if (fastest) {
- printk(KERN_INFO "xor: automatically using best "
- "checksumming function:\n");
- xor_speed(fastest);
- goto out;
- } else {
- printk(KERN_INFO "xor: measuring software checksum speed\n");
- XOR_TRY_TEMPLATES;
- fastest = template_list;
- for (f = fastest; f; f = f->next)
- if (f->speed > fastest->speed)
- fastest = f;
- }
+ printk(KERN_INFO "xor: measuring software checksum speed\n");
+ XOR_TRY_TEMPLATES;
+ fastest = template_list;
+ for (f = fastest; f; f = f->next)
+ if (f->speed > fastest->speed)
+ fastest = f;
printk(KERN_INFO "xor: using function: %s (%d.%03d MB/sec)\n",
fastest->name, fastest->speed / 1000, fastest->speed % 1000);
#undef xor_speed
- out:
free_pages((unsigned long)b1, 2);
-
+out:
active_template = fastest;
return 0;
}
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] Add Ingenic JZ4780 hardware RNG driver
From: PrasannaKumar Muralidharan @ 2016-08-19 12:54 UTC (permalink / raw)
To: noloader-Re5JQEeQqe8AvxtiuMwx3w
Cc: linux-crypto-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mips-6z/3iImG2C8G8FEW9MqTrA
In-Reply-To: <CAH8yC8kt-+6tnzAc2bsu6GX4uX1bqVoE8sZXvCS34DDhGhP2XQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
> Please forgive my ignorance Prasanna...
>
> For the JZ4780 I have, there are two registers in play. The first is
> the control register which enables/disables the RNG. The control
> register is named ERNG. The second register is the data register, and
> it produces the random stream. The data register is named RNG. ERNG is
> located at 0x100000D8 and RNG is located at 0x100000DC. This kind of
> confuses me because I don't see where 0x100000D8 is ever added to
> those values (maybe its in the descriptor?):
>
> +#define REG_RNG_CTRL 0x0
> +#define REG_RNG_DATA 0x4
The base address 0x100000D8 is defined in jz4780.dtsi file.
REG_RNG_CTRL and REG_RNG_DATA are offsets. In jz4780_rng_readl and
jz4780_rng_writel functions the ioremap'd base address is added with
offset.
> Also, testing with a userland PoC for the device, you have to throttle
> reads from RNG register. If reads occur with a 0 delay, then the
> random value appears fixed. If the delay is too small, then you can
> watch random values being shifted-in in a barrel like fashion.
> Unfortunately, the manual did not discuss how long to wait for a value
> to be ready. I found spinning in a loop for 5000 was too small and
> witnessed the shifting; while spinning in a loop for 10000 avoided the
> shift observation. I don't what number of JIFFIES that translates to.
I can calculate the speed and make sure the delay is met in the
driver. Thanks a lot for providing this info.
> Finally, from looking at the native Ingenic driver (which was not very
> impressive), they enabled/disabled the RNG register on demand. There
> was also a [possible related] note in the manual about not applying
> VCC for over a second. I can only say "possibly related" because I was
> not sure if the register was part of the controller they were
> discussing. The userland PoC worked fine when enabling/disabling the
> RNG register. So I'm not sure about this (from jz4780_rng_probe):
>
> + platform_set_drvdata(pdev, jz4780_rng);
> + jz4780_rng_writel(jz4780_rng, 1, REG_RNG_CTRL);
> + ret = hwrng_register(&jz4780_rng->rng);
>
> And this (from jz4780_rng_remove):
>
> + jz4780_rng_writel(jz4780_rng, 0, REG_RNG_CTRL);
> + hwrng_unregister(&jz4780_rng->rng);
>
> Anyway, I hope that helps you avoid some land mines (if they are present).
Looking at JZ4780 Programmers manual I could not find any info about
VCC. Can you point me to it?
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] Add Ingenic JZ4780 hardware RNG driver
From: PrasannaKumar Muralidharan @ 2016-08-19 13:09 UTC (permalink / raw)
To: noloader; +Cc: linux-crypto, devicetree, linux-kernel, linux-mips
In-Reply-To: <CAH8yC8ny62Vf63cjtL8bUgGoRr-0BVGvqazs20S4JreJq+OBcg@mail.gmail.com>
> __ARM_FEATURE_UNALIGNED (cf.,
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0774f/chr1383660321827.html)
> . MIPSEL does not define such a macro.
>
> # MIPS ci20 creator with GCC 4.6
> $ gcc -march=native -dM -E - </dev/null | grep -i align
> #define __BIGGEST_ALIGNMENT__ 8
>
> If the MIPS CPU does not tolerate unaligned data access, then the
> following could SIGBUS:
>
>> + u32 *data = buf;
>> + *data = jz4780_rng_readl(jz4780_rng, REG_RNG_DATA);
>
> If GCC emits code that uses the MIPS unaligned load and store
> instructions, then there's probably going to be a performance penalty.
>
> Regardless of what the CPU tolerates, I believe unaligned data access
> is undefined behavior in C/C++. I believe you should memcpy the value
> into the buffer.
I am not sure whether this is required. 'buf' is part of a structure
so I guess it is properly aligned by padding. Not sure though, will
look about this.
^ permalink raw reply
* [PATCH 1/5] hwrng: amd: Fix style problem with blank line
From: LABBE Corentin @ 2016-08-19 13:42 UTC (permalink / raw)
To: herbert, mpm; +Cc: linux-crypto, linux-kernel, LABBE Corentin
Some blank line are unncessary, and one is missing after declaration.
This patch fix thoses style problems.
Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>
---
drivers/char/hw_random/amd-rng.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/char/hw_random/amd-rng.c b/drivers/char/hw_random/amd-rng.c
index 48f6a83..45b7965 100644
--- a/drivers/char/hw_random/amd-rng.c
+++ b/drivers/char/hw_random/amd-rng.c
@@ -31,10 +31,8 @@
#include <linux/delay.h>
#include <asm/io.h>
-
#define PFX KBUILD_MODNAME ": "
-
/*
* Data for PCI driver interface
*
@@ -52,7 +50,6 @@ MODULE_DEVICE_TABLE(pci, pci_tbl);
static struct pci_dev *amd_pdev;
-
static int amd_rng_data_present(struct hwrng *rng, int wait)
{
u32 pmbase = (u32)rng->priv;
@@ -100,7 +97,6 @@ static void amd_rng_cleanup(struct hwrng *rng)
pci_write_config_byte(amd_pdev, 0x40, rnen);
}
-
static struct hwrng amd_rng = {
.name = "amd",
.init = amd_rng_init,
@@ -109,7 +105,6 @@ static struct hwrng amd_rng = {
.data_read = amd_rng_data_read,
};
-
static int __init mod_init(void)
{
int err = -ENODEV;
@@ -157,6 +152,7 @@ out:
static void __exit mod_exit(void)
{
u32 pmbase = (unsigned long)amd_rng.priv;
+
release_region(pmbase + 0xF0, 8);
hwrng_unregister(&amd_rng);
}
--
2.7.3
^ permalink raw reply related
* [PATCH 3/5] hwrng: amd: Be consitent with the driver name
From: LABBE Corentin @ 2016-08-19 13:42 UTC (permalink / raw)
To: herbert, mpm; +Cc: linux-crypto, linux-kernel, LABBE Corentin
In-Reply-To: <1471614177-12380-1-git-send-email-clabbe.montjoie@gmail.com>
The driver name is displayed each time differently.
This patch make use of the same name everywhere.
Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>
---
drivers/char/hw_random/amd-rng.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/char/hw_random/amd-rng.c b/drivers/char/hw_random/amd-rng.c
index d0042f5..d0a806a 100644
--- a/drivers/char/hw_random/amd-rng.c
+++ b/drivers/char/hw_random/amd-rng.c
@@ -31,7 +31,7 @@
#include <linux/delay.h>
#include <asm/io.h>
-#define PFX KBUILD_MODNAME ": "
+#define DRV_NAME "AMD768-HWRNG"
/*
* Data for PCI driver interface
@@ -98,7 +98,7 @@ static void amd_rng_cleanup(struct hwrng *rng)
}
static struct hwrng amd_rng = {
- .name = "amd",
+ .name = DRV_NAME,
.init = amd_rng_init,
.cleanup = amd_rng_cleanup,
.data_present = amd_rng_data_present,
@@ -128,8 +128,8 @@ found:
pmbase &= 0x0000FF00;
if (pmbase == 0)
goto out;
- if (!request_region(pmbase + 0xF0, 8, "AMD HWRNG")) {
- dev_err(&pdev->dev, "AMD HWRNG region 0x%x already in use!\n",
+ if (!request_region(pmbase + 0xF0, 8, DRV_NAME)) {
+ dev_err(&pdev->dev, DRV_NAME " region 0x%x already in use!\n",
pmbase + 0xF0);
err = -EBUSY;
goto out;
@@ -137,11 +137,10 @@ found:
amd_rng.priv = (unsigned long)pmbase;
amd_pdev = pdev;
- pr_info("AMD768 RNG detected\n");
+ pr_info(DRV_NAME " detected\n");
err = hwrng_register(&amd_rng);
if (err) {
- pr_err(PFX "RNG registering failed (%d)\n",
- err);
+ pr_err(DRV_NAME " registering failed (%d)\n", err);
release_region(pmbase + 0xF0, 8);
goto out;
}
--
2.7.3
^ permalink raw reply related
* [PATCH 5/5] hwrng: amd: Rework of the amd768-hwrng driver
From: LABBE Corentin @ 2016-08-19 13:42 UTC (permalink / raw)
To: herbert, mpm; +Cc: linux-crypto, linux-kernel, LABBE Corentin
In-Reply-To: <1471614177-12380-1-git-send-email-clabbe.montjoie@gmail.com>
This patch convert the hwrng interface used by amd768-rng to its new API
by replacing data_read()/data_present() by read().
Furthermore, Instead of having two global variable, it's better to use a
private struct. This will permit to remove amd_pdev variable.
Finally, Instead of accessing hw directly via pmbase, it's better to
access after ioport_map() via ioread32/iowrite32.
Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>
---
drivers/char/hw_random/amd-rng.c | 151 +++++++++++++++++++++++++--------------
1 file changed, 99 insertions(+), 52 deletions(-)
diff --git a/drivers/char/hw_random/amd-rng.c b/drivers/char/hw_random/amd-rng.c
index 9ddc99c..efdd853 100644
--- a/drivers/char/hw_random/amd-rng.c
+++ b/drivers/char/hw_random/amd-rng.c
@@ -32,6 +32,14 @@
#define DRV_NAME "AMD768-HWRNG"
+#define GEN_CFG_REG1 0x40
+#define GEN_CFG_REG2 0x41
+#define SMIO_SPACEPTR 0x58
+#define RNGDATA 0x00
+#define RNGDONE 0x04
+#define PMBASE_OFFSET 0xF0
+#define PMBASE_SIZE 8
+
/*
* Data for PCI driver interface
*
@@ -39,6 +47,7 @@
* PCI ids via MODULE_DEVICE_TABLE. We do not actually
* register a pci_driver, because someone else might one day
* want to register another driver on the same PCI id.
+ * Like i2c-amd756
*/
static const struct pci_device_id pci_tbl[] = {
{ PCI_VDEVICE(AMD, 0x7443), 0, },
@@ -47,112 +56,150 @@ static const struct pci_device_id pci_tbl[] = {
};
MODULE_DEVICE_TABLE(pci, pci_tbl);
-static struct pci_dev *amd_pdev;
+struct amd768_priv {
+ void __iomem *iobase;
+ struct pci_dev *pcidev;
+ u32 pmbase;
+};
-static int amd_rng_data_present(struct hwrng *rng, int wait)
+static int amd_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
{
- u32 pmbase = (u32)rng->priv;
- int data, i;
-
- for (i = 0; i < 20; i++) {
- data = !!(inl(pmbase + 0xF4) & 1);
- if (data || !wait)
- break;
- udelay(10);
+ u32 *data = buf;
+ struct amd768_priv *priv = (struct amd768_priv *)rng->priv;
+ size_t read = 0;
+ /* We will wait at maximum one time per read */
+ int timeout = max / 4 + 1;
+
+ /*
+ * RNG data is available when RNGDONE is set to 1
+ * New random numbers are generated approximately 128 microseconds
+ * after RNGDATA is read
+ */
+ while (read < max) {
+ if (ioread32(priv->iobase + RNGDONE) == 0) {
+ if (wait) {
+ /* Delay given by datasheet */
+ usleep_range(128, 196);
+ if (timeout-- == 0)
+ return read;
+ } else {
+ return 0;
+ }
+ } else {
+ *data = ioread32(priv->iobase + RNGDATA);
+ data++;
+ read += 4;
+ }
}
- return data;
-}
-
-static int amd_rng_data_read(struct hwrng *rng, u32 *data)
-{
- u32 pmbase = (u32)rng->priv;
- *data = inl(pmbase + 0xF0);
-
- return 4;
+ return read;
}
static int amd_rng_init(struct hwrng *rng)
{
u8 rnen;
+ struct amd768_priv *priv = (struct amd768_priv *)rng->priv;
- pci_read_config_byte(amd_pdev, 0x40, &rnen);
+ pci_read_config_byte(priv->pcidev, GEN_CFG_REG1, &rnen);
rnen |= BIT(7); /* RNG on */
- pci_write_config_byte(amd_pdev, 0x40, rnen);
+ pci_write_config_byte(priv->pcidev, GEN_CFG_REG1, rnen);
- pci_read_config_byte(amd_pdev, 0x41, &rnen);
+ pci_read_config_byte(priv->pcidev, GEN_CFG_REG2, &rnen);
rnen |= BIT(7); /* PMIO enable */
- pci_write_config_byte(amd_pdev, 0x41, rnen);
-
+ pci_write_config_byte(priv->pcidev, GEN_CFG_REG2, rnen);
return 0;
}
static void amd_rng_cleanup(struct hwrng *rng)
{
u8 rnen;
+ struct amd768_priv *priv = (struct amd768_priv *)rng->priv;
- pci_read_config_byte(amd_pdev, 0x40, &rnen);
+ pci_read_config_byte(priv->pcidev, GEN_CFG_REG1, &rnen);
rnen &= ~BIT(7); /* RNG off */
- pci_write_config_byte(amd_pdev, 0x40, rnen);
+ pci_write_config_byte(priv->pcidev, GEN_CFG_REG1, rnen);
}
static struct hwrng amd_rng = {
.name = DRV_NAME,
+ .read = amd_rng_read,
.init = amd_rng_init,
.cleanup = amd_rng_cleanup,
- .data_present = amd_rng_data_present,
- .data_read = amd_rng_data_read,
};
-static int __init mod_init(void)
+static int mod_init(void)
{
- int err = -ENODEV;
+ int err;
struct pci_dev *pdev = NULL;
const struct pci_device_id *ent;
u32 pmbase;
+ struct amd768_priv *priv;
for_each_pci_dev(pdev) {
ent = pci_match_id(pci_tbl, pdev);
if (ent)
goto found;
}
- /* Device not found. */
- goto out;
-
+ return -ENODEV;
found:
- err = pci_read_config_dword(pdev, 0x58, &pmbase);
+
+ err = pci_read_config_dword(pdev, SMIO_SPACEPTR, &pmbase);
if (err)
- goto out;
- err = -EIO;
+ return err;
+
pmbase &= 0x0000FF00;
- if (pmbase == 0)
- goto out;
- if (!request_region(pmbase + 0xF0, 8, DRV_NAME)) {
- dev_err(&pdev->dev, DRV_NAME " region 0x%x already in use!\n",
- pmbase + 0xF0);
- err = -EBUSY;
- goto out;
+
+ priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ if (!request_region(pmbase + PMBASE_OFFSET, PMBASE_SIZE, DRV_NAME)) {
+ pr_err(DRV_NAME "region 0x%x already in use!\n", pmbase);
+ goto err_pmbase;
+ }
+
+ priv->iobase = ioport_map(pmbase + PMBASE_OFFSET, PMBASE_SIZE);
+ if (!priv->iobase) {
+ pr_err(DRV_NAME "Cannot map ioport\n");
+ err = -EINVAL;
+ goto err_iomap;
}
- amd_rng.priv = (unsigned long)pmbase;
- amd_pdev = pdev;
+
+ amd_rng.priv = (unsigned long)priv;
+ priv->pmbase = pmbase;
+ priv->pcidev = pdev;
pr_info(DRV_NAME " detected\n");
+
err = hwrng_register(&amd_rng);
if (err) {
- pr_err(DRV_NAME " registering failed (%d)\n", err);
- release_region(pmbase + 0xF0, 8);
- goto out;
+ pr_err(DRV_NAME "Cannot register HWRNG %d\n", err);
+ goto err_hwrng;
}
-out:
+ return 0;
+
+err_hwrng:
+ ioport_unmap(priv->iobase);
+err_iomap:
+ release_region(pmbase + PMBASE_OFFSET, PMBASE_SIZE);
+err_pmbase:
+ kfree(priv);
return err;
}
-static void __exit mod_exit(void)
+static void mod_exit(void)
{
- u32 pmbase = (unsigned long)amd_rng.priv;
+ struct amd768_priv *priv;
+
+ priv = (struct amd768_priv *)amd_rng.priv;
- release_region(pmbase + 0xF0, 8);
hwrng_unregister(&amd_rng);
+
+ ioport_unmap(priv->iobase);
+
+ release_region(priv->pmbase + PMBASE_OFFSET, PMBASE_SIZE);
+
+ kfree(priv);
}
module_init(mod_init);
--
2.7.3
^ permalink raw reply related
* [PATCH 4/5] hwrng: amd: Remove asm/io.h
From: LABBE Corentin @ 2016-08-19 13:42 UTC (permalink / raw)
To: herbert, mpm; +Cc: linux-crypto, linux-kernel, LABBE Corentin
In-Reply-To: <1471614177-12380-1-git-send-email-clabbe.montjoie@gmail.com>
checkpatch complains about <asm/io.h> used instead of linux/io.h.
In fact it is not needed.
This patch remove it, and in the process, alphabetize the other headers.
Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>
---
drivers/char/hw_random/amd-rng.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/char/hw_random/amd-rng.c b/drivers/char/hw_random/amd-rng.c
index d0a806a..9ddc99c 100644
--- a/drivers/char/hw_random/amd-rng.c
+++ b/drivers/char/hw_random/amd-rng.c
@@ -24,12 +24,11 @@
* warranty of any kind, whether express or implied.
*/
-#include <linux/module.h>
+#include <linux/delay.h>
+#include <linux/hw_random.h>
#include <linux/kernel.h>
+#include <linux/module.h>
#include <linux/pci.h>
-#include <linux/hw_random.h>
-#include <linux/delay.h>
-#include <asm/io.h>
#define DRV_NAME "AMD768-HWRNG"
--
2.7.3
^ permalink raw reply related
* [PATCH 2/5] hwrng: amd: use the BIT macro
From: LABBE Corentin @ 2016-08-19 13:42 UTC (permalink / raw)
To: herbert, mpm; +Cc: linux-crypto, linux-kernel, LABBE Corentin
In-Reply-To: <1471614177-12380-1-git-send-email-clabbe.montjoie@gmail.com>
This patch add usage of the BIT() macro
Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>
---
drivers/char/hw_random/amd-rng.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/char/hw_random/amd-rng.c b/drivers/char/hw_random/amd-rng.c
index 45b7965..d0042f5 100644
--- a/drivers/char/hw_random/amd-rng.c
+++ b/drivers/char/hw_random/amd-rng.c
@@ -78,11 +78,11 @@ static int amd_rng_init(struct hwrng *rng)
u8 rnen;
pci_read_config_byte(amd_pdev, 0x40, &rnen);
- rnen |= (1 << 7); /* RNG on */
+ rnen |= BIT(7); /* RNG on */
pci_write_config_byte(amd_pdev, 0x40, rnen);
pci_read_config_byte(amd_pdev, 0x41, &rnen);
- rnen |= (1 << 7); /* PMIO enable */
+ rnen |= BIT(7); /* PMIO enable */
pci_write_config_byte(amd_pdev, 0x41, rnen);
return 0;
@@ -93,7 +93,7 @@ static void amd_rng_cleanup(struct hwrng *rng)
u8 rnen;
pci_read_config_byte(amd_pdev, 0x40, &rnen);
- rnen &= ~(1 << 7); /* RNG off */
+ rnen &= ~BIT(7); /* RNG off */
pci_write_config_byte(amd_pdev, 0x40, rnen);
}
--
2.7.3
^ permalink raw reply related
* Re: [PATCH v6 0/5] /dev/random - a new approach
From: H. Peter Anvin @ 2016-08-19 17:20 UTC (permalink / raw)
To: Herbert Xu, Theodore Ts'o, Pavel Machek, Stephan Mueller,
sandyinchina, Jason Cooper, John Denker, Joe Perches,
George Spelvin, linux-crypto, linux-kernel
In-Reply-To: <20160819055612.GA20427@gondor.apana.org.au>
On 08/18/16 22:56, Herbert Xu wrote:
> On Thu, Aug 18, 2016 at 10:49:47PM -0400, Theodore Ts'o wrote:
>>
>> That really depends on the system. We can't assume that people are
>> using systems with a 100Hz clock interrupt. More often than not
>> people are using tickless kernels these days. That's actually the
>> problem with changing /dev/urandom to block until things are
>> initialized.
>
> Couldn't we disable tickless until urandom has been seeded? In fact
> perhaps we should accelerate the timer interrupt rate until it has
> been seeded?
>
The biggest problem there is that the timer interrupt adds *no* entropy
unless there is a source of asynchronicity in the system. On PCs,
traditionally the timer has been run from a completely different crystal
(14.31818 MHz) than the CPU, which is the ideal situation, but if they
are run off the same crystal and run in lockstep, there is very little
if anything there. On some systems, the timer may even *be* the only
source of time, and the entropy truly is zero.
-hpa
^ 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