Re: [RFC] /dev/random for in-kernel use

2014-04-28 Thread Stephan Mueller 
Am Sonntag, 27. April 2014, 20:19:41 schrieb Theodore Ts'o:

Hi Theodore,

 On Sun, Apr 27, 2014 at 08:49:48PM +0200, Stephan Mueller wrote:
  With the heavy update of random.c during the 3.13 development, the
  re-seeding of the nonblocking_pool from the input_pool is now prevented
  for a duration of random_min_urandom_seed seconds. Furthermore, the
  nonblocking_pool can be read from user space such that it acts as a
  deterministic RNG due to the non- blocking behavior if more data is
  pulled than is delivered by the noise sources. As the nonblocking_pool is
  used when a in-kernel user invokes get_random_bytes, the described
  deterministic behavior also applies to this function.
 
 This actually wasn't a major change.  If you are drawing sufficiently
 heavily from /dev/urandom (and some crypto libraries draw _very_
 heavily; the Chrome browser in particular draws from /dev/urandom
 quite liberally), then you'll end up drawing from the input pool
 faster than it can be filled from noise sources anyway.  So the rate
 limiting wasn't making a material difference as far as the quality of
 /dev/urandom and get_random_bytes() is concerned.  What it does do is
 allow users of /dev/random (such as gpg key generaiton) to complete in
 a reasonable time.

Thanks for clarifying this. I agree that the change is immaterial considering 
a random number hog in user space with respect to the deterministic 
behavior.
 
 However, given that we're reseeding once a minute (or as needed), it's
 actually not a deterministic RNG (per SP 800-90A, section 8.6.5, a
 DRBG is forbidden to reseed itself automatically).

To be honest, I do not read that in this section. Moreover, a DRBG must reseed 
itself -- the caller shall only have the ability to add additional data or 
trigger a reseeding earlier (the proposed DRBG implementation directly draws 
from get_random_bytes automatically). But this is a different topic and we 
should disregard it for the moment.
 
  Now, get_random_bytes is the only function inside the kernel that can
  deliver entropy. For most use cases, the described approach is just fine.
  However, when using well defined deterministic RNGs, like the already
  existing ANSI X9.31 or the suggested SP800-90A DRBG, seeding these DRNGs
  from the DRNG of the nonblocking_pool is typically not a suggested way.
  This is visible in user space where /dev/random is preferred when seeding
  deterministic RNGs (see libgcrypt as an example).
 
 Well, as far as SP800-90A DRBG is concerned, using either the logical
 equivalent of /dev/random or /dev/urandom is not allowed, since
 neither is a approved entropy source.  (Then again, given that NIST
 approved Dual-EC, I'm not sure how much I'm impressed by a NIST
 approval, but whatever.  :-) But if your goal is to get the NIST

Well spoken words :-)

Considering that approved entropy sources have to comply with SP800-90B and C, 
I have prepared already some analyses of random.c whether the blocking or the 
nonblocking pool meets these requirements. Using several system tap scripts, 
the statistical behavior of the noise sources and the pool distributions look 
appropriate. In addition, some theoretical analyses showed that the blocking 
pool (considering the blocking behavior) would meet the requirements of 
SP800-90B/C whereas the nonblocking pool does not.

Anticipating that the compliance to SP800-90B/C would be required for a 
successful FIPS validation somewhen in the future, making the blocking 
behavior available to in-kernel users would be of interest.

 certification, which IMHO should only matter if you are selling to the
 US government, it really can really only use RDRAND on Intel platforms
 --- i.e., get_random_bytes_arch().

I am not too convinced of RDRAND due to the lack of usable source code (i.e. 
source code that I can build myself). But that is my personal taste :-)
 
 That being said, if some kernel module really wants to get its hands
 on entropy extracted from the blocking pool, I don't see any reason
 why we shouldn't deny them that functionality.
 
  Therefore may I propose the implementation of the blocking concept of
  /dev/random as a provider of entropy to in-kernel callers like DRNGs? I
  would recommend a function of
  
  void get_blocking_bytes_nowait(void *buf, int nbytes,
  
  void (*cb)(void *buf, int buflen))
 
 Let me make a counter proposal.  Let's instead provide a blocking
 interface:

[...]

Thanks for these suggestions. Shall I take these suggestions and turn them 
into a full patch?

Moreover, I read that even for in-kernel users we should use the blocking 
pool. Or shall we conceive of a third output pool, say, a kernel pool that is 
independent of the output pools to user space? Adding such a pool more or less 
only requires to define a new struct entropy_pool instance.

Ciao
Stephan
-- 
| Cui bono? |
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org

Re: [RFC PATCH v2 4/9] crypto: qce: Add ablkcipher algorithms

