* Re: [PATCH] hwrng: stm32 - fix build warning
From: Maxime Coquelin @ 2016-05-24 8:50 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel@lists.infradead.org, Sudip Mukherjee,
Matt Mackall, Herbert Xu, linux-kernel@vger.kernel.org,
linux-crypto
In-Reply-To: <12548318.auB4PSA3KC@wuerfel>
2016-05-24 10:32 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
> On Tuesday, May 24, 2016 9:59:41 AM CEST Maxime Coquelin wrote:
>> 2016-05-23 22:35 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
>> > On Monday, May 23, 2016 6:14:08 PM CEST Sudip Mukherjee wrote:
>> >> diff --git a/drivers/char/hw_random/stm32-rng.c b/drivers/char/hw_random/stm32-rng.c
>> >> index 92a8106..0533370 100644
>> >> --- a/drivers/char/hw_random/stm32-rng.c
>> >> +++ b/drivers/char/hw_random/stm32-rng.c
>> >> @@ -52,7 +52,7 @@ static int stm32_rng_read(struct hwrng *rng, void *data, size_t max, bool wait)
>> >> {
>> >> struct stm32_rng_private *priv =
>> >> container_of(rng, struct stm32_rng_private, rng);
>> >> - u32 sr;
>> >> + u32 sr = 0;
>> >> int retval = 0;
>> >>
>> >> pm_runtime_get_sync((struct device *) priv->rng.priv);
>> >
>> > Does this work as well?
>> >
>> > diff --git a/drivers/char/hw_random/stm32-rng.c b/drivers/char/hw_random/stm32-rng.c
>> > index 92a810648bd0..5c836b0afa40 100644
>> > --- a/drivers/char/hw_random/stm32-rng.c
>> > +++ b/drivers/char/hw_random/stm32-rng.c
>> > @@ -79,7 +79,7 @@ static int stm32_rng_read(struct hwrng *rng, void *data, size_t max, bool wait)
>> > max -= sizeof(u32);
>> > }
>> >
>> > - if (WARN_ONCE(sr & (RNG_SR_SEIS | RNG_SR_CEIS),
>> > + if (WARN_ONCE(retval > 0 && (sr & (RNG_SR_SEIS | RNG_SR_CEIS)),
>> > "bad RNG status - %x\n", sr))
>> > writel_relaxed(0, priv->base + RNG_SR);
>> >
>> > I think it would be nicer to not add a bogus initialization.
>> Hmm, no sure this nicer.
>> The while loop can break before retval is incremented when sr value is
>> not expected (sr != RNG_SR_DRDY).
>> In that case, we certainly want to print sr value.
>
> Ah, you are right.
>
>> Maybe the better way is just to initialize sr with status register content?
>
>> pm_runtime_get_sync((struct device *) priv->rng.priv);
>>
>>+ sr = readl_relaxed(priv->base + RNG_SR);
>> while (max > sizeof(u32)) {
>>- sr = readl_relaxed(priv->base + RNG_SR);
>> if (!sr && wait) {
>> unsigned int timeout = RNG_TIMEOUT;
>
>
> I think that introduces a bug: you really want to read the status
> register on each loop iteration.
Actually, I read the status again at the end of the loop.
But my implementation isn't good anyway, because I read the status
register one time more every time.
>
> How about moving the error handling into the loop itself?
That would be better, indeed, but there is one problem with your below proposal:
>
> Arnd
>
>
> diff --git a/drivers/char/hw_random/stm32-rng.c b/drivers/char/hw_random/stm32-rng.c
> index 92a810648bd0..fceacd809462 100644
> --- a/drivers/char/hw_random/stm32-rng.c
> +++ b/drivers/char/hw_random/stm32-rng.c
> @@ -59,6 +59,10 @@ static int stm32_rng_read(struct hwrng *rng, void *data, size_t max, bool wait)
>
> while (max > sizeof(u32)) {
> sr = readl_relaxed(priv->base + RNG_SR);
> + if (WARN_ONCE(sr & (RNG_SR_SEIS | RNG_SR_CEIS),
> + "bad RNG status - %x\n", sr))
> + writel_relaxed(0, priv->base + RNG_SR);
> +
The error handling should be moved after the last status register read.
> if (!sr && wait) {
> unsigned int timeout = RNG_TIMEOUT;
>
> @@ -79,10 +83,6 @@ static int stm32_rng_read(struct hwrng *rng, void *data, size_t max, bool wait)
> max -= sizeof(u32);
> }
>
> - if (WARN_ONCE(sr & (RNG_SR_SEIS | RNG_SR_CEIS),
> - "bad RNG status - %x\n", sr))
> - writel_relaxed(0, priv->base + RNG_SR);
> -
> pm_runtime_mark_last_busy((struct device *) priv->rng.priv);
> pm_runtime_put_sync_autosuspend((struct device *) priv->rng.priv);
diff --git a/drivers/char/hw_random/stm32-rng.c
b/drivers/char/hw_random/stm32-rng.c
index 92a810648bd0..2a0fc90e4dc3 100644
--- a/drivers/char/hw_random/stm32-rng.c
+++ b/drivers/char/hw_random/stm32-rng.c
@@ -68,6 +68,10 @@ static int stm32_rng_read(struct hwrng *rng, void
*data, size_t max, bool wait)
} while (!sr && --timeout);
}
+ if (WARN_ONCE(sr & (RNG_SR_SEIS | RNG_SR_CEIS),
+ "bad RNG status - %x\n", sr))
+ writel_relaxed(0, priv->base + RNG_SR);
+
/* If error detected or data not ready... */
if (sr != RNG_SR_DRDY)
break;
@@ -79,10 +83,6 @@ static int stm32_rng_read(struct hwrng *rng, void
*data, size_t max, bool wait)
max -= sizeof(u32);
}
- if (WARN_ONCE(sr & (RNG_SR_SEIS | RNG_SR_CEIS),
- "bad RNG status - %x\n", sr))
- writel_relaxed(0, priv->base + RNG_SR);
-
pm_runtime_mark_last_busy((struct device *) priv->rng.priv);
pm_runtime_put_sync_autosuspend((struct device *) priv->rng.priv);
Thanks,
Maxime
^ permalink raw reply related
* Re: [PATCH] hwrng: stm32 - fix build warning
From: Arnd Bergmann @ 2016-05-24 8:32 UTC (permalink / raw)
To: Maxime Coquelin
Cc: linux-arm-kernel@lists.infradead.org, Sudip Mukherjee,
Matt Mackall, Herbert Xu, linux-kernel@vger.kernel.org,
linux-crypto
In-Reply-To: <CALszF6AxXY0LK5fToFg3095+gz6xcZz8KHaYqc=o39vjpBYDmA@mail.gmail.com>
On Tuesday, May 24, 2016 9:59:41 AM CEST Maxime Coquelin wrote:
> 2016-05-23 22:35 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
> > On Monday, May 23, 2016 6:14:08 PM CEST Sudip Mukherjee wrote:
> >> diff --git a/drivers/char/hw_random/stm32-rng.c b/drivers/char/hw_random/stm32-rng.c
> >> index 92a8106..0533370 100644
> >> --- a/drivers/char/hw_random/stm32-rng.c
> >> +++ b/drivers/char/hw_random/stm32-rng.c
> >> @@ -52,7 +52,7 @@ static int stm32_rng_read(struct hwrng *rng, void *data, size_t max, bool wait)
> >> {
> >> struct stm32_rng_private *priv =
> >> container_of(rng, struct stm32_rng_private, rng);
> >> - u32 sr;
> >> + u32 sr = 0;
> >> int retval = 0;
> >>
> >> pm_runtime_get_sync((struct device *) priv->rng.priv);
> >
> > Does this work as well?
> >
> > diff --git a/drivers/char/hw_random/stm32-rng.c b/drivers/char/hw_random/stm32-rng.c
> > index 92a810648bd0..5c836b0afa40 100644
> > --- a/drivers/char/hw_random/stm32-rng.c
> > +++ b/drivers/char/hw_random/stm32-rng.c
> > @@ -79,7 +79,7 @@ static int stm32_rng_read(struct hwrng *rng, void *data, size_t max, bool wait)
> > max -= sizeof(u32);
> > }
> >
> > - if (WARN_ONCE(sr & (RNG_SR_SEIS | RNG_SR_CEIS),
> > + if (WARN_ONCE(retval > 0 && (sr & (RNG_SR_SEIS | RNG_SR_CEIS)),
> > "bad RNG status - %x\n", sr))
> > writel_relaxed(0, priv->base + RNG_SR);
> >
> > I think it would be nicer to not add a bogus initialization.
> Hmm, no sure this nicer.
> The while loop can break before retval is incremented when sr value is
> not expected (sr != RNG_SR_DRDY).
> In that case, we certainly want to print sr value.
Ah, you are right.
> Maybe the better way is just to initialize sr with status register content?
> pm_runtime_get_sync((struct device *) priv->rng.priv);
>
>+ sr = readl_relaxed(priv->base + RNG_SR);
> while (max > sizeof(u32)) {
>- sr = readl_relaxed(priv->base + RNG_SR);
> if (!sr && wait) {
> unsigned int timeout = RNG_TIMEOUT;
I think that introduces a bug: you really want to read the status
register on each loop iteration.
How about moving the error handling into the loop itself?
Arnd
diff --git a/drivers/char/hw_random/stm32-rng.c b/drivers/char/hw_random/stm32-rng.c
index 92a810648bd0..fceacd809462 100644
--- a/drivers/char/hw_random/stm32-rng.c
+++ b/drivers/char/hw_random/stm32-rng.c
@@ -59,6 +59,10 @@ static int stm32_rng_read(struct hwrng *rng, void *data, size_t max, bool wait)
while (max > sizeof(u32)) {
sr = readl_relaxed(priv->base + RNG_SR);
+ if (WARN_ONCE(sr & (RNG_SR_SEIS | RNG_SR_CEIS),
+ "bad RNG status - %x\n", sr))
+ writel_relaxed(0, priv->base + RNG_SR);
+
if (!sr && wait) {
unsigned int timeout = RNG_TIMEOUT;
@@ -79,10 +83,6 @@ static int stm32_rng_read(struct hwrng *rng, void *data, size_t max, bool wait)
max -= sizeof(u32);
}
- if (WARN_ONCE(sr & (RNG_SR_SEIS | RNG_SR_CEIS),
- "bad RNG status - %x\n", sr))
- writel_relaxed(0, priv->base + RNG_SR);
-
pm_runtime_mark_last_busy((struct device *) priv->rng.priv);
pm_runtime_put_sync_autosuspend((struct device *) priv->rng.priv);
^ permalink raw reply related
* Re: [PATCH] hwrng: stm32 - fix build warning
From: Maxime Coquelin @ 2016-05-24 7:59 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel@lists.infradead.org, Sudip Mukherjee,
Matt Mackall, Herbert Xu, linux-kernel@vger.kernel.org,
linux-crypto
In-Reply-To: <6297051.TAxtzW5OIB@wuerfel>
2016-05-23 22:35 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
> On Monday, May 23, 2016 6:14:08 PM CEST Sudip Mukherjee wrote:
>> We have been getting build warning about:
>> drivers/char/hw_random/stm32-rng.c: In function 'stm32_rng_read':
>> drivers/char/hw_random/stm32-rng.c:82:19: warning: 'sr' may be used
>> uninitialized in this function
>>
>> On checking the code it turns out that sr can never be used
>> uninitialized as sr is getting initialized in the while loop and while
>> loop will always execute as the minimum value of max can be 32.
>> So just initialize sr to 0 while declaring it to silence the compiler.
>>
>> Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
>> ---
>
> I notice that you are using a really old compiler. While this warning
> seems to be valid in the sense that the compiler should figure out that
> the variable might be used uninitialized, please update your toolchain
> before reporting other such problems, as gcc-4.6 had a lot more false
> positives that newer ones (5.x or 6.x) have.
>
>>
>> build log at:
>> https://travis-ci.org/sudipm-mukherjee/parport/jobs/132180906
>>
>> drivers/char/hw_random/stm32-rng.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/char/hw_random/stm32-rng.c b/drivers/char/hw_random/stm32-rng.c
>> index 92a8106..0533370 100644
>> --- a/drivers/char/hw_random/stm32-rng.c
>> +++ b/drivers/char/hw_random/stm32-rng.c
>> @@ -52,7 +52,7 @@ static int stm32_rng_read(struct hwrng *rng, void *data, size_t max, bool wait)
>> {
>> struct stm32_rng_private *priv =
>> container_of(rng, struct stm32_rng_private, rng);
>> - u32 sr;
>> + u32 sr = 0;
>> int retval = 0;
>>
>> pm_runtime_get_sync((struct device *) priv->rng.priv);
>
> Does this work as well?
>
> diff --git a/drivers/char/hw_random/stm32-rng.c b/drivers/char/hw_random/stm32-rng.c
> index 92a810648bd0..5c836b0afa40 100644
> --- a/drivers/char/hw_random/stm32-rng.c
> +++ b/drivers/char/hw_random/stm32-rng.c
> @@ -79,7 +79,7 @@ static int stm32_rng_read(struct hwrng *rng, void *data, size_t max, bool wait)
> max -= sizeof(u32);
> }
>
> - if (WARN_ONCE(sr & (RNG_SR_SEIS | RNG_SR_CEIS),
> + if (WARN_ONCE(retval > 0 && (sr & (RNG_SR_SEIS | RNG_SR_CEIS)),
> "bad RNG status - %x\n", sr))
> writel_relaxed(0, priv->base + RNG_SR);
>
> I think it would be nicer to not add a bogus initialization.
Hmm, no sure this nicer.
The while loop can break before retval is incremented when sr value is
not expected (sr != RNG_SR_DRDY).
In that case, we certainly want to print sr value.
Maybe the better way is just to initialize sr with status register content?
diff --git a/drivers/char/hw_random/stm32-rng.c
b/drivers/char/hw_random/stm32-rng.c
index 92a810648bd0..07a6659d0fe6 100644
--- a/drivers/char/hw_random/stm32-rng.c
+++ b/drivers/char/hw_random/stm32-rng.c
@@ -57,8 +57,8 @@ static int stm32_rng_read(struct hwrng *rng, void
*data, size_t max, bool wait)
pm_runtime_get_sync((struct device *) priv->rng.priv);
+ sr = readl_relaxed(priv->base + RNG_SR);
while (max > sizeof(u32)) {
- sr = readl_relaxed(priv->base + RNG_SR);
if (!sr && wait) {
unsigned int timeout = RNG_TIMEOUT;
@@ -77,6 +77,8 @@ static int stm32_rng_read(struct hwrng *rng, void
*data, size_t max, bool wait)
retval += sizeof(u32);
data += sizeof(u32);
max -= sizeof(u32);
+
+ sr = readl_relaxed(priv->base + RNG_SR);
}
if (WARN_ONCE(sr & (RNG_SR_SEIS | RNG_SR_CEIS),
Regards,
Maxime
^ permalink raw reply related
* Re: key retention service: DH support
From: Stephan Mueller @ 2016-05-24 7:29 UTC (permalink / raw)
To: David Howells; +Cc: keyrings, linux-crypto, mathew.j.martineau
In-Reply-To: <28895.1464074381@warthog.procyon.org.uk>
Am Dienstag, 24. Mai 2016, 08:19:41 schrieb David Howells:
Hi David,
> Stephan Mueller <smueller@chronox.de> wrote:
> > The KDF patches are fully tested. All that would be needed on the key
> > retention side after the shared secret generation are the following calls:
> >
> > kdf = crypto_alloc_rng(NAME, 0, 0);
> >
> > crypto_rng_reset(kdf, <shared_secret>, sizeof(<shared_secret>));
> >
> > crypto_rng_generate(kdf, LABEL, sizeof(LABEL), outbuf, outbuflen);
> >
> > NAME would be the KDF type such as "kdf_ctr(hmac(sha256))"
> >
> > LABEL would be an arbitrary string defined by the key service (e.g.
> > "LxKeyRet").
>
> So there wouldn't be a change to the DH keyctl (including functional)?
Assuming that the LABEL and/or the KDF name are not configurable by user
space, the only potential difference I would see is that a user could ask for
the length of the output data.
Think of it like the KDF in a network protocol where the shared secret has
some length X but the caller needs data of length Y for a specific use (e.g. a
symmetric key plus an HMAC key). The use case for such "local" DH operation
would be the writing of encrypted data while the system is locked. The
encryption of the actual file data is done using a symmetric algo with
symmetric key, potentially with an integrity key. Usually, the DH shared
secret size is not equal to the size of a symmetric key. So, a KDF would be
needed to bring it to the right size.
Ciao
Stephan
^ permalink raw reply
* Re: key retention service: DH support
From: David Howells @ 2016-05-24 7:19 UTC (permalink / raw)
To: Stephan Mueller; +Cc: dhowells, keyrings, linux-crypto, mathew.j.martineau
In-Reply-To: <1884439.7dZQH0lY4q@tauon.atsec.com>
Stephan Mueller <smueller@chronox.de> wrote:
> The KDF patches are fully tested. All that would be needed on the key
> retention side after the shared secret generation are the following calls:
>
> kdf = crypto_alloc_rng(NAME, 0, 0);
>
> crypto_rng_reset(kdf, <shared_secret>, sizeof(<shared_secret>));
>
> crypto_rng_generate(kdf, LABEL, sizeof(LABEL), outbuf, outbuflen);
>
> NAME would be the KDF type such as "kdf_ctr(hmac(sha256))"
>
> LABEL would be an arbitrary string defined by the key service (e.g.
> "LxKeyRet").
So there wouldn't be a change to the DH keyctl (including functional)?
David
^ permalink raw reply
* Re: key retention service: DH support
From: Stephan Mueller @ 2016-05-24 7:14 UTC (permalink / raw)
To: David Howells; +Cc: keyrings, linux-crypto, mathew.j.martineau
In-Reply-To: <27639.1464073468@warthog.procyon.org.uk>
Am Dienstag, 24. Mai 2016, 08:04:28 schrieb David Howells:
Hi David,
> Stephan Mueller <smueller@chronox.de> wrote:
> > With the new DH support for the key retention service, support for DH
> > derived keys pops up.
> >
> > The implementation in security/keys/dh.c returns the DH shared secret
> > straight to the user space caller.
> >
> > I implemented a KDF with that exact scenario already in mind: [1].
> >
> > I am wondering whether the shared secret should be processed by a KDF
> > before returning the data to user space?
> >
> > [1] http://www.chronox.de/kdf.html
>
> Adding Mat to the cc list. If we want to modify the new DH keyctl, we have
> a very short time window in which to do so.
The KDF patches are fully tested. All that would be needed on the key
retention side after the shared secret generation are the following calls:
kdf = crypto_alloc_rng(NAME, 0, 0);
crypto_rng_reset(kdf, <shared_secret>, sizeof(<shared_secret>));
crypto_rng_generate(kdf, LABEL, sizeof(LABEL), outbuf, outbuflen);
NAME would be the KDF type such as "kdf_ctr(hmac(sha256))"
LABEL would be an arbitrary string defined by the key service (e.g.
"LxKeyRet").
Ciao
Stephan
^ permalink raw reply
* Re: key retention service: DH support
From: David Howells @ 2016-05-24 7:04 UTC (permalink / raw)
To: Stephan Mueller; +Cc: dhowells, keyrings, linux-crypto, mathew.j.martineau
In-Reply-To: <1522711.HEekpKlqDU@positron.chronox.de>
Stephan Mueller <smueller@chronox.de> wrote:
> With the new DH support for the key retention service, support for DH derived
> keys pops up.
>
> The implementation in security/keys/dh.c returns the DH shared secret straight
> to the user space caller.
>
> I implemented a KDF with that exact scenario already in mind: [1].
>
> I am wondering whether the shared secret should be processed by a KDF before
> returning the data to user space?
>
> [1] http://www.chronox.de/kdf.html
Adding Mat to the cc list. If we want to modify the new DH keyctl, we have a
very short time window in which to do so.
David
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: rng: Northstar Plus SoC rng bindings
From: Eric Anholt @ 2016-05-24 2:22 UTC (permalink / raw)
To: Yendapally Reddy Dhananjaya Reddy, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Stephen Warren, Lee Jones,
Russell King, Ray Jui, Scott Branden, Jon Mason, Matt Mackall,
Herbert Xu, Daniel Thompson, Kieran Bingham, Pankaj Dev,
Richard Weinberger, noltari-Re5JQEeQqe8AvxtiuMwx3w,
Joshua Henderson
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
Yendapally Reddy Dhananjaya Reddy
In-Reply-To: <1464020451-16520-2-git-send-email-yendapally.reddy-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 367 bytes --]
Yendapally Reddy Dhananjaya Reddy <yendapally.reddy-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
writes:
> Document the bindings used by Northstar Plus(NSP) SoC random number
> generator.
>
> Signed-off-by: Yendapally Reddy Dhananjaya Reddy <yendapally.reddy-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Acked-by: Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply
* Re: [PATCH 4/4] hwrng: bcm2835: Read as much data as available
From: Eric Anholt @ 2016-05-24 2:21 UTC (permalink / raw)
To: Yendapally Reddy Dhananjaya Reddy, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Stephen Warren, Lee Jones,
Russell King, Ray Jui, Scott Branden, Jon Mason, Matt Mackall,
Herbert Xu, Daniel Thompson, Kieran Bingham, Pankaj Dev,
Richard Weinberger, noltari, Joshua Henderson
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list, linux-crypto,
Yendapally Reddy Dhananjaya Reddy
In-Reply-To: <1464020451-16520-5-git-send-email-yendapally.reddy@broadcom.com>
[-- Attachment #1: Type: text/plain, Size: 1412 bytes --]
Yendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com>
writes:
> Read the requested number of data from the fifo
>
> Signed-off-by: Yendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com>
> ---
> drivers/char/hw_random/bcm2835-rng.c | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/char/hw_random/bcm2835-rng.c b/drivers/char/hw_random/bcm2835-rng.c
> index b1e8b78..9bbdc07 100644
> --- a/drivers/char/hw_random/bcm2835-rng.c
> +++ b/drivers/char/hw_random/bcm2835-rng.c
> @@ -43,6 +43,8 @@ static int bcm2835_rng_read(struct hwrng *rng, void *buf, size_t max,
> bool wait)
> {
> void __iomem *rng_base = (void __iomem *)rng->priv;
> + u32 max_words = max/sizeof(u32);
Style fix: Binary operators get a space on each side, so
"max / sizeof(u32);"
> @@ -50,8 +52,14 @@ static int bcm2835_rng_read(struct hwrng *rng, void *buf, size_t max,
> cpu_relax();
> }
>
> - *(u32 *)buf = __raw_readl(rng_base + RNG_DATA);
> - return sizeof(u32);
> + num_words = (readl(rng_base + RNG_STATUS) >> 24);
Optional cleanup: here and in the return statement, drop the extra
parenthesis.
Functionality-wise, this patch looks great to me, and should make the
driver more efficient. With at least the binary operators change done,
it will be:
Reviewed-by: Eric Anholt <eric@anholt.net>
Thanks!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply
* Re: [PATCH 2/4] hwrng: bcm2835: Support Broadcom NSP SoC rng
From: Eric Anholt @ 2016-05-24 2:14 UTC (permalink / raw)
To: Yendapally Reddy Dhananjaya Reddy, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Stephen Warren, Lee Jones,
Russell King, Ray Jui, Scott Branden, Jon Mason, Matt Mackall,
Herbert Xu, Daniel Thompson, Kieran Bingham, Pankaj Dev,
Richard Weinberger, noltari-Re5JQEeQqe8AvxtiuMwx3w,
Joshua Henderson
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
Yendapally Reddy Dhananjaya Reddy
In-Reply-To: <1464020451-16520-3-git-send-email-yendapally.reddy-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 559 bytes --]
Yendapally Reddy Dhananjaya Reddy <yendapally.reddy-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
writes:
> This supports the random number generator available in NSP SoC.
> Masks the rng interrupt for NSP.
The interrupt reg is also present on the 2835. I would prefer for
simplicity if you also initialized the register to the same value on the
Pi, even though the firmware has presumably been setting it for us
already.
However, this patch is still correct and I'm fine with it, so it's:
Acked-by: Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: rng: Northstar Plus SoC rng bindings
From: Rob Herring @ 2016-05-23 21:39 UTC (permalink / raw)
To: Yendapally Reddy Dhananjaya Reddy
Cc: Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Stephen Warren, Lee Jones, Eric Anholt, Russell King, Ray Jui,
Scott Branden, Jon Mason, Matt Mackall, Herbert Xu,
Daniel Thompson, Kieran Bingham, Pankaj Dev, Richard Weinberger,
noltari, Joshua Henderson, devicetree, linux-rpi-kernel,
linux-arm-kernel, linux-kernel, bcm-kernel-feedback-list,
linux-crypt
In-Reply-To: <1464020451-16520-2-git-send-email-yendapally.reddy@broadcom.com>
On Mon, May 23, 2016 at 12:20:48PM -0400, Yendapally Reddy Dhananjaya Reddy wrote:
> Document the bindings used by Northstar Plus(NSP) SoC random number
> generator.
>
> Signed-off-by: Yendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com>
> ---
> Documentation/devicetree/bindings/rng/brcm,bcm2835.txt | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH] hwrng: stm32 - fix build warning
From: Arnd Bergmann @ 2016-05-23 20:35 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Sudip Mukherjee, Matt Mackall, Herbert Xu, Maxime Coquelin,
linux-kernel, linux-crypto
In-Reply-To: <1464007448-25395-1-git-send-email-sudipm.mukherjee@gmail.com>
On Monday, May 23, 2016 6:14:08 PM CEST Sudip Mukherjee wrote:
> We have been getting build warning about:
> drivers/char/hw_random/stm32-rng.c: In function 'stm32_rng_read':
> drivers/char/hw_random/stm32-rng.c:82:19: warning: 'sr' may be used
> uninitialized in this function
>
> On checking the code it turns out that sr can never be used
> uninitialized as sr is getting initialized in the while loop and while
> loop will always execute as the minimum value of max can be 32.
> So just initialize sr to 0 while declaring it to silence the compiler.
>
> Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
> ---
I notice that you are using a really old compiler. While this warning
seems to be valid in the sense that the compiler should figure out that
the variable might be used uninitialized, please update your toolchain
before reporting other such problems, as gcc-4.6 had a lot more false
positives that newer ones (5.x or 6.x) have.
>
> build log at:
> https://travis-ci.org/sudipm-mukherjee/parport/jobs/132180906
>
> drivers/char/hw_random/stm32-rng.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/char/hw_random/stm32-rng.c b/drivers/char/hw_random/stm32-rng.c
> index 92a8106..0533370 100644
> --- a/drivers/char/hw_random/stm32-rng.c
> +++ b/drivers/char/hw_random/stm32-rng.c
> @@ -52,7 +52,7 @@ static int stm32_rng_read(struct hwrng *rng, void *data, size_t max, bool wait)
> {
> struct stm32_rng_private *priv =
> container_of(rng, struct stm32_rng_private, rng);
> - u32 sr;
> + u32 sr = 0;
> int retval = 0;
>
> pm_runtime_get_sync((struct device *) priv->rng.priv);
Does this work as well?
diff --git a/drivers/char/hw_random/stm32-rng.c b/drivers/char/hw_random/stm32-rng.c
index 92a810648bd0..5c836b0afa40 100644
--- a/drivers/char/hw_random/stm32-rng.c
+++ b/drivers/char/hw_random/stm32-rng.c
@@ -79,7 +79,7 @@ static int stm32_rng_read(struct hwrng *rng, void *data, size_t max, bool wait)
max -= sizeof(u32);
}
- if (WARN_ONCE(sr & (RNG_SR_SEIS | RNG_SR_CEIS),
+ if (WARN_ONCE(retval > 0 && (sr & (RNG_SR_SEIS | RNG_SR_CEIS)),
"bad RNG status - %x\n", sr))
writel_relaxed(0, priv->base + RNG_SR);
I think it would be nicer to not add a bogus initialization.
Arnd
^ permalink raw reply related
* Re: [PATCH v6 0/3] Key-agreement Protocol Primitives (KPP) API
From: Stephan Mueller @ 2016-05-23 20:33 UTC (permalink / raw)
To: Benedetto, Salvatore
Cc: herbert@gondor.apana.org.au, linux-crypto@vger.kernel.org
In-Reply-To: <309B30E91F5E2846B79BD9AA9711D0319181FB@IRSMSX102.ger.corp.intel.com>
Am Montag, 23. Mai 2016, 20:26:15 schrieb Benedetto, Salvatore:
Hi Salvatore,
>
> http://permalink.gmane.org/gmane.linux.kernel.lsm/27456
>
> As mentioned in the cover letter of that patch, KEYCTL_DH_COMPUTE will be
> converted to kpp once accepted.
Ok, I have overlooked that one :-)
Nevermind then and thanks
Ciao
Stephan
^ permalink raw reply
* RE: [PATCH v6 0/3] Key-agreement Protocol Primitives (KPP) API
From: Benedetto, Salvatore @ 2016-05-23 20:26 UTC (permalink / raw)
To: Stephan Mueller
Cc: herbert@gondor.apana.org.au, linux-crypto@vger.kernel.org,
Benedetto, Salvatore
In-Reply-To: <8688641.Yei9vfB8rY@positron.chronox.de>
Hi Stephan,
> -----Original Message-----
> From: Stephan Mueller [mailto:smueller@chronox.de]
> Sent: Monday, May 23, 2016 7:44 PM
> To: Benedetto, Salvatore <salvatore.benedetto@intel.com>
> Cc: herbert@gondor.apana.org.au; linux-crypto@vger.kernel.org
> Subject: Re: [PATCH v6 0/3] Key-agreement Protocol Primitives (KPP) API
>
> Am Mittwoch, 11. Mai 2016, 08:26:00 schrieb Salvatore Benedetto:
>
> Hi Salvatore,
>
> > Hi Herb,
> >
> > the following patchset introduces a new API for abstracting
> > key-agreement protocols such as DH and ECDH. It provides the
> > primitives required for implementing the protocol, thus the name KPP
> > (Key-agreement Protocol Primitives).
>
> I just saw that in Linus' tree, a DH implementation popped up at
> security/keys/dh.c
>
> Note, the implementation is also from an Intel developer.
>
> Would it make sense that both implementations are synced so that we only
> have one and that we need to worry about side channels only once?
>
http://permalink.gmane.org/gmane.linux.kernel.lsm/27456
As mentioned in the cover letter of that patch, KEYCTL_DH_COMPUTE will be converted
to kpp once accepted.
Regards,
Salvatore
^ permalink raw reply
* key retention service: DH support
From: Stephan Mueller @ 2016-05-23 18:57 UTC (permalink / raw)
To: dhowells; +Cc: keyrings, linux-crypto
Hi David,
With the new DH support for the key retention service, support for DH derived
keys pops up.
The implementation in security/keys/dh.c returns the DH shared secret straight
to the user space caller.
I implemented a KDF with that exact scenario already in mind: [1].
I am wondering whether the shared secret should be processed by a KDF before
returning the data to user space?
[1] http://www.chronox.de/kdf.html
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH v6 0/3] Key-agreement Protocol Primitives (KPP) API
From: Stephan Mueller @ 2016-05-23 18:44 UTC (permalink / raw)
To: Salvatore Benedetto; +Cc: herbert, linux-crypto
In-Reply-To: <1462951563-50042-1-git-send-email-salvatore.benedetto@intel.com>
Am Mittwoch, 11. Mai 2016, 08:26:00 schrieb Salvatore Benedetto:
Hi Salvatore,
> Hi Herb,
>
> the following patchset introduces a new API for abstracting key-agreement
> protocols such as DH and ECDH. It provides the primitives required for
> implementing the protocol, thus the name KPP (Key-agreement Protocol
> Primitives).
I just saw that in Linus' tree, a DH implementation popped up at
security/keys/dh.c
Note, the implementation is also from an Intel developer.
Would it make sense that both implementations are synced so that we only have
one and that we need to worry about side channels only once?
Ciao
Stephan
^ permalink raw reply
* [PATCH] hwrng: stm32 - fix build warning
From: Sudip Mukherjee @ 2016-05-23 12:44 UTC (permalink / raw)
To: Matt Mackall, Herbert Xu, Maxime Coquelin
Cc: linux-kernel, linux-crypto, linux-arm-kernel, Sudip Mukherjee
We have been getting build warning about:
drivers/char/hw_random/stm32-rng.c: In function 'stm32_rng_read':
drivers/char/hw_random/stm32-rng.c:82:19: warning: 'sr' may be used
uninitialized in this function
On checking the code it turns out that sr can never be used
uninitialized as sr is getting initialized in the while loop and while
loop will always execute as the minimum value of max can be 32.
So just initialize sr to 0 while declaring it to silence the compiler.
Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
---
build log at:
https://travis-ci.org/sudipm-mukherjee/parport/jobs/132180906
drivers/char/hw_random/stm32-rng.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/hw_random/stm32-rng.c b/drivers/char/hw_random/stm32-rng.c
index 92a8106..0533370 100644
--- a/drivers/char/hw_random/stm32-rng.c
+++ b/drivers/char/hw_random/stm32-rng.c
@@ -52,7 +52,7 @@ static int stm32_rng_read(struct hwrng *rng, void *data, size_t max, bool wait)
{
struct stm32_rng_private *priv =
container_of(rng, struct stm32_rng_private, rng);
- u32 sr;
+ u32 sr = 0;
int retval = 0;
pm_runtime_get_sync((struct device *) priv->rng.priv);
--
1.9.1
^ permalink raw reply related
* [PATCH 3/4] ARM: dts: nsp: Add rng device tree entry
From: Yendapally Reddy Dhananjaya Reddy @ 2016-05-23 16:20 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Stephen Warren, Lee Jones, Eric Anholt, Russell King, Ray Jui,
Scott Branden, Jon Mason, Matt Mackall, Herbert Xu,
Daniel Thompson, Kieran Bingham, Pankaj Dev, Richard Weinberger,
noltari, Joshua Henderson
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list, linux-crypto,
Yendapally Reddy Dhananjaya Reddy
In-Reply-To: <1464020451-16520-1-git-send-email-yendapally.reddy@broadcom.com>
Add support for the random number generator to the Northstar Plus
SoC device tree.
Signed-off-by: Yendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com>
---
arch/arm/boot/dts/bcm-nsp.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
index def9e78..1ed829e 100644
--- a/arch/arm/boot/dts/bcm-nsp.dtsi
+++ b/arch/arm/boot/dts/bcm-nsp.dtsi
@@ -206,6 +206,11 @@
brcm,nand-has-wp;
};
+ rng: rng@33000 {
+ compatible = "brcm,bcm-nsp-rng";
+ reg = <0x33000 0x14>;
+ };
+
ccbtimer0: timer@34000 {
compatible = "arm,sp804";
reg = <0x34000 0x1000>;
--
2.1.0
^ permalink raw reply related
* [PATCH 4/4] hwrng: bcm2835: Read as much data as available
From: Yendapally Reddy Dhananjaya Reddy @ 2016-05-23 16:20 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Stephen Warren, Lee Jones, Eric Anholt, Russell King, Ray Jui,
Scott Branden, Jon Mason, Matt Mackall, Herbert Xu,
Daniel Thompson, Kieran Bingham, Pankaj Dev, Richard Weinberger,
noltari, Joshua Henderson
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list, linux-crypto,
Yendapally Reddy Dhananjaya Reddy
In-Reply-To: <1464020451-16520-1-git-send-email-yendapally.reddy@broadcom.com>
Read the requested number of data from the fifo
Signed-off-by: Yendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com>
---
drivers/char/hw_random/bcm2835-rng.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/char/hw_random/bcm2835-rng.c b/drivers/char/hw_random/bcm2835-rng.c
index b1e8b78..9bbdc07 100644
--- a/drivers/char/hw_random/bcm2835-rng.c
+++ b/drivers/char/hw_random/bcm2835-rng.c
@@ -43,6 +43,8 @@ static int bcm2835_rng_read(struct hwrng *rng, void *buf, size_t max,
bool wait)
{
void __iomem *rng_base = (void __iomem *)rng->priv;
+ u32 max_words = max/sizeof(u32);
+ u32 num_words, count;
while ((__raw_readl(rng_base + RNG_STATUS) >> 24) == 0) {
if (!wait)
@@ -50,8 +52,14 @@ static int bcm2835_rng_read(struct hwrng *rng, void *buf, size_t max,
cpu_relax();
}
- *(u32 *)buf = __raw_readl(rng_base + RNG_DATA);
- return sizeof(u32);
+ num_words = (readl(rng_base + RNG_STATUS) >> 24);
+ if (num_words > max_words)
+ num_words = max_words;
+
+ for (count = 0; count < num_words; count++)
+ ((u32 *)buf)[count] = readl(rng_base + RNG_DATA);
+
+ return (num_words * sizeof(u32));
}
static struct hwrng bcm2835_rng_ops = {
--
2.1.0
^ permalink raw reply related
* [PATCH 2/4] hwrng: bcm2835: Support Broadcom NSP SoC rng
From: Yendapally Reddy Dhananjaya Reddy @ 2016-05-23 16:20 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Stephen Warren, Lee Jones, Eric Anholt, Russell King, Ray Jui,
Scott Branden, Jon Mason, Matt Mackall, Herbert Xu,
Daniel Thompson, Kieran Bingham, Pankaj Dev, Richard Weinberger,
noltari, Joshua Henderson
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list, linux-crypto,
Yendapally Reddy Dhananjaya Reddy
In-Reply-To: <1464020451-16520-1-git-send-email-yendapally.reddy@broadcom.com>
This supports the random number generator available in NSP SoC.
Masks the rng interrupt for NSP.
Signed-off-by: Yendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com>
---
drivers/char/hw_random/Kconfig | 2 +-
drivers/char/hw_random/bcm2835-rng.c | 34 ++++++++++++++++++++++++++++++----
2 files changed, 31 insertions(+), 5 deletions(-)
diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index 67ee8b0..f8d1a2b 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -90,7 +90,7 @@ config HW_RANDOM_BCM63XX
config HW_RANDOM_BCM2835
tristate "Broadcom BCM2835 Random Number Generator support"
- depends on ARCH_BCM2835
+ depends on ARCH_BCM2835 || ARCH_BCM_NSP
default HW_RANDOM
---help---
This driver provides kernel-side support for the Random Number
diff --git a/drivers/char/hw_random/bcm2835-rng.c b/drivers/char/hw_random/bcm2835-rng.c
index 7192ec2..b1e8b78 100644
--- a/drivers/char/hw_random/bcm2835-rng.c
+++ b/drivers/char/hw_random/bcm2835-rng.c
@@ -19,6 +19,7 @@
#define RNG_CTRL 0x0
#define RNG_STATUS 0x4
#define RNG_DATA 0x8
+#define RNG_INT_MASK 0x10
/* enable rng */
#define RNG_RBGEN 0x1
@@ -26,6 +27,18 @@
/* the initial numbers generated are "less random" so will be discarded */
#define RNG_WARMUP_COUNT 0x40000
+#define RNG_INT_OFF 0x1
+
+static void __init nsp_rng_init(void __iomem *base)
+{
+ u32 val;
+
+ /* mask the interrupt */
+ val = readl(base + RNG_INT_MASK);
+ val |= RNG_INT_OFF;
+ writel(val, base + RNG_INT_MASK);
+}
+
static int bcm2835_rng_read(struct hwrng *rng, void *buf, size_t max,
bool wait)
{
@@ -46,10 +59,18 @@ static struct hwrng bcm2835_rng_ops = {
.read = bcm2835_rng_read,
};
+static const struct of_device_id bcm2835_rng_of_match[] = {
+ { .compatible = "brcm,bcm2835-rng"},
+ { .compatible = "brcm,bcm-nsp-rng", .data = nsp_rng_init},
+ {},
+};
+
static int bcm2835_rng_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct device_node *np = dev->of_node;
+ void (*rng_setup)(void __iomem *base);
+ const struct of_device_id *rng_id;
void __iomem *rng_base;
int err;
@@ -61,6 +82,15 @@ static int bcm2835_rng_probe(struct platform_device *pdev)
}
bcm2835_rng_ops.priv = (unsigned long)rng_base;
+ rng_id = of_match_node(bcm2835_rng_of_match, np);
+ if (!rng_id)
+ return -EINVAL;
+
+ /* Check for rng init function, execute it */
+ rng_setup = rng_id->data;
+ if (rng_setup)
+ rng_setup(rng_base);
+
/* set warm-up count & enable */
__raw_writel(RNG_WARMUP_COUNT, rng_base + RNG_STATUS);
__raw_writel(RNG_RBGEN, rng_base + RNG_CTRL);
@@ -90,10 +120,6 @@ static int bcm2835_rng_remove(struct platform_device *pdev)
return 0;
}
-static const struct of_device_id bcm2835_rng_of_match[] = {
- { .compatible = "brcm,bcm2835-rng", },
- {},
-};
MODULE_DEVICE_TABLE(of, bcm2835_rng_of_match);
static struct platform_driver bcm2835_rng_driver = {
--
2.1.0
^ permalink raw reply related
* [PATCH 1/4] dt-bindings: rng: Northstar Plus SoC rng bindings
From: Yendapally Reddy Dhananjaya Reddy @ 2016-05-23 16:20 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Stephen Warren, Lee Jones, Eric Anholt, Russell King, Ray Jui,
Scott Branden, Jon Mason, Matt Mackall, Herbert Xu,
Daniel Thompson, Kieran Bingham, Pankaj Dev, Richard Weinberger,
noltari, Joshua Henderson
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list, linux-crypto,
Yendapally Reddy Dhananjaya Reddy
In-Reply-To: <1464020451-16520-1-git-send-email-yendapally.reddy@broadcom.com>
Document the bindings used by Northstar Plus(NSP) SoC random number
generator.
Signed-off-by: Yendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com>
---
Documentation/devicetree/bindings/rng/brcm,bcm2835.txt | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/rng/brcm,bcm2835.txt b/Documentation/devicetree/bindings/rng/brcm,bcm2835.txt
index 07ccdaa..aa304d4 100644
--- a/Documentation/devicetree/bindings/rng/brcm,bcm2835.txt
+++ b/Documentation/devicetree/bindings/rng/brcm,bcm2835.txt
@@ -2,7 +2,7 @@ BCM2835 Random number generator
Required properties:
-- compatible : should be "brcm,bcm2835-rng"
+- compatible : should be "brcm,bcm2835-rng" or "brcm,bcm-nsp-rng"
- reg : Specifies base physical address and size of the registers.
Example:
@@ -11,3 +11,8 @@ rng {
compatible = "brcm,bcm2835-rng";
reg = <0x7e104000 0x10>;
};
+
+rng@18033000 {
+ compatible = "brcm,bcm-nsp-rng";
+ reg = <0x18033000 0x14>;
+};
--
2.1.0
^ permalink raw reply related
* [PATCH 0/4] hw rng support for NSP SoC
From: Yendapally Reddy Dhananjaya Reddy @ 2016-05-23 16:20 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Stephen Warren, Lee Jones, Eric Anholt, Russell King, Ray Jui,
Scott Branden, Jon Mason, Matt Mackall, Herbert Xu,
Daniel Thompson, Kieran Bingham, Pankaj Dev, Richard Weinberger,
noltari, Joshua Henderson
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list, linux-crypto,
Yendapally Reddy Dhananjaya Reddy
This patchset contains the hw random number generator support for the
Broadcom's NSP SoC. The block is similar to the block available in
bcm2835 with different default interrupt mask value. Due to lack of
documentation, I cannot confirm the interrupt mask register details
in bcm2835. In an effort to not break the existing functionality of
bcm2835, I used a different compatible string to mask the interrupt
for NSP SoC. Please let me know. Also supported providing requested
number of random numbers instead of static size of four bytes.
The first patch contains the documentation changes and the second patch
contains the support for rng available in NSP SoC. The third patch
contains the device tree changes for NSP SoC. The fourth patch contains
the support for reading requested number of random numbers.
This patch set has been tested on NSP bcm958625HR board.
This patch set is based on v4.6.0-rc1 and is available from github
repo: https://github.com/Broadcom/cygnus-linux.git
branch: nsp-rng-v1
Yendapally Reddy Dhananjaya Reddy (4):
dt-bindings: rng: Northstar Plus SoC rng bindings
hwrng: bcm2835: Support Broadcom NSP SoC rng
ARM: dts: nsp: Add rng device tree entry
hwrng: bcm2835: Read as much data as available
.../devicetree/bindings/rng/brcm,bcm2835.txt | 7 +++-
arch/arm/boot/dts/bcm-nsp.dtsi | 5 +++
drivers/char/hw_random/Kconfig | 2 +-
drivers/char/hw_random/bcm2835-rng.c | 46 +++++++++++++++++++---
4 files changed, 52 insertions(+), 8 deletions(-)
--
2.1.0
^ permalink raw reply
* Re: IV generation in cryptographic driver in AEAD
From: Gary R Hook @ 2016-05-23 13:27 UTC (permalink / raw)
To: Herbert Xu; +Cc: Denis B, linux-crypto
In-Reply-To: <20160520233132.GA18006@gondor.apana.org.au>
On 05/20/2016 06:31 PM, Herbert Xu wrote:
> On Fri, May 20, 2016 at 10:50:38AM -0500, Gary R Hook wrote:
>>
>> Why is (or should) setting geniv (be) required?
>>
>> crypto_givcipher_default() appears to call crypto_default_geniv() if
>> the geniv member
>> is NULL. That function returns "eseqiv" or "chainiv" (under certain
>> conditions). If an
>> implementation isn't generating its own IVs, shouldn't the default
>> happen anyway? Or is
>> this more a matter of populating the structure with known,
>> intentional values?
>>
>> Thank you for any illumination provided.
>
> In the upstream kernel AEAD geniv has been completely phased out
> and no longer exists. Denis is working on an old kernel that still
> has it.
>
> We haven't yet phased it out for skcipher but I'm working on it.
...and there was light.
Thank you; very helpful.
(I'll work harder on my line wraps... If someone knows how to get
Thunderbird
to do it for me, I'd love to know.)
^ permalink raw reply
* Re: [PATCH] crypto: ccp - Fix AES XTS error for request sizes above 4096
From: Tom Lendacky @ 2016-05-23 13:50 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto, Gary Hook, David Miller
In-Reply-To: <20160520233543.GB18006@gondor.apana.org.au>
On 05/20/2016 06:35 PM, Herbert Xu wrote:
> On Fri, May 20, 2016 at 05:33:03PM -0500, Tom Lendacky wrote:
>> The ccp-crypto module for AES XTS support has a bug that can allow requests
>> greater than 4096 bytes in size to be passed to the CCP hardware. The CCP
>> hardware does not support request sizes larger than 4096, resulting in
>> incorrect output. The request should actually be handled by the fallback
>> mechanism instantiated by the ccp-crypto module.
>>
>> Add a check to insure the request size is less than or equal to the maximum
>> supported size and use the fallback mechanism if it is not.
>>
>> Cc: <stable@vger.kernel.org> # 3.14.x-
>> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
>
> I'm OK with this patch but I think it doesn't always need to go into
> the fallback. I made a test vector split as 4064 bytes + 48 bytes
> and ccp handled it just fine. It appears that the bug is actually
> in the handling of a single SG entry that's longer than a page,
> presumably because sg_next is used unconditionally instead of
> checking whether there is more in the current SG entry.
I'll take a closer look at this. Something obviously isn't right but
the code doesn't do anything related to PAGE size checks and works
on the length specified in the SG entry.
>
> But I'll merge your fix as it fixes a real problem.
Thanks Herbert.
Tom
>
> Thanks,
>
^ permalink raw reply
* RE: [PATCH v6 0/3] crypto: caam - add support for RSA algorithm
From: Tudor-Dan Ambarus @ 2016-05-23 12:56 UTC (permalink / raw)
To: Stephan Mueller
Cc: herbert@gondor.apana.org.au, linux-crypto@vger.kernel.org,
Horia Ioan Geanta Neag
In-Reply-To: <2370625.CgO9A4qjJ6@positron.chronox.de>
Hi Stephan,
> as I am looking into the RSA countermeasures, I am wondering how much of
> countermeasures are actually applied inside hardware implementations.
Please point me to the reference RSA countermeasures so that we have
a common point of start.
Thanks,
ta
^ 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