Re: [PATCH crypto 2/2] crypto: caam - add allocation failure handling in SPRINTFCAT macro
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: # 3.2+ > > > > Cc: Kim Phillips > > > > Signed-off-by: Horia Geanta > > > > > > 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
Re: [PATCH crypto 2/2] crypto: caam - add allocation failure handling in SPRINTFCAT macro
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: # 3.2+ > > > Cc: Kim Phillips > > > Signed-off-by: Horia Geanta > > > > 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. Thanks, -- Email: Herbert Xu 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: user - Allow CRYPTO_MSG_GETALG without CAP_NET_ADMIN
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 > --- > 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
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 > Signed-off-by: Jason Cooper Reviewed-by: Marek Vasut 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
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: # 3.2+ > > Cc: Kim Phillips > > Signed-off-by: Horia Geanta > > 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: [RFC] /dev/random for in-kernel use
>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 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: [RFC] /dev/random for in-kernel use
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
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
[PATCH 0/7 v8] crypto:s5p-sss: Add Device tree and Exynos support
SSS module on Exynos4210, Exynos5250 and Exynos5420 SoCs has added features to the one on S5PV210. However with minor changes the s5p-sss.c driver can be reused to support SSS modules on Exynos4 and 5 SoCs. This patch set 1. Adds device tree support to the s5p-sss.c driver and Documentation 2. Adds code to support SSS module on Exynos4 and 5 SoCs 3. Adds variant struct to handle the differences in SSS modules 4. Adds clk_prepare/clk_unprepare clocks to the s5p-sss.c driver Note: Compatible "exynos4210-secss" should work for Exynos4412 and Exynos5260 (Exynos5260, for which ARCH code is under review) I couldn't test on Exynos4412 and Exynos4210 boards, Should be able to test with addition of DT node and clocks support. These patches are under review at https://lkml.org/lkml/2014/2/17/124 Naveen Krishna Chatradhi (7): crypto:s5p-sss: Use platform_get_irq() instead of _byname() crypto:s5p-sss: Kconfig: Let Exynos SoCs select SSS driver crypto:s5p-sss: Look for the next request in the queue crypto:s5p-sss: Add device tree support crypto:s5p-sss: Add support for SSS module on Exynos crypto:s5p-sss: validate iv before memcpy crypto:s5p-sss: Use clk_prepare/clk_unprepare .../devicetree/bindings/crypto/samsung-sss.txt | 35 + drivers/crypto/Kconfig |6 +- drivers/crypto/s5p-sss.c | 145 +++- 3 files changed, 150 insertions(+), 36 deletions(-) create mode 100644 Documentation/devicetree/bindings/crypto/samsung-sss.txt -- 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()
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
Reviewed-by: Tomasz Figa
Acked-by: Herbert Xu
CC: David S. Miller
CC: Vladimir Zapolskiy
TO:
CC:
---
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
[PATCH 2/7 v8] crypto:s5p-sss: Add device tree support
This patch adds device tree support to the s5p-sss.c crypto driver.
Signed-off-by: Naveen Krishna Chatradhi
Acked-by: Herbert Xu
CC: David S. Miller
CC: Vladimir Zapolskiy
TO:
CC:
---
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
#include
#include
+#include
#include
#include
@@ -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 3/7 v8] crypto:s5p-sss: Add support for SSS module on Exynos
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
Reviewed-by: Tomasz Figa
Acked-by: Herbert Xu
CC: David S. Miller
CC: Vladimir Zapolskiy
TO:
CC:
---
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
.../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 {
+ boolhas_hash_irq;
+ unsigned intaes_offset;
+};
+
struct s5p_aes_reqctx {
unsigned long mode;
};
@@ -162,6
[PATCH 7/7 v8] crypto:s5p-sss: Look for the next request in the queue
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
Acked-by: Herbert Xu
CC: David S. Miller
CC: Vladimir Zapolskiy
TO:
CC:
---
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 5/7 v8] crypto:s5p-sss: validate iv before memcpy
This patch adds code to validate "iv" buffer before trying to
memcpy the contents
Signed-off-by: Naveen Krishna Chatradhi
Reviewed-by: Tomasz Figa
Acked-by: Herbert Xu
CC: David S. Miller
CC: Vladimir Zapolskiy
TO:
CC:
---
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 4/7 v8] crypto:s5p-sss: Kconfig: Let Exynos SoCs select SSS driver
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 Reviewed-by: Tomasz Figa Acked-by: Herbert Xu CC: David S. Miller CC: Vladimir Zapolskiy TO: CC: --- 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 6/7 v8] crypto:s5p-sss: Use clk_prepare/clk_unprepare
This patch set adds use of clk_prepare/clk_unprepare as
required by generic clock framework.
Signed-off-by: Naveen Krishna Chatradhi
Reviewed-by: Tomasz Figa
Acked-by: Herbert Xu
CC: David S. Miller
CC: Vladimir Zapolskiy
TO:
CC:
---
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
Re: [PATCH 0/3] Cleanup ressource leaks in test_aead_speed()
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 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
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 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 1/2] crypto: caam - fix mem leak in ahash_setkey
On Wed, Apr 23, 2014 at 01:47:32AM +0200, Marek Vasut wrote:
> On Friday, April 18, 2014 at 12:01:41 PM, Horia Geanta wrote:
> > In case hash key is bigger than algorithm block size, it is hashed.
> > In this case, memory is allocated to keep this hash in hashed_key.
> > hashed_key has to be freed on the key_dma dma mapping error path.
> >
> > Cc: # 3.10+
> > Signed-off-by: Horia Geanta
> > ---
> > drivers/crypto/caam/caamhash.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/crypto/caam/caamhash.c
> > b/drivers/crypto/caam/caamhash.c index 0378328f47a7..2d244e629ed2 100644
> > --- a/drivers/crypto/caam/caamhash.c
> > +++ b/drivers/crypto/caam/caamhash.c
> > @@ -545,7 +545,8 @@ static int ahash_setkey(struct crypto_ahash *ahash,
> > DMA_TO_DEVICE);
> > if (dma_mapping_error(jrdev, ctx->key_dma)) {
> > dev_err(jrdev, "unable to map key i/o memory\n");
> > - return -ENOMEM;
> > + ret = -ENOMEM;
> > + goto map_err;
> > }
> > #ifdef DEBUG
> > print_hex_dump(KERN_ERR, "ctx.key@"__stringify(__LINE__)": ",
> > @@ -559,6 +560,7 @@ static int ahash_setkey(struct crypto_ahash *ahash,
> > DMA_TO_DEVICE);
> > }
> >
> > +map_err:
> > kfree(hashed_key);
>
> Reviewed-by: Marek Vasut
Patch applied to cryptodev. I'm not pushing this to stable
because it doesn't satisfy the conditions for it.
Thanks,
--
Email: Herbert Xu
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
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: # 3.2+ > Cc: Kim Phillips > Signed-off-by: Horia Geanta Patch applied to the crypto tree. Thanks. -- Email: Herbert Xu 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
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 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
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 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
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
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
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
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