2014-04-28 Thread Herbert Xu 
On Mon, Apr 14, 2014 at 03:48:40PM +0300, Stanimir Varbanov wrote:

 + if (IS_AES(flags)) {
 + switch (keylen) {
 + case AES_KEYSIZE_128:
 + case AES_KEYSIZE_256:
 + break;
 + default:
 + goto badkey;

You need to support 192 here.  If the hardware doesn't do that
you can work around it by using a software fallback.

In general you need to provide everything that is supported by
the generic software implementation.

Cheers,
-- 
Email: Herbert Xu herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v2 4/9] crypto: qce: Add ablkcipher algorithms

2014-04-28 Thread Herbert Xu 
On Mon, Apr 14, 2014 at 03:48:40PM +0300, Stanimir Varbanov wrote:

 + } else if (IS_DES(flags)) {
 + u32 tmp[DES_EXPKEY_WORDS];
 +
 + if (keylen != QCE_DES_KEY_SIZE)
 + goto badkey;

No need to check here since you've already set min_keysize and
max_keysize correctly.

 + } else if (IS_3DES(flags)) {
 + if (keylen != DES3_EDE_KEY_SIZE)
 + goto badkey;

Ditto.

Cheers,
-- 
Email: Herbert Xu herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v2 1/9] crypto: qce: Add core driver implementation

2014-04-28 Thread Herbert Xu 
On Mon, Apr 14, 2014 at 03:48:37PM +0300, Stanimir Varbanov wrote:

 + if (backlog)
 + backlog-complete(backlog, -EINPROGRESS);

The completion function needs to be called with BH disabled.

Cheers,
-- 
Email: Herbert Xu herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v2 1/9] crypto: qce: Add core driver implementation

2014-04-28 Thread Herbert Xu 
On Mon, Apr 14, 2014 at 03:48:37PM +0300, Stanimir Varbanov wrote:

 +#define QCE_MAJOR_VERSION5   0x05
 +#define QCE_QUEUE_LENGTH 50

What is the purpose of this software queue? Why can't you directly
feed the requests to the hardware?

If the hardware can't handle more than 50 requests in-flight,
then your software queue has failed to handle this since you're
taking requests off the queue before you touch the hardware so
you're not really limiting it to 50.  That is, for users that
can wait you're potentially dropping their requests instead
of letting them wait through the backlog mechanism.

Cheers,
-- 
Email: Herbert Xu herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH crypto 2/2] crypto: caam - add allocation failure handling in SPRINTFCAT macro

2014-04-28 Thread Herbert Xu 
On Fri, Apr 18, 2014 at 01:01:42PM +0300, Horia Geanta wrote:
 GFP_ATOMIC memory allocation could fail.
 In this case, avoid NULL pointer dereference and notify user.
 
 Cc: sta...@vger.kernel.org # 3.2+
 Cc: Kim Phillips kim.phill...@freescale.com
 Signed-off-by: Horia Geanta horia.gea...@freescale.com

Patch applied to the crypto tree.  Thanks.
-- 
Email: Herbert Xu herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] crypto: atmel-aes: fixes on block size of aes cfb mode

2014-04-28 Thread Herbert Xu 
On Tue, Apr 22, 2014 at 03:23:22PM +0800, Leilei Zhao wrote:
 Hi:
 
 These two patches correct the block size in atmel-aes driver while processing 
 cfb8 and cfb64 mode of aes.

Both patches applied.  Thanks!
-- 
Email: Herbert Xu herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] Cleanup ressource leaks in test_aead_speed()

2014-04-28 Thread Herbert Xu 
On Mon, Apr 21, 2014 at 08:44:39PM +0200, Christian Engelmayer wrote:
 This is a cleanup of Coverity ressource leak findings for the quick  dirty
 crypto testing module crypto/tcrypt.c.
 
 All 3 changesets address function test_aead_speed() that was introduced in
 53f52d7a (crypto: tcrypt - Added speed tests for AEAD crypto alogrithms in
 tcrypt test suite)

All applied.  Thanks!
-- 
Email: Herbert Xu herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 6/7 v8] crypto:s5p-sss: Use clk_prepare/clk_unprepare

2014-04-28 Thread Naveen Krishna Chatradhi 
This patch set adds use of clk_prepare/clk_unprepare as
required by generic clock framework.

Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
Acked-by: Herbert Xu herb...@gondor.apana.org.au
CC: David S. Miller da...@davemloft.net
CC: Vladimir Zapolskiy vzapols...@gmail.com
TO: linux-crypto@vger.kernel.org
CC: linux-samsung-...@vger.kernel.org
---
Changes since v7:
Added Acked-by from Herbert Xu
Changes since v6:
None

 drivers/crypto/s5p-sss.c |   10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index 0ffc042..ea7d478 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -645,7 +645,11 @@ static int s5p_aes_probe(struct platform_device *pdev)
return -ENOENT;
}
 
-   clk_enable(pdata-clk);
+   err = clk_prepare_enable(pdata-clk);
+   if (err  0) {
+   dev_err(dev, Enabling SSS clk failed, err %d\n, err);
+   return err;
+   }
 
spin_lock_init(pdata-lock);
 
@@ -706,7 +710,7 @@ static int s5p_aes_probe(struct platform_device *pdev)
tasklet_kill(pdata-tasklet);
 
  err_irq:
-   clk_disable(pdata-clk);
+   clk_disable_unprepare(pdata-clk);
 
s5p_dev = NULL;
 
@@ -726,7 +730,7 @@ static int s5p_aes_remove(struct platform_device *pdev)
 
tasklet_kill(pdata-tasklet);
 
-   clk_disable(pdata-clk);
+   clk_disable_unprepare(pdata-clk);
 
s5p_dev = NULL;
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/7 v8] crypto:s5p-sss: Kconfig: Let Exynos SoCs select SSS driver

2014-04-28 Thread Naveen Krishna Chatradhi 
This patch modifies Kconfig such that ARCH_EXYNOS SoCs
which includes (Exynos4210, Exynos5250 and Exynos5420)
can also select Samsung SSS(Security SubSystem) driver.

Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
Acked-by: Herbert Xu herb...@gondor.apana.org.au
CC: David S. Miller da...@davemloft.net
CC: Vladimir Zapolskiy vzapols...@gmail.com
TO: linux-crypto@vger.kernel.org
CC: linux-samsung-...@vger.kernel.org
---
Changes since v7:
Added Acked-by from Herbert Xu
Change since v6:
None
Change since v5:
None

 drivers/crypto/Kconfig |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 03ccdb0..f066fa2 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -301,14 +301,14 @@ config CRYPTO_DEV_SAHARA
  found in some Freescale i.MX chips.
 
 config CRYPTO_DEV_S5P
-   tristate Support for Samsung S5PV210 crypto accelerator
-   depends on ARCH_S5PV210
+   tristate Support for Samsung S5PV210/Exynos crypto accelerator
+   depends on ARCH_S5PV210 || ARCH_EXYNOS
select CRYPTO_AES
select CRYPTO_ALGAPI
select CRYPTO_BLKCIPHER
help
  This option allows you to have support for S5P crypto acceleration.
- Select this to offload Samsung S5PV210 or S5PC110 from AES
+ Select this to offload Samsung S5PV210 or S5PC110, Exynos from AES
  algorithms execution.
 
 config CRYPTO_DEV_NX
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 5/7 v8] crypto:s5p-sss: validate iv before memcpy

2014-04-28 Thread Naveen Krishna Chatradhi 
This patch adds code to validate iv buffer before trying to
memcpy the contents

Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
Acked-by: Herbert Xu herb...@gondor.apana.org.au
CC: David S. Miller da...@davemloft.net
CC: Vladimir Zapolskiy vzapols...@gmail.com
TO: linux-crypto@vger.kernel.org
CC: linux-samsung-...@vger.kernel.org
---
Changes since v7:
Added Acked-by from Herbert Xu
Changes since v6:
None

 drivers/crypto/s5p-sss.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index 37e0598..0ffc042 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -380,7 +380,8 @@ static void s5p_set_aes(struct s5p_aes_dev *dev,
 {
void __iomem *keystart;
 
-   memcpy(dev-aes_ioaddr + SSS_REG_AES_IV_DATA(0), iv, 0x10);
+   if (iv)
+   memcpy(dev-aes_ioaddr + SSS_REG_AES_IV_DATA(0), iv, 0x10);
 
if (keylen == AES_KEYSIZE_256)
keystart = dev-aes_ioaddr + SSS_REG_AES_KEY_DATA(0);
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 7/7 v8] crypto:s5p-sss: Look for the next request in the queue

2014-04-28 Thread Naveen Krishna Chatradhi 
Currently, the driver enqueues a request only if the busy bit is
false. And every request initiates a dequeue. If 2 requests arrive
simultaneously, only one of them will be dequeued.

To avoid this senario, we will enqueue the next request irrespective
of the system condition (that is what queue is here for). Also
schedule at a tasklet immediatly after the current request is done.
The tasklet will dequeue the next request in the queue, giving
continuous loop. tasklet will exit if there are no requests in the
queue.

Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Acked-by: Herbert Xu herb...@gondor.apana.org.au
CC: David S. Miller da...@davemloft.net
CC: Vladimir Zapolskiy vzapols...@gmail.com
TO: linux-crypto@vger.kernel.org
CC: linux-samsung-...@vger.kernel.org
---
Changes since v7:
Added Acked-by from Herbert Xu
Changes since v6:
None

 drivers/crypto/s5p-sss.c |   17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index ea7d478..47c568e 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -330,8 +330,12 @@ static void s5p_aes_tx(struct s5p_aes_dev *dev)
}
 
s5p_set_dma_outdata(dev, dev-sg_dst);
-   } else
+   } else {
s5p_aes_complete(dev, err);
+
+   dev-busy = true;
+   tasklet_schedule(dev-tasklet);
+   }
 }
 
 static void s5p_aes_rx(struct s5p_aes_dev *dev)
@@ -469,10 +473,13 @@ static void s5p_tasklet_cb(unsigned long data)
spin_lock_irqsave(dev-lock, flags);
backlog   = crypto_get_backlog(dev-queue);
async_req = crypto_dequeue_request(dev-queue);
-   spin_unlock_irqrestore(dev-lock, flags);
 
-   if (!async_req)
+   if (!async_req) {
+   dev-busy = false;
+   spin_unlock_irqrestore(dev-lock, flags);
return;
+   }
+   spin_unlock_irqrestore(dev-lock, flags);
 
if (backlog)
backlog-complete(backlog, -EINPROGRESS);
@@ -491,14 +498,13 @@ static int s5p_aes_handle_req(struct s5p_aes_dev *dev,
int err;
 
spin_lock_irqsave(dev-lock, flags);
+   err = ablkcipher_enqueue_request(dev-queue, req);
if (dev-busy) {
-   err = -EAGAIN;
spin_unlock_irqrestore(dev-lock, flags);
goto exit;
}
dev-busy = true;
 
-   err = ablkcipher_enqueue_request(dev-queue, req);
spin_unlock_irqrestore(dev-lock, flags);
 
tasklet_schedule(dev-tasklet);
@@ -683,6 +689,7 @@ static int s5p_aes_probe(struct platform_device *pdev)
}
}
 
+   pdata-busy = false;
pdata-variant = variant;
pdata-dev = dev;
platform_set_drvdata(pdev, pdata);
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/7 v8] crypto:s5p-sss: Add support for SSS module on Exynos

2014-04-28 Thread Naveen Krishna Chatradhi 
This patch adds new compatible and variant struct to support the SSS
module on Exynos4 (Exynos4210), Exynos5 (Exynos5420 and Exynos5250)
for which
1. AES register are at an offset of 0x200 and
2. hash interrupt is not available

Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
Acked-by: Herbert Xu herb...@gondor.apana.org.au
CC: David S. Miller da...@davemloft.net
CC: Vladimir Zapolskiy vzapols...@gmail.com
TO: linux-crypto@vger.kernel.org
CC: linux-samsung-...@vger.kernel.org
---
Changes since v7:
Added Acked-by from Herbert Xu
Change since v6:
None
Change since v5:
1. Rewritten the interrupt definition in the documentation
2. Added Reviewed-by: Tomasz Figa t.f...@samsung.com

 .../devicetree/bindings/crypto/samsung-sss.txt |   15 ++-
 drivers/crypto/s5p-sss.c   |  107 +++-
 2 files changed, 95 insertions(+), 27 deletions(-)

diff --git a/Documentation/devicetree/bindings/crypto/samsung-sss.txt 
b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
index 3876f71..1702773 100644
--- a/Documentation/devicetree/bindings/crypto/samsung-sss.txt
+++ b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
@@ -8,16 +8,25 @@ The SSS module in S5PV210 SoC supports the following:
 -- SHA-1/SHA-256/MD5/HMAC (SHA-1/SHA-256/MD5)/PRNG
 -- PRNG: Pseudo Random Number Generator
 
+The SSS module in Exynos4 (Exynos4210) and
+Exynos5 (Exynos5420 and Exynos5250) SoCs
+supports the following also:
+-- ARCFOUR (ARC4)
+-- True Random Number Generator (TRNG)
+-- Secure Key Manager
+
 Required properties:
 
 - compatible : Should contain entries for this and backward compatible
   SSS versions:
   - samsung,s5pv210-secss for S5PV210 SoC.
+  - samsung,exynos4210-secss for Exynos4210, Exynos4212, Exynos4412, 
Exynos5250,
+   Exynos5260 and Exynos5420 SoCs.
 - reg : Offset and length of the register set for the module
 - interrupts : interrupt specifiers of SSS module interrupts, should contain
-   two entries:
-   - first : feed control interrupt,
-   - second : hash interrupt.
+   following entries:
+   - first : feed control interrupt (required for all variants),
+   - second : hash interrupt (required only for 
samsung,s5pv210-secss).
 
 - clocks : list of clock phandle and specifier pairs for all clocks  listed in
clock-names property.
diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index c6aafe8..37e0598 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -106,7 +106,7 @@
 #define SSS_REG_FCPKDMAO0x005C
 
 /* AES registers */
-#define SSS_REG_AES_CONTROL 0x4000
+#define SSS_REG_AES_CONTROL0x00
 #define SSS_AES_BYTESWAP_DI _BIT(11)
 #define SSS_AES_BYTESWAP_DO _BIT(10)
 #define SSS_AES_BYTESWAP_IV _BIT(9)
@@ -122,21 +122,25 @@
 #define SSS_AES_CHAIN_MODE_CTR  _SBF(1, 0x02)
 #define SSS_AES_MODE_DECRYPT_BIT(0)
 
-#define SSS_REG_AES_STATUS  0x4004
+#define SSS_REG_AES_STATUS 0x04
 #define SSS_AES_BUSY_BIT(2)
 #define SSS_AES_INPUT_READY _BIT(1)
 #define SSS_AES_OUTPUT_READY_BIT(0)
 
-#define SSS_REG_AES_IN_DATA(s)  (0x4010 + (s  2))
-#define SSS_REG_AES_OUT_DATA(s) (0x4020 + (s  2))
-#define SSS_REG_AES_IV_DATA(s)  (0x4030 + (s  2))
-#define SSS_REG_AES_CNT_DATA(s) (0x4040 + (s  2))
-#define SSS_REG_AES_KEY_DATA(s) (0x4080 + (s  2))
+#define SSS_REG_AES_IN_DATA(s) (0x10 + (s  2))
+#define SSS_REG_AES_OUT_DATA(s)(0x20 + (s  2))
+#define SSS_REG_AES_IV_DATA(s) (0x30 + (s  2))
+#define SSS_REG_AES_CNT_DATA(s)(0x40 + (s  2))
+#define SSS_REG_AES_KEY_DATA(s)(0x80 + (s  2))
 
 #define SSS_REG(dev, reg)   ((dev)-ioaddr + (SSS_REG_##reg))
 #define SSS_READ(dev, reg)  __raw_readl(SSS_REG(dev, reg))
 #define SSS_WRITE(dev, reg, val)__raw_writel((val), SSS_REG(dev, reg))
 
+#define SSS_AES_REG(dev, reg)   ((dev)-aes_ioaddr + SSS_REG_##reg)
+#define SSS_AES_WRITE(dev, reg, val)__raw_writel((val), \
+   SSS_AES_REG(dev, reg))
+
 /* HW engine modes */
 #define FLAGS_AES_DECRYPT   _BIT(0)
 #define FLAGS_AES_MODE_MASK _SBF(1, 0x03)
@@ -146,6 +150,20 @@
 #define AES_KEY_LEN 16
 #define CRYPTO_QUEUE_LEN1
 
+/**
+ * struct samsung_aes_variant - platform specific SSS driver data
+ * @has_hash_irq: true if SSS module uses hash interrupt, false otherwise
+ * @aes_offset: AES register offset from SSS module's base.
+ *
+ * Specifies platform specific configuration of SSS module.
+ * Note: A structure for driver specific platform data is used for future
+ * expansion of its usage.
+ */
+struct samsung_aes_variant {
+

[PATCH 2/7 v8] crypto:s5p-sss: Add device tree support

2014-04-28 Thread Naveen Krishna Chatradhi 
This patch adds device tree support to the s5p-sss.c crypto driver.

Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Acked-by: Herbert Xu herb...@gondor.apana.org.au
CC: David S. Miller da...@davemloft.net
CC: Vladimir Zapolskiy vzapols...@gmail.com
TO: linux-crypto@vger.kernel.org
CC: linux-samsung-...@vger.kernel.org
---
Changes since v7:
Added Acked-by from Herbert Xu
Changes since v6:
None
Changes since v5:
Rewritten the interrupt definition in the documentation

 .../devicetree/bindings/crypto/samsung-sss.txt |   26 
 drivers/crypto/s5p-sss.c   |8 ++
 2 files changed, 34 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/crypto/samsung-sss.txt

diff --git a/Documentation/devicetree/bindings/crypto/samsung-sss.txt 
b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
new file mode 100644
index 000..3876f71
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
@@ -0,0 +1,26 @@
+Samsung SoC SSS (Security SubSystem) module
+
+The SSS module in S5PV210 SoC supports the following:
+-- Feeder (FeedCtrl)
+-- Advanced Encryption Standard (AES)
+-- Data Encryption Standard (DES)/3DES
+-- Public Key Accelerator (PKA)
+-- SHA-1/SHA-256/MD5/HMAC (SHA-1/SHA-256/MD5)/PRNG
+-- PRNG: Pseudo Random Number Generator
+
+Required properties:
+
+- compatible : Should contain entries for this and backward compatible
+  SSS versions:
+  - samsung,s5pv210-secss for S5PV210 SoC.
+- reg : Offset and length of the register set for the module
+- interrupts : interrupt specifiers of SSS module interrupts, should contain
+   two entries:
+   - first : feed control interrupt,
+   - second : hash interrupt.
+
+- clocks : list of clock phandle and specifier pairs for all clocks  listed in
+   clock-names property.
+- clock-names : list of device clock input names; should contain one entry
+   secss.
+
diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index 2876fa3..c6aafe8 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -22,6 +22,7 @@
 #include linux/scatterlist.h
 #include linux/dma-mapping.h
 #include linux/io.h
+#include linux/of.h
 #include linux/crypto.h
 #include linux/interrupt.h
 
@@ -177,6 +178,12 @@ struct s5p_aes_dev {
 
 static struct s5p_aes_dev *s5p_dev;
 
+static const struct of_device_id s5p_sss_dt_match[] = {
+   { .compatible = samsung,s5pv210-secss },
+   { },
+};
+MODULE_DEVICE_TABLE(of, s5p_sss_dt_match);
+
 static void s5p_set_dma_indata(struct s5p_aes_dev *dev, struct scatterlist *sg)
 {
SSS_WRITE(dev, FCBRDMAS, sg_dma_address(sg));
@@ -672,6 +679,7 @@ static struct platform_driver s5p_aes_crypto = {
.driver = {
.owner  = THIS_MODULE,
.name   = s5p-secss,
+   .of_match_table = s5p_sss_dt_match,
},
 };
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/7 v8] crypto:s5p-sss: Use platform_get_irq() instead of _byname()

2014-04-28 Thread Naveen Krishna Chatradhi 
This patch uses the platform_get_irq() instead of the
platform_get_irq_byname(). Making feeder control interrupt
as resource 0 and hash interrupt as 1.

reasons for this change.
1. Cannot find any Arch which is currently using this driver
2. Samsung Exynos4 and 5 SoCs only use the feeder control interrupt
3. Patches adding support for DT and H/W version are in pipeline

Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
Acked-by: Herbert Xu herb...@gondor.apana.org.au
CC: David S. Miller da...@davemloft.net
CC: Vladimir Zapolskiy vzapols...@gmail.com
TO: linux-crypto@vger.kernel.org
CC: linux-samsung-...@vger.kernel.org
---
Changes since v7:
Added Acked-by from Herbert Xu
Changes since v6:
None
Changes since v5:
None

 drivers/crypto/s5p-sss.c |   24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index be45762..2876fa3 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -587,29 +587,29 @@ static int s5p_aes_probe(struct platform_device *pdev)
 
spin_lock_init(pdata-lock);
 
-   pdata-irq_hash = platform_get_irq_byname(pdev, hash);
-   if (pdata-irq_hash  0) {
-   err = pdata-irq_hash;
-   dev_warn(dev, hash interrupt is not available.\n);
+   pdata-irq_fc = platform_get_irq(pdev, 0);
+   if (pdata-irq_fc  0) {
+   err = pdata-irq_fc;
+   dev_warn(dev, feed control interrupt is not available.\n);
goto err_irq;
}
-   err = devm_request_irq(dev, pdata-irq_hash, s5p_aes_interrupt,
+   err = devm_request_irq(dev, pdata-irq_fc, s5p_aes_interrupt,
   IRQF_SHARED, pdev-name, pdev);
if (err  0) {
-   dev_warn(dev, hash interrupt is not available.\n);
+   dev_warn(dev, feed control interrupt is not available.\n);
goto err_irq;
}
 
-   pdata-irq_fc = platform_get_irq_byname(pdev, feed control);
-   if (pdata-irq_fc  0) {
-   err = pdata-irq_fc;
-   dev_warn(dev, feed control interrupt is not available.\n);
+   pdata-irq_hash = platform_get_irq(pdev, 1);
+   if (pdata-irq_hash  0) {
+   err = pdata-irq_hash;
+   dev_warn(dev, hash interrupt is not available.\n);
goto err_irq;
}
-   err = devm_request_irq(dev, pdata-irq_fc, s5p_aes_interrupt,
+   err = devm_request_irq(dev, pdata-irq_hash, s5p_aes_interrupt,
   IRQF_SHARED, pdev-name, pdev);
if (err  0) {
-   dev_warn(dev, feed control interrupt is not available.\n);
+   dev_warn(dev, hash interrupt is not available.\n);
goto err_irq;
}
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] /dev/random for in-kernel use

2014-04-28 Thread Theodore Ts'o 
On Mon, Apr 28, 2014 at 08:00:19AM +0200, Stephan Mueller wrote:
  However, given that we're reseeding once a minute (or as needed), it's
  actually not a deterministic RNG (per SP 800-90A, section 8.6.5, a
  DRBG is forbidden to reseed itself automatically).
 
 To be honest, I do not read that in this section. Moreover, a DRBG must 
 reseed 
 itself -- the caller shall only have the ability to add additional data or 
 trigger a reseeding earlier (the proposed DRBG implementation directly draws 
 from get_random_bytes automatically). 

It seems pretty clear to me: 

   The source of the entropy input (EI) SHALL be either:
   ...

   3.  An approved DRBG, thus forming a chain of at least two DRBGs;
   the initial DRBG in the chain SHALL be seeded by an approved
   NRBG or an approved entropy source. A DRBG instantiation may
   seed or reseed another DRBG instantiation, but SHALL NOT reseed
   itself.

The last SHALL NOT is what makes me think that the DRBG shouldn't be
doing this automatically.  So if it is only being done via explicit
user request (i.e., an ioctl) then the blocking interface should be
sufficient.

 Anticipating that the compliance to SP800-90B/C would be required for a 
 successful FIPS validation somewhen in the future, making the blocking 
 behavior available to in-kernel users would be of interest.
 
 
 I am not too convinced of RDRAND due to the lack of usable source code (i.e. 
 source code that I can build myself). But that is my personal taste :-)

The problem is the FIPS validation would presumably require obeying
the SP-800A requirement for an approved entropy source, and while we
can't audit RDRAND to satisfy ourselves that the US government hasn't
introduced a back door, if the only purpose of the FIPS validation is
so that people can sell into the US government market, presuambly the
US government is OK with a potential NSA-introduced back door.  :-)

That being said, there is some FIPS compliance code in
drivers/char/random.c, which was introduced while Matt Mackall was
maintaining the driver, and it mystifies me, since I never thought
/dev/random could be an approved FIPS compliant generator --- not that
I care, since I'm not trying to sell into the US government market,
but the FIPS compliance code is largely harmless, so I've never
bothered to remove it.

 Thanks for these suggestions. Shall I take these suggestions and turn them 
 into a full patch?

Sure, go for it.

 Moreover, I read that even for in-kernel users we should use the blocking 
 pool. Or shall we conceive of a third output pool, say, a kernel pool that is 
 independent of the output pools to user space? Adding such a pool more or 
 less 
 only requires to define a new struct entropy_pool instance.

I've audited most of the in-kernel users, and most of them aren't even
using them for a session key; they're using it for something less
critical (e.g. ASLR, stack magic, etc.).  CIFS is perhaps the only
place where it is generating a session key, and session key generation
is just fine with the /dev/urandom pool.

So making all of the in-kernel users deal with a blocking interface is
not worth it, IMHO.

Regards,

- Ted
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] /dev/random for in-kernel use

2014-04-28 Thread Stephan Mueller 
Am Montag, 28. April 2014, 10:23:50 schrieb Theodore Ts'o:

Hi Theodore,

  I am not too convinced of RDRAND due to the lack of usable source code
  (i.e. source code that I can build myself). But that is my personal taste
  :-)
 The problem is the FIPS validation would presumably require obeying
 the SP-800A requirement for an approved entropy source, and while we
 can't audit RDRAND to satisfy ourselves that the US government hasn't
 introduced a back door, if the only purpose of the FIPS validation is
 so that people can sell into the US government market, presuambly the
 US government is OK with a potential NSA-introduced back door.  :-)

From a US centric view, you may be right. But there are some FIPS 140-2 
aspects which are helpful in general (albeit just a minority). And for those, 
auditible code is key. Not everybody is delighted to have NSA watching. :-)
 
 That being said, there is some FIPS compliance code in
 drivers/char/random.c, which was introduced while Matt Mackall was
 maintaining the driver, and it mystifies me, since I never thought
 /dev/random could be an approved FIPS compliant generator --- not that
 I care, since I'm not trying to sell into the US government market,
 but the FIPS compliance code is largely harmless, so I've never
 bothered to remove it.

Ok, let me demystify it, because I was the initial trigger of the code 
changes. Albeit random.c is outside of any FIPS module, NIST requires that 
even seed sources that are outside the module boundary have a so-called 
continuous selftest as defined in FIPS specification section 4.9.2. If the 
self test fails, the seed source must become unavailable.
 
  Thanks for these suggestions. Shall I take these suggestions and turn them
  into a full patch?
 
 Sure, go for it.
 
  Moreover, I read that even for in-kernel users we should use the blocking
  pool. Or shall we conceive of a third output pool, say, a kernel pool that
  is independent of the output pools to user space? Adding such a pool more
  or less only requires to define a new struct entropy_pool instance.
 
 I've audited most of the in-kernel users, and most of them aren't even
 using them for a session key; they're using it for something less
 critical (e.g. ASLR, stack magic, etc.).  CIFS is perhaps the only
 place where it is generating a session key, and session key generation
 is just fine with the /dev/urandom pool.
 
 So making all of the in-kernel users deal with a blocking interface is
 not worth it, IMHO.

Sorry, I did not make myself clear: for the purpose of the blocking behavior, 
shall we draw from blocking_pool or define a new pool used completely for this 
in-kernel blocking usage? Note, if we use the blocking_pool, any non-root user 
can stall the in-kernel operation indefinitely by simply reading /dev/random. 
As the in-kernel use for blocking random numbers would be limited, I was 
thinking about a new entropy pool that has no user space access.

I do not want to convert any existing in-kernel users of random data to use 
the new entropy pool.

Ciao
Stephan
-- 
| Cui bono? |
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] /dev/random for in-kernel use

2014-04-28 Thread Gregory Baudet 
3.  An approved DRBG, thus forming a chain of at least two DRBGs;
the initial DRBG in the chain SHALL be seeded by an approved
NRBG or an approved entropy source. A DRBG instantiation may
seed or reseed another DRBG instantiation, but SHALL NOT reseed

itself.


According to me, this just means that the DRBG output cannot be used
as the seed input of that same DRBG.

On 28 April 2014 16:23, Theodore Ts'o ty...@mit.edu wrote:
 On Mon, Apr 28, 2014 at 08:00:19AM +0200, Stephan Mueller wrote:
  However, given that we're reseeding once a minute (or as needed), it's
  actually not a deterministic RNG (per SP 800-90A, section 8.6.5, a
  DRBG is forbidden to reseed itself automatically).

 To be honest, I do not read that in this section. Moreover, a DRBG must 
 reseed
 itself -- the caller shall only have the ability to add additional data or
 trigger a reseeding earlier (the proposed DRBG implementation directly draws
 from get_random_bytes automatically).

 It seems pretty clear to me:

The source of the entropy input (EI) SHALL be either:
...

3.  An approved DRBG, thus forming a chain of at least two DRBGs;
the initial DRBG in the chain SHALL be seeded by an approved
NRBG or an approved entropy source. A DRBG instantiation may
seed or reseed another DRBG instantiation, but SHALL NOT reseed
itself.

 The last SHALL NOT is what makes me think that the DRBG shouldn't be
 doing this automatically.  So if it is only being done via explicit
 user request (i.e., an ioctl) then the blocking interface should be
 sufficient.

 Anticipating that the compliance to SP800-90B/C would be required for a
 successful FIPS validation somewhen in the future, making the blocking
 behavior available to in-kernel users would be of interest.
 

 I am not too convinced of RDRAND due to the lack of usable source code (i.e.
 source code that I can build myself). But that is my personal taste :-)

 The problem is the FIPS validation would presumably require obeying
 the SP-800A requirement for an approved entropy source, and while we
 can't audit RDRAND to satisfy ourselves that the US government hasn't
 introduced a back door, if the only purpose of the FIPS validation is
 so that people can sell into the US government market, presuambly the
 US government is OK with a potential NSA-introduced back door.  :-)

 That being said, there is some FIPS compliance code in
 drivers/char/random.c, which was introduced while Matt Mackall was
 maintaining the driver, and it mystifies me, since I never thought
 /dev/random could be an approved FIPS compliant generator --- not that
 I care, since I'm not trying to sell into the US government market,
 but the FIPS compliance code is largely harmless, so I've never
 bothered to remove it.

 Thanks for these suggestions. Shall I take these suggestions and turn them
 into a full patch?

 Sure, go for it.

 Moreover, I read that even for in-kernel users we should use the blocking
 pool. Or shall we conceive of a third output pool, say, a kernel pool that is
 independent of the output pools to user space? Adding such a pool more or 
 less
 only requires to define a new struct entropy_pool instance.

 I've audited most of the in-kernel users, and most of them aren't even
 using them for a session key; they're using it for something less
 critical (e.g. ASLR, stack magic, etc.).  CIFS is perhaps the only
 place where it is generating a session key, and session key generation
 is just fine with the /dev/urandom pool.

 So making all of the in-kernel users deal with a blocking interface is
 not worth it, IMHO.

 Regards,

 - Ted
 --
 To unsubscribe from this list: send the line unsubscribe linux-crypto in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] crypto: user - Allow CRYPTO_MSG_GETALG without CAP_NET_ADMIN

2014-04-28 Thread Marek Vasut 
On Friday, April 25, 2014 at 12:51:06 AM, Matthias-Christian Ott wrote:
 CRYPTO_USER requires CAP_NET_ADMIN for all operations. Most information
 provided by CRYPTO_MSG_GETALG is also accessible through /proc/modules
 and AF_ALG. CRYPTO_MSG_GETALG should not require CAP_NET_ADMIN so that
 processes without CAP_NET_ADMIN can use CRYPTO_MSG_GETALG to get cipher
 details, such as cipher priorities, for AF_ALG.
 
 Signed-off-by: Matthias-Christian Ott o...@mirix.org
 ---
  crypto/crypto_user.c | 12 +---
  1 file changed, 9 insertions(+), 3 deletions(-)

Can you please submit the patch using git send-email so we can properly review 
it?

Thank you !

Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] staging: crypto: skein: depend upon CRYPTO

2014-04-28 Thread Marek Vasut 
On Friday, April 25, 2014 at 06:45:09 PM, Jason Cooper wrote:
 Fengguang's randconfig kernel build tester discovered the following
 warnings:
 
 warning: (CRYPTO_THREEFISH) selects CRYPTO_ALGAPI which has unmet direct
 dependencies (CRYPTO) warning: (DM_VERITY  CRYPTO_SKEIN) selects
 CRYPTO_HASH which has unmet direct dependencies (CRYPTO)
 
 Fix this in the Kconfig by depending on CRYPTO.
 
 Reported-by: Fengguang Wu fengguang...@intel.com
 Signed-off-by: Jason Cooper ja...@lakedaemon.net

Reviewed-by: Marek Vasut ma...@denx.de

Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH crypto 2/2] crypto: caam - add allocation failure handling in SPRINTFCAT macro

2014-04-28 Thread Marek Vasut 
On Monday, April 28, 2014 at 12:24:41 PM, Herbert Xu wrote:
 On Fri, Apr 18, 2014 at 01:01:42PM +0300, Horia Geanta wrote:
  GFP_ATOMIC memory allocation could fail.
  In this case, avoid NULL pointer dereference and notify user.
  
  Cc: sta...@vger.kernel.org # 3.2+
  Cc: Kim Phillips kim.phill...@freescale.com
  Signed-off-by: Horia Geanta horia.gea...@freescale.com
 
 Patch applied to the crypto tree.  Thanks.

Hi Herbert,

Don't you instead want to apply my 11-patch series from
Message-Id: 1398362722-16430-1-git-send-email-ma...@denx.de
Subject: [PATCH 00/11] crypto: caam: Error reporting fixes
which actually fixes this SPRINTFCAT() horror properly please ?

Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH crypto 2/2] crypto: caam - add allocation failure handling in SPRINTFCAT macro

2014-04-28 Thread Marek Vasut 
On Monday, April 28, 2014 at 11:53:23 PM, Herbert Xu wrote:
 On Mon, Apr 28, 2014 at 09:28:41PM +0200, Marek Vasut wrote:
  On Monday, April 28, 2014 at 12:24:41 PM, Herbert Xu wrote:
   On Fri, Apr 18, 2014 at 01:01:42PM +0300, Horia Geanta wrote:
GFP_ATOMIC memory allocation could fail.
In this case, avoid NULL pointer dereference and notify user.

Cc: sta...@vger.kernel.org # 3.2+
Cc: Kim Phillips kim.phill...@freescale.com
Signed-off-by: Horia Geanta horia.gea...@freescale.com
   
   Patch applied to the crypto tree.  Thanks.
  
  Hi Herbert,
  
  Don't you instead want to apply my 11-patch series from
  Message-Id: 1398362722-16430-1-git-send-email-ma...@denx.de
  Subject: [PATCH 00/11] crypto: caam: Error reporting fixes
  which actually fixes this SPRINTFCAT() horror properly please ?
 
 This patch is going into the current release while your patches
 are better suited for the next merge window.

I agree with you that we're rather late in the RC now, but I also believe this 
patch is just hiding the real bug and that we should fix the root cause of the 
problem instead of adding a plaster over it.

I also believe that while my 11-patch series is big, it should go into -stable 
eventually, since it fixes the real problem.

Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html