Something wrong with cryptodev-2.6 tree?
Hi, It seems that the cryptodev-2.6 tree at https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git has somehow rolled back 3 months ago. Not sure if it's a git.kernel.org issue or something else but probably worth taking a look? Thanks, Gilad -- Gilad Ben-Yossef Chief Coffee Drinker values of β will give rise to dom!
Re: [PATCH 5/6] crypto: skcipher - remove useless setting of type flags
On Sun, Jul 1, 2018 at 1:16 AM, Eric Biggers wrote:
> From: Eric Biggers
>
> Some skcipher algorithms set .cra_flags = CRYPTO_ALG_TYPE_SKCIPHER. But
> this is redundant with the C structure type ('struct skcipher_alg'), and
> crypto_register_skcipher() already sets the type flag automatically,
> clearing any type flag that was already there. Apparently the useless
> assignment has just been copy+pasted around.
>
> So, remove the useless assignment from all the skcipher algorithms.
>
> This patch shouldn't change any actual behavior.
>
> Signed-off-by: Eric Biggers
> ---
> drivers/crypto/ccree/cc_cipher.c | 3 +--
Acked-by: Gilad Ben-Yossef
Re: [PATCH 3/6] crypto: ahash - remove useless setting of cra_type
On Sun, Jul 1, 2018 at 1:16 AM, Eric Biggers wrote:
> From: Eric Biggers
>
> Some ahash algorithms set .cra_type = _ahash_type. But this is
> redundant with the C structure type ('struct ahash_alg'), and
> crypto_register_ahash() already sets the .cra_type automatically.
> Apparently the useless assignment has just been copy+pasted around.
>
> So, remove the useless assignment from all the ahash algorithms.
>
> This patch shouldn't change any actual behavior.
>
> Signed-off-by: Eric Biggers
> ---
> drivers/crypto/ccree/cc_hash.c | 1 -
Acked-by: Gilad Ben-Yossef
Re: [PATCH 2/6] crypto: ahash - remove useless setting of type flags
On Sun, Jul 1, 2018 at 1:16 AM, Eric Biggers wrote:
> From: Eric Biggers
>
> Many ahash algorithms set .cra_flags = CRYPTO_ALG_TYPE_AHASH. But this
> is redundant with the C structure type ('struct ahash_alg'), and
> crypto_register_ahash() already sets the type flag automatically,
> clearing any type flag that was already there. Apparently the useless
> assignment has just been copy+pasted around.
>
> So, remove the useless assignment from all the ahash algorithms.
>
> This patch shouldn't change any actual behavior.
>
> Signed-off-by: Eric Biggers
> ---
> drivers/crypto/ccree/cc_hash.c | 3 +-
Acked-by: Gilad Ben-Yossef
--
Gilad Ben-Yossef
Chief Coffee Drinker
values of β will give rise to dom!
...
[PATCH v2 2/5] crypto: ccree: better clock handling
Use managed clock handling, differentiate between no clock (possibly OK)
and clock init failure (never OK) and correctly handle clock detection
being deferred.
Suggested-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com>
---
drivers/crypto/ccree/cc_driver.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/ccree/cc_driver.c b/drivers/crypto/ccree/cc_driver.c
index 6f93ce7..b266657 100644
--- a/drivers/crypto/ccree/cc_driver.c
+++ b/drivers/crypto/ccree/cc_driver.c
@@ -190,6 +190,7 @@ static int init_cc_resources(struct platform_device
*plat_dev)
u64 dma_mask;
const struct cc_hw_data *hw_rev;
const struct of_device_id *dev_id;
+ struct clk *clk;
int rc = 0;
new_drvdata = devm_kzalloc(dev, sizeof(*new_drvdata), GFP_KERNEL);
@@ -219,7 +220,24 @@ static int init_cc_resources(struct platform_device
*plat_dev)
platform_set_drvdata(plat_dev, new_drvdata);
new_drvdata->plat_dev = plat_dev;
- new_drvdata->clk = of_clk_get(np, 0);
+ clk = devm_clk_get(dev, NULL);
+ if (IS_ERR(clk))
+ switch (PTR_ERR(clk)) {
+ /* Clock is optional so this might be fine */
+ case -ENOENT:
+ break;
+
+ /* Clock not available, let's try again soon */
+ case -EPROBE_DEFER:
+ return -EPROBE_DEFER;
+
+ default:
+ dev_err(dev, "Error getting clock: %ld\n",
+ PTR_ERR(clk));
+ return PTR_ERR(clk);
+ }
+ new_drvdata->clk = clk;
+
new_drvdata->coherent = of_dma_is_coherent(np);
/* Get device resources */
--
2.7.4
[PATCH v2 3/5] crypto: ccree: silence debug prints
The cache parameter register configuration was being too verbose. Use dev_dbg() to only provide the information if needed. Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com> --- drivers/crypto/ccree/cc_driver.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/crypto/ccree/cc_driver.c b/drivers/crypto/ccree/cc_driver.c index b266657..1e40e76 100644 --- a/drivers/crypto/ccree/cc_driver.c +++ b/drivers/crypto/ccree/cc_driver.c @@ -168,14 +168,14 @@ int init_cc_regs(struct cc_drvdata *drvdata, bool is_probe) val = cc_ioread(drvdata, CC_REG(AXIM_CACHE_PARAMS)); if (is_probe) - dev_info(dev, "Cache params previous: 0x%08X\n", val); + dev_dbg(dev, "Cache params previous: 0x%08X\n", val); cc_iowrite(drvdata, CC_REG(AXIM_CACHE_PARAMS), cache_params); val = cc_ioread(drvdata, CC_REG(AXIM_CACHE_PARAMS)); if (is_probe) - dev_info(dev, "Cache params current: 0x%08X (expect: 0x%08X)\n", -val, cache_params); + dev_dbg(dev, "Cache params current: 0x%08X (expect: 0x%08X)\n", + val, cache_params); return 0; } -- 2.7.4
[PATCH v2 5/5] arm64: dts: renesas: r8a7795: add ccree binding
Add bindings for CryptoCell instance in the SoC.
Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com>
---
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index d842940..3ac75db 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -528,6 +528,15 @@
status = "disabled";
};
+ arm_cc630p: crypto@e6601000 {
+ compatible = "arm,cryptocell-630p-ree";
+ interrupts = ;
+ reg = <0x0 0xe6601000 0 0x1000>;
+ clocks = < CPG_MOD 229>;
+ resets = < 229>;
+ power-domains = < R8A7795_PD_ALWAYS_ON>;
+ };
+
i2c3: i2c@e66d {
#address-cells = <1>;
#size-cells = <0>;
--
2.7.4
[PATCH v2 4/5] clk: renesas: r8a7795: add ccree clock bindings
This patch adds the clock used by the CryptoCell 630p instance in the SoC.
Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com>
---
This patch depends upon the "clk: renesas: r8a7795: Add CR clock" patch
from Geert Uytterhoeven.
drivers/clk/renesas/r8a7795-cpg-mssr.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/renesas/r8a7795-cpg-mssr.c
b/drivers/clk/renesas/r8a7795-cpg-mssr.c
index e5b1865..a85dd50 100644
--- a/drivers/clk/renesas/r8a7795-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a7795-cpg-mssr.c
@@ -133,6 +133,7 @@ static struct mssr_mod_clk r8a7795_mod_clks[] __initdata = {
DEF_MOD("sys-dmac2", 217, R8A7795_CLK_S0D3),
DEF_MOD("sys-dmac1", 218, R8A7795_CLK_S0D3),
DEF_MOD("sys-dmac0", 219, R8A7795_CLK_S0D3),
+ DEF_MOD("sceg-pub", 229, R8A7795_CLK_CR),
DEF_MOD("cmt3", 300, R8A7795_CLK_R),
DEF_MOD("cmt2", 301, R8A7795_CLK_R),
DEF_MOD("cmt1", 302, R8A7795_CLK_R),
--
2.7.4
[PATCH v2 0/5] crypto: ccree: cleanup, fixes and R-Car enabling
The patch set enables the use of CryptoCell found in some Renesas R-Car Salvator-X boards and fixes some driver issues uncovered that prevented to work properly. Changes from v1: - Properly fix the bug that caused us to read a bad signature register rather than dropping the check - Proper DT fields as indicated by Geert Uytterhoeven. - Better clock enabling as suggested by Geert Uytterhoeven. Note! the last two patches in the set depend on the "clk: renesas: r8a7795: Add CR clock" patch from Geert Uytterhoeven. Gilad Ben-Yossef (5): crypto: ccree: correct host regs offset crypto: ccree: better clock handling crypto: ccree: silence debug prints clk: renesas: r8a7795: add ccree clock bindings arm64: dts: renesas: r8a7795: add ccree binding arch/arm64/boot/dts/renesas/r8a7795.dtsi | 9 + drivers/clk/renesas/r8a7795-cpg-mssr.c | 1 + drivers/crypto/ccree/cc_debugfs.c| 7 +-- drivers/crypto/ccree/cc_driver.c | 34 ++-- drivers/crypto/ccree/cc_driver.h | 2 ++ drivers/crypto/ccree/cc_host_regs.h | 6 -- 6 files changed, 49 insertions(+), 10 deletions(-) -- 2.7.4
[PATCH v2 1/5] crypto: ccree: correct host regs offset
The product signature and HW revision register have different offset on the
older HW revisions.
This fixes the problem of the driver failing sanity check on silicon
despite working on the FPGA emulation systems.
Fixes: 27b3b22dd98c ("crypto: ccree - add support for older HW revs")
Cc: sta...@vger.kernel.org
Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com>
---
drivers/crypto/ccree/cc_debugfs.c | 7 +--
drivers/crypto/ccree/cc_driver.c| 8 ++--
drivers/crypto/ccree/cc_driver.h| 2 ++
drivers/crypto/ccree/cc_host_regs.h | 6 --
4 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/crypto/ccree/cc_debugfs.c
b/drivers/crypto/ccree/cc_debugfs.c
index 08f8db4..5ca184e 100644
--- a/drivers/crypto/ccree/cc_debugfs.c
+++ b/drivers/crypto/ccree/cc_debugfs.c
@@ -26,7 +26,8 @@ struct cc_debugfs_ctx {
static struct dentry *cc_debugfs_dir;
static struct debugfs_reg32 debug_regs[] = {
- CC_DEBUG_REG(HOST_SIGNATURE),
+ { .name = "SIGNATURE" }, /* Must be 0th */
+ { .name = "VERSION" }, /* Must be 1st */
CC_DEBUG_REG(HOST_IRR),
CC_DEBUG_REG(HOST_POWER_DOWN_EN),
CC_DEBUG_REG(AXIM_MON_ERR),
@@ -34,7 +35,6 @@ static struct debugfs_reg32 debug_regs[] = {
CC_DEBUG_REG(HOST_IMR),
CC_DEBUG_REG(AXIM_CFG),
CC_DEBUG_REG(AXIM_CACHE_PARAMS),
- CC_DEBUG_REG(HOST_VERSION),
CC_DEBUG_REG(GPR_HOST),
CC_DEBUG_REG(AXIM_MON_COMP),
};
@@ -58,6 +58,9 @@ int cc_debugfs_init(struct cc_drvdata *drvdata)
struct debugfs_regset32 *regset;
struct dentry *file;
+ debug_regs[0].offset = drvdata->sig_offset;
+ debug_regs[1].offset = drvdata->ver_offset;
+
ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
if (!ctx)
return -ENOMEM;
diff --git a/drivers/crypto/ccree/cc_driver.c b/drivers/crypto/ccree/cc_driver.c
index 89ce013..6f93ce7 100644
--- a/drivers/crypto/ccree/cc_driver.c
+++ b/drivers/crypto/ccree/cc_driver.c
@@ -207,9 +207,13 @@ static int init_cc_resources(struct platform_device
*plat_dev)
if (hw_rev->rev >= CC_HW_REV_712) {
new_drvdata->hash_len_sz = HASH_LEN_SIZE_712;
new_drvdata->axim_mon_offset = CC_REG(AXIM_MON_COMP);
+ new_drvdata->sig_offset = CC_REG(HOST_SIGNATURE_712);
+ new_drvdata->ver_offset = CC_REG(HOST_VERSION_712);
} else {
new_drvdata->hash_len_sz = HASH_LEN_SIZE_630;
new_drvdata->axim_mon_offset = CC_REG(AXIM_MON_COMP8);
+ new_drvdata->sig_offset = CC_REG(HOST_SIGNATURE_630);
+ new_drvdata->ver_offset = CC_REG(HOST_VERSION_630);
}
platform_set_drvdata(plat_dev, new_drvdata);
@@ -276,7 +280,7 @@ static int init_cc_resources(struct platform_device
*plat_dev)
}
/* Verify correct mapping */
- signature_val = cc_ioread(new_drvdata, CC_REG(HOST_SIGNATURE));
+ signature_val = cc_ioread(new_drvdata, new_drvdata->sig_offset);
if (signature_val != hw_rev->sig) {
dev_err(dev, "Invalid CC signature: SIGNATURE=0x%08X !=
expected=0x%08X\n",
signature_val, hw_rev->sig);
@@ -287,7 +291,7 @@ static int init_cc_resources(struct platform_device
*plat_dev)
/* Display HW versions */
dev_info(dev, "ARM CryptoCell %s Driver: HW version 0x%08X, Driver
version %s\n",
-hw_rev->name, cc_ioread(new_drvdata, CC_REG(HOST_VERSION)),
+hw_rev->name, cc_ioread(new_drvdata, new_drvdata->ver_offset),
DRV_MODULE_VERSION);
rc = init_cc_regs(new_drvdata, true);
diff --git a/drivers/crypto/ccree/cc_driver.h b/drivers/crypto/ccree/cc_driver.h
index 2048fde..95f82b2 100644
--- a/drivers/crypto/ccree/cc_driver.h
+++ b/drivers/crypto/ccree/cc_driver.h
@@ -129,6 +129,8 @@ struct cc_drvdata {
enum cc_hw_rev hw_rev;
u32 hash_len_sz;
u32 axim_mon_offset;
+ u32 sig_offset;
+ u32 ver_offset;
};
struct cc_crypto_alg {
diff --git a/drivers/crypto/ccree/cc_host_regs.h
b/drivers/crypto/ccree/cc_host_regs.h
index f510018..616b2e1 100644
--- a/drivers/crypto/ccree/cc_host_regs.h
+++ b/drivers/crypto/ccree/cc_host_regs.h
@@ -45,7 +45,8 @@
#define CC_HOST_ICR_DSCRPTR_WATERMARK_QUEUE0_CLEAR_BIT_SIZE0x1UL
#define CC_HOST_ICR_AXIM_COMP_INT_CLEAR_BIT_SHIFT 0x17UL
#define CC_HOST_ICR_AXIM_COMP_INT_CLEAR_BIT_SIZE 0x1UL
-#define CC_HOST_SIGNATURE_REG_OFFSET 0xA24UL
+#define CC_HOST_SIGNATURE_712_REG_OFFSET 0xA24UL
+#define CC_HOST_SIGNATURE_630_REG_OFFSET 0xAC8UL
#define CC_HOST_SIGNATURE_VALUE_BIT_SHIFT 0x0UL
#define CC_HOST_SIGNATURE_VALUE_BIT_SIZE 0x20UL
#define CC_HOST_BOOT_REG_OFFSET0xA28UL
@@ -105,7 +106,8 @@
#define CC_HOST_BOOT_ONLY_ENCRYPT_LOCAL_BIT_SIZE 0x1UL
#defi
Re: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding
On Tue, May 22, 2018 at 10:48 AM, Geert Uytterhoeven <ge...@linux-m68k.org> wrote: > Hi Gilad, > > On Mon, May 21, 2018 at 3:43 PM, Gilad Ben-Yossef <gi...@benyossef.com> wrote: >> On Thu, May 17, 2018 at 1:16 PM, Geert Uytterhoeven >> <ge...@linux-m68k.org> wrote: >>> Indeed. From a quick glance, it looks like drivers/crypto/ccree/cc_driver.c >>> does not distinguish between the absence of the clock property, and an >>> actual error in getting the clock, and never considers any error a failure >>> (incl. -PROBE_DEFER). >>> >>> As of_clk_get() returns -ENOENT for both a missing clock property and a >>> missing clock, you should use (devm_)clk_get() instead, and distinguish >>> between NULL (no clock property) and IS_ERR() (actual failure -> abort). >> >> I was trying to do as you suggested but I didn't quite get what is the >> dev_id (2nd) parameter to devm_clk_get parameter is supposed to be. > > It's the (optional) name of the clock, helpful in case there is more than one. > In your case, NULL is fine. > I have assumed as much and tried it, it did not work and so I assumed I am missing something and asked you. It turns out I was missing the fact I was using the wrong device tree file... :-( So thanks, it works now :-) Having said that, while using devm)clk_get() is a better approach, it does not seems to distinguish between no "clocks" and a failure to clock information - it returns ENOENT in both cases as well. Thanks, Gilad -- Gilad Ben-Yossef Chief Coffee Drinker "If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru
Re: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding
On Thu, May 17, 2018 at 1:16 PM, Geert Uytterhoeven <ge...@linux-m68k.org> wrote: > > Indeed. From a quick glance, it looks like drivers/crypto/ccree/cc_driver.c > does not distinguish between the absence of the clock property, and an > actual error in getting the clock, and never considers any error a failure > (incl. -PROBE_DEFER). > > As of_clk_get() returns -ENOENT for both a missing clock property and a > missing clock, you should use (devm_)clk_get() instead, and distinguish > between NULL (no clock property) and IS_ERR() (actual failure -> abort). > I was trying to do as you suggested but I didn't quite get what is the dev_id (2nd) parameter to devm_clk_get parameter is supposed to be. I see what of_clk_get() is doing, so can replicate that but it seems an over kill. Any ideas? Thanks, Gilad -- Gilad Ben-Yossef Chief Coffee Drinker "If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru
Re: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding
On Thu, May 17, 2018 at 4:35 PM, Geert Uytterhoeven <ge...@linux-m68k.org> wrote: > Hi Gilad, > > On Thu, May 17, 2018 at 3:09 PM, Gilad Ben-Yossef <gi...@benyossef.com> wrote: >> On Thu, May 17, 2018 at 1:16 PM, Geert Uytterhoeven >> <ge...@linux-m68k.org> wrote: >>> However, even with your clock patch, the signature checking fails for me, >>> on both R-Car H3 ES1.0 and ES2.0. >>> Does this need changes to the ARM Trusted Firmware, to allow Linux to >>> access the public SCEG module? >> >> Well, this is actually something different. If you look you will >> notice that my patch was part of a 3 part patch series, >> the first of which disabled this test. > > Sorry, I had completely forgotten about the first patch from the series. > With that applied, it continues: > > ccree e6601000.crypto: ARM CryptoCell 630P Driver: HW version > 0x, Driver version 4.0 > ccree e6601000.crypto: Cache params previous: 0x0777 > ccree e6601000.crypto: Cache params current: 0x > (expect: 0x) > alg: No test for cts1(cbc(aes)) (cts1-cbc-aes-ccree) > alg: No test for authenc(xcbc(aes),cbc(aes)) > (authenc-xcbc-aes-cbc-aes-ccree) > alg: No test for authenc(xcbc(aes),rfc3686(ctr(aes))) > (authenc-xcbc-aes-rfc3686-ctr-aes-ccree) > ccree e6601000.crypto: ARM ccree device initialized > > Is HW version 0x expected? It's related to the problem with reading the wrong register I've mentioned before. > >> If you take all the 3 patches, it will work. > > is there an easy way to test proper operation? The lines of the form " alg: No test for cts1(cbc(aes)) (cts1-cbc-aes-ccree)" indicates you have the Crypto API testmgr enable (or rather not disabled would be more accurate) so every cryptographic algorithm except those specified in these messages was tested with test vectors from crypto/testmgr.c upon registration. If you don't seen failure warnings, it works. You can also check /proc/crypto for all the algorithm with ccree listed as their driver and check that their test passed. > I enabled CONFIG_CRYPT_TEST, and did insmod tcrypt.ko, but I mostly see > "Failed to load transform" messages. > tcrypt.ko is a rather crude developer tool. It has hard coded lists of test for different algorithms that does not take into account if some crypto algs are enagled in the build or not. It's more of a stress test. Gilad -- Gilad Ben-Yossef Chief Coffee Drinker "If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru
Re: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding
On Thu, May 17, 2018 at 12:04 PM, Simon Horman <ho...@verge.net.au> wrote:
> On Thu, May 17, 2018 at 11:01:57AM +0300, Gilad Ben-Yossef wrote:
>> On Wed, May 16, 2018 at 10:43 AM, Simon Horman <ho...@verge.net.au> wrote:
>> > On Tue, May 15, 2018 at 04:50:44PM +0200, Geert Uytterhoeven wrote:
>> >> Hi Gilad,
>> >>
>> >> On Tue, May 15, 2018 at 2:29 PM, Gilad Ben-Yossef <gi...@benyossef.com>
>> >> wrote:
>> >> > Add bindings for CryptoCell instance in the SoC.
>> >> >
>> >> > Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com>
>> >>
>> >> Thanks for your patch!
>> >>
>> >> > --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>> >> > +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>> >> > @@ -528,6 +528,14 @@
>> >> > status = "disabled";
>> >> > };
>> >> >
>> >> > + arm_cc630p: crypto@e6601000 {
>> >> > + compatible = "arm,cryptocell-630p-ree";
>> >> > + interrupts = ;
>> >> > + #interrupt-cells = <2>;
>> >>
>> >> I believe the #interrupt-cells property is not needed.
>> >>
>> >> > + reg = <0x0 0xe6601000 0 0x1000>;
>> >> > + clocks = < CPG_MOD 229>;
>> >> > + };
>> >>
>> >> The rest looks good, but I cannot verify the register block.
>> >>
>> >> > +
>> >> > i2c3: i2c@e66d {
>> >> > #address-cells = <1>;
>> >> > #size-cells = <0>;
>> >
>> > Thanks, I have applied this after dropping the #interrupt-cells property.
>>
>> Thanks you!
>>
>> Alas, it will not work without the clk patch (the previous one in the
>> series) so they need to be
>> taken or dropped together.
>
> I think its fine if it does not yet work.
> But not if its causes things that previously worked to stop working.
Based on the further discussion with Geert my recommendation is to
drop my patch for now,
take Geert CR clock patch and I will follow up next week with a v2
that fixes the clock
handing as discussed with Geert.
Many thanks,
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
-- Jean-Baptiste Queru
Re: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding
On Thu, May 17, 2018 at 1:16 PM, Geert Uytterhoeven
<ge...@linux-m68k.org> wrote:
> Hi Gilad,
>
> On Thu, May 17, 2018 at 10:01 AM, Gilad Ben-Yossef <gi...@benyossef.com>
> wrote:
>> On Wed, May 16, 2018 at 10:43 AM, Simon Horman <ho...@verge.net.au> wrote:
>>> On Tue, May 15, 2018 at 04:50:44PM +0200, Geert Uytterhoeven wrote:
>>>> On Tue, May 15, 2018 at 2:29 PM, Gilad Ben-Yossef <gi...@benyossef.com>
>>>> wrote:
>>>> > Add bindings for CryptoCell instance in the SoC.
>>>> >
>>>> > Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com>
>>>>
>>>> Thanks for your patch!
>>>>
>>>> > --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>>>> > +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>>>> > @@ -528,6 +528,14 @@
>>>> > status = "disabled";
>>>> > };
>>>> >
>>>> > + arm_cc630p: crypto@e6601000 {
>>>> > + compatible = "arm,cryptocell-630p-ree";
>>>> > + interrupts = ;
>>>> > + #interrupt-cells = <2>;
>>>>
>>>> I believe the #interrupt-cells property is not needed.
>>>>
>>>> > + reg = <0x0 0xe6601000 0 0x1000>;
>>>> > + clocks = < CPG_MOD 229>;
>
> Missing "power-domains = < R8A7795_PD_ALWAYS_ON>;", as
> the Secure Engine is part of the CPG/MSSR clock domain (see below [*]).
Thank you. I didn't get this information from Renesas :-)
>
>>>> > + };
>>>>
>>>> The rest looks good, but I cannot verify the register block.
>>>>
>>>> > +
>>>> > i2c3: i2c@e66d {
>>>> > #address-cells = <1>;
>>>> > #size-cells = <0>;
>>>
>>> Thanks, I have applied this after dropping the #interrupt-cells property.
>>
>> Thanks you!
>>
>> Alas, it will not work without the clk patch (the previous one in the
>> series) so they need to be
>> taken or dropped together.
>
> Indeed. From a quick glance, it looks like drivers/crypto/ccree/cc_driver.c
> does not distinguish between the absence of the clock property, and an
> actual error in getting the clock, and never considers any error a failure
> (incl. -PROBE_DEFER).
>
> As of_clk_get() returns -ENOENT for both a missing clock property and a
> missing clock, you should use (devm_)clk_get() instead, and distinguish
> between NULL (no clock property) and IS_ERR() (actual failure -> abort).
>
Thank you, this is very valuable. I will do as you suggested.
> Hence in the absence of the clock patch, the driver accesses the crypto
> engine while its module clock is turned off, leading to:
>
> ccree e6601000.crypto: Invalid CC signature: SIGNATURE=0x
> != expected=0xDCC63000
>
> You must be lucky, though, usually you get an imprecise external abort
> later, crashing the whole system ;-)
>
> So I think this patch should be dropped for now.
>
> However, even with your clock patch, the signature checking fails for me,
> on both R-Car H3 ES1.0 and ES2.0.
> Does this need changes to the ARM Trusted Firmware, to allow Linux to
> access the public SCEG module?
Well, this is actually something different. If you look you will
notice that my patch was part of a 3 part patch series,
the first of which disabled this test.
If you take all the 3 patches, it will work.
To make things more interesting, I have since sending the patch
learned WHY the test does not work, so disabling
it is not needed - to make a long story short, I was reading the wrong
register that just happens to have the right value
in our FPGA based tests systems but does not in the real silicon
implementations.
But you are right - if the clock is not enabled and you are try to
read from the register the system does freeze.
I will send a fixed v2. based on your patch enabling the CR clock.
>
> [*] More on the subject of clock control:
> At least for Renesas SoCs, where the module is part of a clock domain, and
> can be controlled automatically by Runtime PM, you could drop the explicit
> clock control, and use Runtime PM instead
> (pm_runtime_{enable,get_sync,put,disable}()). That would allow the driver
> to work on systems with any kind of PM Domains, too.
> Depending on the other platforms that include a CryptoCell and their
> (non)reliance on PM Domains, you may have to keep the explicit clock
> handling, in addition to Runtime PM.
>
> To decrease power consumption, I suggest to move the clock and/or Runtime
> PM handling to the routines that actually use the hardware, instead of
> powering the module in the probe routine.
>
This is very interesting and I will give it a try.
Thanks again!
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
-- Jean-Baptiste Queru
Re: [PATCH 1/3] crypto: ccree: drop signature register check
Herbert, On Tue, May 15, 2018 at 3:29 PM, Gilad Ben-Yossef <gi...@benyossef.com> wrote: > We were using the content of the signature register as a sanity > check for the hardware functioning but it turns out not all > implementers use the same values so the check is giving false > negative on certain SoCs and so we drop it. > Please drop this patch. I have found a better fix and will send a v2 soon. Thanks, Gilad -- Gilad Ben-Yossef Chief Coffee Drinker "If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru
Re: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding
On Wed, May 16, 2018 at 10:43 AM, Simon Horman <ho...@verge.net.au> wrote:
> On Tue, May 15, 2018 at 04:50:44PM +0200, Geert Uytterhoeven wrote:
>> Hi Gilad,
>>
>> On Tue, May 15, 2018 at 2:29 PM, Gilad Ben-Yossef <gi...@benyossef.com>
>> wrote:
>> > Add bindings for CryptoCell instance in the SoC.
>> >
>> > Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com>
>>
>> Thanks for your patch!
>>
>> > --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>> > +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>> > @@ -528,6 +528,14 @@
>> > status = "disabled";
>> > };
>> >
>> > + arm_cc630p: crypto@e6601000 {
>> > + compatible = "arm,cryptocell-630p-ree";
>> > + interrupts = ;
>> > + #interrupt-cells = <2>;
>>
>> I believe the #interrupt-cells property is not needed.
>>
>> > + reg = <0x0 0xe6601000 0 0x1000>;
>> > + clocks = < CPG_MOD 229>;
>> > + };
>>
>> The rest looks good, but I cannot verify the register block.
>>
>> > +
>> > i2c3: i2c@e66d {
>> > #address-cells = <1>;
>> > #size-cells = <0>;
>
> Thanks, I have applied this after dropping the #interrupt-cells property.
Thanks you!
Alas, it will not work without the clk patch (the previous one in the
series) so they need to be
taken or dropped together.
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
-- Jean-Baptiste Queru
Re: [PATCH 2/3] clk: renesas: r8a7795: Add ccree clock
On Tue, May 15, 2018 at 5:47 PM, Geert Uytterhoeven
<ge...@linux-m68k.org> wrote:
> Hi Gilad,
>
> On Tue, May 15, 2018 at 2:29 PM, Gilad Ben-Yossef <gi...@benyossef.com> wrote:
>> This patch adds the clock used by the CryptoCell 630p instance in the SoC.
>>
>> Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com>
>
> Thanks for your patch!
>
>> --- a/drivers/clk/renesas/r8a7795-cpg-mssr.c
>> +++ b/drivers/clk/renesas/r8a7795-cpg-mssr.c
>> @@ -132,6 +132,7 @@ static struct mssr_mod_clk r8a7795_mod_clks[] __initdata
>> = {
>> DEF_MOD("sys-dmac2", 217, R8A7795_CLK_S0D3),
>> DEF_MOD("sys-dmac1", 218, R8A7795_CLK_S0D3),
>> DEF_MOD("sys-dmac0", 219, R8A7795_CLK_S0D3),
>> + DEF_MOD("ccree", 229, R8A7795_CLK_S3D2),
>
> I don't know if "ccree" is the proper name for this clock, as there
> may be multiple
> instances.
I'd be happy to rename it to anything else. Suggestions?
> I also can't verify the parent clock.
I'm afraid I can't really help. This is based on code snippet from
Renesas. I verified it works but
I am not an expert on the clock settings :-(
>
>> DEF_MOD("cmt3", 300, R8A7795_CLK_R),
>> DEF_MOD("cmt2", 301, R8A7795_CLK_R),
>> DEF_MOD("cmt1", 302, R8A7795_CLK_R),
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
--
Gilad Ben-Yossef
Chief Coffee Drinker
"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
-- Jean-Baptiste Queru
[PATCH 1/3] crypto: ccree: drop signature register check
We were using the content of the signature register as a sanity
check for the hardware functioning but it turns out not all
implementers use the same values so the check is giving false
negative on certain SoCs and so we drop it.
Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com>
---
drivers/crypto/ccree/cc_driver.c | 18 +++---
1 file changed, 3 insertions(+), 15 deletions(-)
diff --git a/drivers/crypto/ccree/cc_driver.c b/drivers/crypto/ccree/cc_driver.c
index 89ce013..f8ff358 100644
--- a/drivers/crypto/ccree/cc_driver.c
+++ b/drivers/crypto/ccree/cc_driver.c
@@ -38,21 +38,20 @@ MODULE_PARM_DESC(cc_dump_bytes, "Dump buffers to kernel log
as debugging aid");
struct cc_hw_data {
char *name;
enum cc_hw_rev rev;
- u32 sig;
};
/* Hardware revisions defs. */
static const struct cc_hw_data cc712_hw = {
- .name = "712", .rev = CC_HW_REV_712, .sig = 0xDCC71200U
+ .name = "712", .rev = CC_HW_REV_712
};
static const struct cc_hw_data cc710_hw = {
- .name = "710", .rev = CC_HW_REV_710, .sig = 0xDCC63200U
+ .name = "710", .rev = CC_HW_REV_710
};
static const struct cc_hw_data cc630p_hw = {
- .name = "630P", .rev = CC_HW_REV_630, .sig = 0xDCC63000U
+ .name = "630P", .rev = CC_HW_REV_630
};
static const struct of_device_id arm_ccree_dev_of_match[] = {
@@ -186,7 +185,6 @@ static int init_cc_resources(struct platform_device
*plat_dev)
struct cc_drvdata *new_drvdata;
struct device *dev = _dev->dev;
struct device_node *np = dev->of_node;
- u32 signature_val;
u64 dma_mask;
const struct cc_hw_data *hw_rev;
const struct of_device_id *dev_id;
@@ -275,16 +273,6 @@ static int init_cc_resources(struct platform_device
*plat_dev)
return rc;
}
- /* Verify correct mapping */
- signature_val = cc_ioread(new_drvdata, CC_REG(HOST_SIGNATURE));
- if (signature_val != hw_rev->sig) {
- dev_err(dev, "Invalid CC signature: SIGNATURE=0x%08X !=
expected=0x%08X\n",
- signature_val, hw_rev->sig);
- rc = -EINVAL;
- goto post_clk_err;
- }
- dev_dbg(dev, "CC SIGNATURE=0x%08X\n", signature_val);
-
/* Display HW versions */
dev_info(dev, "ARM CryptoCell %s Driver: HW version 0x%08X, Driver
version %s\n",
hw_rev->name, cc_ioread(new_drvdata, CC_REG(HOST_VERSION)),
--
2.7.4
[PATCH 2/3] clk: renesas: r8a7795: Add ccree clock
This patch adds the clock used by the CryptoCell 630p instance in the SoC.
Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com>
---
drivers/clk/renesas/r8a7795-cpg-mssr.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/renesas/r8a7795-cpg-mssr.c
b/drivers/clk/renesas/r8a7795-cpg-mssr.c
index 775b0ce..642706a 100644
--- a/drivers/clk/renesas/r8a7795-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a7795-cpg-mssr.c
@@ -132,6 +132,7 @@ static struct mssr_mod_clk r8a7795_mod_clks[] __initdata = {
DEF_MOD("sys-dmac2", 217, R8A7795_CLK_S0D3),
DEF_MOD("sys-dmac1", 218, R8A7795_CLK_S0D3),
DEF_MOD("sys-dmac0", 219, R8A7795_CLK_S0D3),
+ DEF_MOD("ccree", 229, R8A7795_CLK_S3D2),
DEF_MOD("cmt3", 300, R8A7795_CLK_R),
DEF_MOD("cmt2", 301, R8A7795_CLK_R),
DEF_MOD("cmt1", 302, R8A7795_CLK_R),
--
2.7.4
[PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding
Add bindings for CryptoCell instance in the SoC.
Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com>
---
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 91486b4..6c76841 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -528,6 +528,14 @@
status = "disabled";
};
+ arm_cc630p: crypto@e6601000 {
+ compatible = "arm,cryptocell-630p-ree";
+ interrupts = ;
+ #interrupt-cells = <2>;
+ reg = <0x0 0xe6601000 0 0x1000>;
+ clocks = < CPG_MOD 229>;
+ };
+
i2c3: i2c@e66d {
#address-cells = <1>;
#size-cells = <0>;
--
2.7.4
[PATCH 0/3] enable ccree on Renesas R-Car platform
The following patch set enables CryptoCell present in the Renesas R-Car SoC. Gilad Ben-Yossef (3): crypto: ccree: drop signature register check clk: renesas: r8a7795: Add ccree clock arm64: dts: renesas: r8a7795: add ccree binding arch/arm64/boot/dts/renesas/r8a7795.dtsi | 8 drivers/clk/renesas/r8a7795-cpg-mssr.c | 1 + drivers/crypto/ccree/cc_driver.c | 18 +++--- 3 files changed, 12 insertions(+), 15 deletions(-) -- 2.7.4
[PATCH] crypto: reorder paes test lexicographically
Due to a snafu "paes" testmgr tests were not ordered
lexicographically, which led to boot time warnings.
Reorder the tests as needed.
Fixes: a794d8d ("crypto: ccree - enable support for hardware keys")
Reported-by: Abdul Haleem <abdha...@linux.vnet.ibm.com>
Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com>
---
crypto/testmgr.c | 44 ++--
1 file changed, 22 insertions(+), 22 deletions(-)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index c31da0f..b1b8ebb 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -3012,13 +3012,6 @@ static const struct alg_test_desc alg_test_descs[] = {
}
}
}, {
- /* Same as ecb(aes) except the key is stored in
-* hardware secure memory which we reference by index
-*/
- .alg = "ecb(paes)",
- .test = alg_test_null,
- .fips_allowed = 1,
- }, {
.alg = "ecb(khazad)",
.test = alg_test_skcipher,
.suite = {
@@ -3028,6 +3021,13 @@ static const struct alg_test_desc alg_test_descs[] = {
}
}
}, {
+ /* Same as ecb(aes) except the key is stored in
+* hardware secure memory which we reference by index
+*/
+ .alg = "ecb(paes)",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
.alg = "ecb(seed)",
.test = alg_test_skcipher,
.suite = {
@@ -3610,21 +3610,6 @@ static const struct alg_test_desc alg_test_descs[] = {
}
}
}, {
- /* Same as xts(aes) except the key is stored in
-* hardware secure memory which we reference by index
-*/
- .alg = "xts(paes)",
- .test = alg_test_null,
- .fips_allowed = 1,
- }, {
- .alg = "xts4096(paes)",
- .test = alg_test_null,
- .fips_allowed = 1,
- }, {
- .alg = "xts512(paes)",
- .test = alg_test_null,
- .fips_allowed = 1,
- }, {
.alg = "xts(camellia)",
.test = alg_test_skcipher,
.suite = {
@@ -3643,6 +3628,13 @@ static const struct alg_test_desc alg_test_descs[] = {
}
}
}, {
+ /* Same as xts(aes) except the key is stored in
+* hardware secure memory which we reference by index
+*/
+ .alg = "xts(paes)",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
.alg = "xts(serpent)",
.test = alg_test_skcipher,
.suite = {
@@ -3679,6 +3671,14 @@ static const struct alg_test_desc alg_test_descs[] = {
}
}
}, {
+ .alg = "xts4096(paes)",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
+ .alg = "xts512(paes)",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
.alg = "zlib-deflate",
.test = alg_test_comp,
.fips_allowed = 1,
--
2.7.4
Re: [next-20180509][bisected a794d8d] ppc boot warnings at crypto/testmgr.c:3720
On Fri, May 11, 2018 at 9:59 AM, Abdul Haleem <abdha...@linux.vnet.ibm.com> wrote: > Greeting's > > Today's next kernel on powerpc machine has boot warnings with commit > > a794d8d : crypto: ccree - enable support for hardware keys Adding the crypto list and maintainer as it came in via the crypto tree. > > Warning disappears when above commit is reverted. > > Machine Type: Power8 PowerVM LPAR > kernel : 4.17.0-rc4-next-20180509 > config: attached. > test: kexec boot > > trace logs: > --- > Initialise system trusted keyrings > workingset: timestamp_bits=38 max_order=18 bucket_order=0 > zbud: loaded > pstore: using deflate compression > WARNING: CPU: 6 PID: 109 at crypto/testmgr.c:3720 alg_test.part.6+0xd4/0x460 > Modules linked in: > CPU: 6 PID: 109 Comm: cryptomgr_test Not tainted > 4.17.0-rc4-next-20180509-autotest-2-g0244ae7 #2 > NIP: c04a60f4 LR: c04a60e4 CTR: c04a0200 > REGS: c00289acb9d0 TRAP: 0700 Not tainted > (4.17.0-rc4-next-20180509-autotest-2-g0244ae7) > MSR: 80029033 <SF,EE,ME,IR,DR,RI,LE> CR: 24000484 XER: 2000 > CFAR: c09b9110 SOFTE: 0 > GPR00: c04a0260 c00289acbc50 c115df00 0001 > GPR04: c0c13e64 000d 0400 > GPR08: 0001 006b > GPR12: ceca7800 c0128918 c002812a3600 > GPR16: > GPR20: c0c13560 c00288c29880 0400 > GPR24: c00288c29800 000d c0c135a8 c0a1db38 > GPR28: c0c13128 c0c13e60 c0a1c788 0001 > NIP [c04a60f4] alg_test.part.6+0xd4/0x460 > LR [c04a60e4] alg_test.part.6+0xc4/0x460 > Call Trace: > [c00289acbc50] [c00289acbcc0] 0xc00289acbcc0 (unreliable) > [c00289acbd90] [c04a0260] cryptomgr_test+0x60/0x80 > [c00289acbdc0] [c0128a68] kthread+0x158/0x1a0 > [c00289acbe30] [c000b628] ret_from_kernel_thread+0x5c/0xb4 > Instruction dump: > 3b5a56a8 4824 6000 eb9effc8 ebbe 7f83e378 7fa4eb78 48513001 > 6000 7c7f1b78 7d3f00d0 79290fe0 <0b09> 2f9f 419d013c 7fe90034 > ---[ end trace f8ddd7633e720997 ]--- > testmgr: alg_test_descs entries in wrong order: 'ecb(paes)' before > 'ecb(khazad)' > Oouch! this is is my bad. I've changed the cipher name (from haes to paes) based on review feedback but forgot that the cipher test names are alphabetically ordered. I wonder why I didn't see this myself as I'm 100% sure booted this fix on 2 different platforms. Maybe because Khazad was not enabled in my test setup and I guess there are no other cipher starting in I, L,M,N,O ? Fix coming up shortly. Sorry about this. Gilad -- Gilad Ben-Yossef Chief Coffee Drinker "If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru
Re: DMA map buffer allocated in ahash_request_ctx
On Wed, May 9, 2018 at 3:12 PM, Harsh Jain <harshjain.p...@gmail.com> wrote: > Hi Herbert, > > Can we use buffer defined in ahash request context(private space for > each request) to DMA map it to H/W.? Not Herbert but... the ccree driver is doing just and Herbert specifically indicated ahash request contexts are not allowed to be allocated from stack (I asked) so it should be OK. Note that you will need to map and unmap at every Crypto API invocation. You can't map on init because you are not guaranteed to have a final() or export() Hope it helps, Gilad -- Gilad Ben-Yossef Chief Coffee Drinker "If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru
Re: IV generation
On Mon, May 7, 2018 at 2:29 PM, Stephan Mueller <smuel...@chronox.de> wrote: > Am Montag, 7. Mai 2018, 13:19:47 CEST schrieb Gilad Ben-Yossef: > > Hi Gilad, > >> ah... so if I have hardware that can implement say, seqiv, I can >> register "seqiv(rfc4106(gcm(aes)))" and, assuming priorities are >> right, it will be used? > > That is the question I cannot fully answer. Seqiv is a template and thus not > subjet to prios by itself. So, you hardware however could register the full > seqiv(rfc) cipher. I am not fully sure that such registered cipher is then > picked up by the IPSec stack. > > Look into net/xfrm/xfrm_algos.c -- there you see the individual cipher names > and the IV generator added separately. What I have not traced yet is whether > the code assembles the IV generator name and the cipher name before making the > call to crypto_alloc_aead. > > What I can say for sure is that the kernel crypto API knows of the > seqiv(rfc...) cipher name and generates the IV for your (the invocation field > that is). I see. I think the code does the assembly in esp4.c esp_init_aead() and esp_init_authenc() So it should all Just Work(TM). Many thanks for the clarification. Gilad -- Gilad Ben-Yossef Chief Coffee Drinker "If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru
Re: IV generation
On Mon, May 7, 2018 at 2:02 PM, Stephan Mueller <smuel...@chronox.de> wrote: > Am Montag, 7. Mai 2018, 08:26:08 CEST schrieb Gilad Ben-Yossef: > > Hi Gilad, > >> Hi, >> >> A quick question: am I correct in my understanding that there is now >> no automatic IV generation support for either skcipher nor aead? >> And if I'm wrong, can someone point to an example of a driver that >> implements either, as all the ones I see are the deprecated ablkcipher >> interface. >> >> BTW, I'm perfectly fine with not having one, I just want to understand >> I am not missing something... > > The automated IV generation is implemented with the generators such as seqiv > or chainiv. > > For example, AES-GCM as used for IPSec compliant with RFC4106 generates the IV > (the invocation field part of the IV) with the seqiv. This is handled by the > IPSec stack to initialize the cipher of, say, seqiv(rfc4106(gcm(aes))). > > The CTR mode uses the chainiv implementation to manage the IV. ah... so if I have hardware that can implement say, seqiv, I can register "seqiv(rfc4106(gcm(aes)))" and, assuming priorities are right, it will be used? Thanks, Gilad -- Gilad Ben-Yossef Chief Coffee Drinker "If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru
IV generation
Hi, A quick question: am I correct in my understanding that there is now no automatic IV generation support for either skcipher nor aead? And if I'm wrong, can someone point to an example of a driver that implements either, as all the ones I see are the deprecated ablkcipher interface. BTW, I'm perfectly fine with not having one, I just want to understand I am not missing something... Thanks in advance, Gilad -- Gilad Ben-Yossef Chief Coffee Drinker "If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru
Re: [PATCH v2 1/2] crypto: ccree: enable support for hardware keys
On Wed, Apr 25, 2018 at 6:47 PM, Tudor Ambarus
<tudor.amba...@microchip.com> wrote:
> Hi, Gilad,
>
> On 04/23/2018 10:25 AM, Gilad Ben-Yossef wrote:
>>
>> Enable CryptoCell support for hardware keys.
>>
>> Hardware keys are regular AES keys loaded into CryptoCell internal memory
>> via firmware, often from secure boot ROM or hardware fuses at boot time.
>>
>> As such, they can be used for enc/dec purposes like any other key but
>> cannot (read: extremely hard to) be extracted since since they are not
>> available anywhere in RAM during runtime.
>>
>> The mechanism has some similarities to s390 secure keys although the keys
>> are not wrapped or sealed, but simply loaded offline. The interface was
>> therefore modeled based on the s390 secure keys support.
>
>
> I'm interested in hardware keys, ecc508 supports them too. In your
> proposal you expect that the user will provide a specific key token that
> is meaningful only for the ccree driver. If another driver that supports
> "cbc(paes)" shows up, you will force the user to select a specific
> driver implementation and to know what kind of key token to provide.
> Shouldn't we have a common API that can address other drivers too?
The v1 of the patch gave a unique name ("haes") to the CryptoCell HW
key format, since the information in the key for CryptoCell and the
s390 is very different (in short: cryptocell uses key size + slot
index, s390 provide an key encrypted by a HW known key).
Herbert expressed the sentiment that since the user needs to be aware
of the specific format of the token for each device anyway, she must
be aware of which tfm provider is being used anyway, so must be using
the device specific name.
Hence, I change the name to use "paes" just like the s390.
It's pretty obvious that the s390 and CryptoCell HW/protected keys
don't have anything in common and are not interchangeable.
I would say that if the ecc508 tokens are yet a third format, we
should follow the same example and just leave it as "paes" and let the
user specify an exact device name.
However, if we can find a common token format for ecc508 with either
CryptoCell or the s390 (probably less likely), maybe its worth using a
common name for those and a different for the outlier?
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
-- Jean-Baptiste Queru
Re: [PATCH 1/2] crypto: sm4 - export encrypt/decrypt routines to other drivers
On Wed, Apr 25, 2018 at 3:20 PM, Ard Biesheuvel
<ard.biesheu...@linaro.org> wrote:
> In preparation of adding support for the SIMD based arm64 implementation
> of arm64, which requires a fallback to non-SIMD code when invoked in
> certain contexts, expose the generic SM4 encrypt and decrypt routines
> to other drivers.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
Acked-by: Gilad Ben-Yossef <gi...@benyossef.com>
> ---
> crypto/sm4_generic.c | 10 ++
> include/crypto/sm4.h | 3 +++
> 2 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/crypto/sm4_generic.c b/crypto/sm4_generic.c
> index f537a2766c55..c18eebfd5edd 100644
> --- a/crypto/sm4_generic.c
> +++ b/crypto/sm4_generic.c
> @@ -190,21 +190,23 @@ static void sm4_do_crypt(const u32 *rk, u32 *out, const
> u32 *in)
>
> /* encrypt a block of text */
>
> -static void sm4_encrypt(struct crypto_tfm *tfm, u8 *out, const u8 *in)
> +void crypto_sm4_encrypt(struct crypto_tfm *tfm, u8 *out, const u8 *in)
> {
> const struct crypto_sm4_ctx *ctx = crypto_tfm_ctx(tfm);
>
> sm4_do_crypt(ctx->rkey_enc, (u32 *)out, (u32 *)in);
> }
> +EXPORT_SYMBOL_GPL(crypto_sm4_encrypt);
>
> /* decrypt a block of text */
>
> -static void sm4_decrypt(struct crypto_tfm *tfm, u8 *out, const u8 *in)
> +void crypto_sm4_decrypt(struct crypto_tfm *tfm, u8 *out, const u8 *in)
> {
> const struct crypto_sm4_ctx *ctx = crypto_tfm_ctx(tfm);
>
> sm4_do_crypt(ctx->rkey_dec, (u32 *)out, (u32 *)in);
> }
> +EXPORT_SYMBOL_GPL(crypto_sm4_decrypt);
>
> static struct crypto_alg sm4_alg = {
> .cra_name = "sm4",
> @@ -219,8 +221,8 @@ static struct crypto_alg sm4_alg = {
> .cia_min_keysize= SM4_KEY_SIZE,
> .cia_max_keysize= SM4_KEY_SIZE,
> .cia_setkey = crypto_sm4_set_key,
> - .cia_encrypt= sm4_encrypt,
> - .cia_decrypt= sm4_decrypt
> + .cia_encrypt= crypto_sm4_encrypt,
> + .cia_decrypt= crypto_sm4_decrypt
> }
> }
> };
> diff --git a/include/crypto/sm4.h b/include/crypto/sm4.h
> index b64e64d20b28..7afd730d16ff 100644
> --- a/include/crypto/sm4.h
> +++ b/include/crypto/sm4.h
> @@ -25,4 +25,7 @@ int crypto_sm4_set_key(struct crypto_tfm *tfm, const u8
> *in_key,
> int crypto_sm4_expand_key(struct crypto_sm4_ctx *ctx, const u8 *in_key,
> unsigned int key_len);
>
> +void crypto_sm4_encrypt(struct crypto_tfm *tfm, u8 *out, const u8 *in);
> +void crypto_sm4_decrypt(struct crypto_tfm *tfm, u8 *out, const u8 *in);
> +
> #endif
> --
> 2.17.0
>
--
Gilad Ben-Yossef
Chief Coffee Drinker
"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
-- Jean-Baptiste Queru
Re: [PATCH] crypto: ccree: limit build to plausible archs
On Tue, Apr 24, 2018 at 11:52 AM, Geert Uytterhoeven <ge...@linux-m68k.org> wrote: > > My underlying idea is not to cut down build time for test code (that's what > we have COMPILE_TEST for), but to enhance usability for users and distros, > who need to know if it makes sense to enable an option. OK, considering the driver Kconfig depends on OF I think we're OK here with regard to usability and distros. > > IMHO the extensive list of possible architectures is not really an > improvement. So either a dependency on COMPILE_TEST, or no dependency > at all makes the most sense to me. Fair enough. Herbert, please drop the patch than. Thanks! Gilad -- Gilad Ben-Yossef Chief Coffee Drinker "If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru
Re: [PATCH] crypto: ccree: limit build to plausible archs
On Mon, Apr 23, 2018 at 8:53 PM, Geert Uytterhoeven <ge...@linux-m68k.org> wrote: > Hi Gilad, > > On Mon, Apr 23, 2018 at 3:22 PM, Gilad Ben-Yossef <gi...@benyossef.com> wrote: >> On Mon, Apr 23, 2018 at 3:13 PM, Geert Uytterhoeven >> <ge...@linux-m68k.org> wrote: >>> On Mon, Apr 23, 2018 at 1:48 PM, Gilad Ben-Yossef <gi...@benyossef.com> >>> wrote: >>>> Limit option to compile ccree to plausible architectures. >>> >>> Thanks for your patch! >>> >>>> Suggested-by: Geert Uytterhoeven <ge...@linux-m68k.org> >>>> Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com> >>>> --- >>>> drivers/crypto/Kconfig | 1 + >>>> 1 file changed, 1 insertion(+) >>>> >>>> diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig >>>> index d1ea1a0..7302785 100644 >>>> --- a/drivers/crypto/Kconfig >>>> +++ b/drivers/crypto/Kconfig >>>> @@ -726,6 +726,7 @@ config CRYPTO_DEV_ARTPEC6 >>>> config CRYPTO_DEV_CCREE >>>> tristate "Support for ARM TrustZone CryptoCell family of security >>>> processors" >>>> depends on CRYPTO && CRYPTO_HW && OF && HAS_DMA >>>> + depends on (XTENSA || X86 || UNICORE32 || SUPERH || RISCV || PPC32 >>>> || OPENRISC || NIOS2 || NDS32 || MIPS || MICROBLAZE || HEXAGON || H8300 || >>>> ARM || ARM64 || ARC || COMPILE_TEST) >>> >>> That list looks a bit excessive to me... >> >> I'm sorry, but as an Arm employee I'm not in liberty to identify which >> customer licensed or might license CryptoCell for which platform, now >> or in the future. >> >> I'm sure you understand. > > IC, a clever marketing scheme to make everyone think that everybody else > is already a licensee ;-) I think you are placing too much importance on Kconfig dependencies marketing power, otherwise I would have long ago rented Kconfig space to Saatchi & Saatchi - e.g. "This Kconfig entry is brought to you by... " :-) > > What about using "depends on || COMPILE_TEST", with the > platforms for which the DTS (incl. "arm,cryptocell-*") will be submitted > for v4.18? The list can easily be extended when needed. > Seriously though, I think I was not efficient in communicating my point through. Let me try again: The CryptoCell 712 doesn't exists as silicon anywhere. It's just been released to our design partners not too long ago. I am guessing there are a few SoCs which include CryptoCell 710 which taped out, but probably no publicly available boards yet. By the standard you set above, we shouldn't be enabling the driver build on ANY platform... The boards that came out last year (which I plan to send DT entries for) are using CryptoCell 630p, which we shipped as a design IP a few years ago. It takes years for an IP design to ship, be designed into SoCs, for these SoCs to ship and be designed into boards and until these ship... and when they do, they almost always don't use the cutting edge latest kernel. That is to say - I don't know which SoC and using which architecture the CryptoCell IP was and will be designed into but I want the driver and the kernel to be ready when they do - this IS after all the whole point o doing stuff Upstream First(tm)! This is the same of having random PCI devices depend on PCI and not a specific architecture even if no one shipped a system with that device yet and again the same with I2C devices depending on I2C and not a specific architecture even if we don't have a board out with that I2C device designed it. It's a generic none architecture dependent component. This is why I initially did not mark the device driver as depending on any specific architecture. In light of your request, and what I believe is the underlying idea to cut down as much as possible build time for test code, to which I agree, I've decided to cut out architecture that there is very little chance to even go into a SoC with CryptoCell, such as s390 or um. So, any pointer to an architecture that will not likely to go into a SoC in the coming years with some off the shelf HW IP so I can cut off more is very welcome, but using currently shipping boards to indicate which architecture to support is not appropriate. I hope this makes things a bit clearer. Thanks, Gilad -- Gilad Ben-Yossef Chief Coffee Drinker "If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru
Re: [PATCH] crypto: ccree: limit build to plausible archs
On Mon, Apr 23, 2018 at 3:13 PM, Geert Uytterhoeven <ge...@linux-m68k.org> wrote: > Hi Gilad, > > On Mon, Apr 23, 2018 at 1:48 PM, Gilad Ben-Yossef <gi...@benyossef.com> wrote: >> Limit option to compile ccree to plausible architectures. > > Thanks for your patch! > >> Suggested-by: Geert Uytterhoeven <ge...@linux-m68k.org> >> Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com> >> --- >> drivers/crypto/Kconfig | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig >> index d1ea1a0..7302785 100644 >> --- a/drivers/crypto/Kconfig >> +++ b/drivers/crypto/Kconfig >> @@ -726,6 +726,7 @@ config CRYPTO_DEV_ARTPEC6 >> config CRYPTO_DEV_CCREE >> tristate "Support for ARM TrustZone CryptoCell family of security >> processors" >> depends on CRYPTO && CRYPTO_HW && OF && HAS_DMA >> + depends on (XTENSA || X86 || UNICORE32 || SUPERH || RISCV || PPC32 >> || OPENRISC || NIOS2 || NDS32 || MIPS || MICROBLAZE || HEXAGON || H8300 || >> ARM || ARM64 || ARC || COMPILE_TEST) > > That list looks a bit excessive to me... I'm sorry, but as an Arm employee I'm not in liberty to identify which customer licensed or might license CryptoCell for which platform, now or in the future. I'm sure you understand. Gilad -- Gilad Ben-Yossef Chief Coffee Drinker "If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru
[PATCH] crypto: ccree: limit build to plausible archs
Limit option to compile ccree to plausible architectures. Suggested-by: Geert Uytterhoeven <ge...@linux-m68k.org> Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com> --- drivers/crypto/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig index d1ea1a0..7302785 100644 --- a/drivers/crypto/Kconfig +++ b/drivers/crypto/Kconfig @@ -726,6 +726,7 @@ config CRYPTO_DEV_ARTPEC6 config CRYPTO_DEV_CCREE tristate "Support for ARM TrustZone CryptoCell family of security processors" depends on CRYPTO && CRYPTO_HW && OF && HAS_DMA + depends on (XTENSA || X86 || UNICORE32 || SUPERH || RISCV || PPC32 || OPENRISC || NIOS2 || NDS32 || MIPS || MICROBLAZE || HEXAGON || H8300 || ARM || ARM64 || ARC || COMPILE_TEST) default n select CRYPTO_HASH select CRYPTO_BLKCIPHER -- 2.7.4
Re: [PATCH/RFC] crypto: Add platform dependencies for CRYPTO_DEV_CCREE
On Wed, Apr 18, 2018 at 10:47 AM, Geert Uytterhoeven
<ge...@linux-m68k.org> wrote:
> Hi Gilad,
>
> On Wed, Apr 18, 2018 at 6:32 AM, Gilad Ben-Yossef <gi...@benyossef.com> wrote:
>> On Tue, Apr 17, 2018 at 9:14 PM, Geert Uytterhoeven
>> <ge...@linux-m68k.org> wrote:
>>> The ARM TrustZone CryptoCell is found on ARM SoCs only. Hence make it
>>> depend on ARM or ARM64, unless compile-testing.
>>
>> Actually it is not. Despite what the name suggest, CryptoCell is
>> designed by Arm but is
>> not in fact limited to Arm cores. I think the only requirement is
>> ability to provide an AMBA bus
>> interface. Kudos to our marketing department to make that so clear and
>> so on... :-)
>
> Good to know, I couldn't find any users of the compatible value in DT sources,
> so I had to guess... and missed ;-)
Yes, the original driver that went through staging was for CC 712,
which so new it doesn't yet
have a commercially available silicon yet :-)
I've added the older 710 and 613 support just recently and will be
working with CC hardware implementors
to add the relevant DT bindings for their respective SoCs
>
> Do you have a good suggestion for a platform dependency?
> Based on the above, I'd say "depends on ARM_AMBA || COMPILE_TEST",
> but (currently) ARM_AMBA is selected on ARM or ARM64 only?
So AMBA *as a system bus* is not strictly needed AFAIK in the sense
that you just need
an AMBA to whatever bus interface, so not all system implementing this
actually define ARM_AMBA.
It's actually safer for me to rule out certain architectures rather
than point to which are used.
I'd say ruling out s390, um, alpha, ia64 and m68k is a safe bet.
Do you want to send a patch or shall I?
Thanks,
Gilad
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
--
Gilad Ben-Yossef
Chief Coffee Drinker
"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
-- Jean-Baptiste Queru
[PATCH v2 2/2] crypto: ccree: use proper printk format
Fix incorrect use of %pad as a printk format string for none dma_addr_t
variable.
Discovered via smatch.
Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com>
---
drivers/crypto/ccree/cc_driver.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/ccree/cc_driver.c b/drivers/crypto/ccree/cc_driver.c
index 89ce013..37f2e6e 100644
--- a/drivers/crypto/ccree/cc_driver.c
+++ b/drivers/crypto/ccree/cc_driver.c
@@ -265,7 +265,7 @@ static int init_cc_resources(struct platform_device
*plat_dev)
}
if (rc) {
- dev_err(dev, "Failed in dma_set_mask, mask=%pad\n", _mask);
+ dev_err(dev, "Failed in dma_set_mask, mask=%llx\n", dma_mask);
return rc;
}
--
2.7.4
[PATCH v2 1/2] crypto: ccree: enable support for hardware keys
Enable CryptoCell support for hardware keys.
Hardware keys are regular AES keys loaded into CryptoCell internal memory
via firmware, often from secure boot ROM or hardware fuses at boot time.
As such, they can be used for enc/dec purposes like any other key but
cannot (read: extremely hard to) be extracted since since they are not
available anywhere in RAM during runtime.
The mechanism has some similarities to s390 secure keys although the keys
are not wrapped or sealed, but simply loaded offline. The interface was
therefore modeled based on the s390 secure keys support.
Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com>
---
crypto/testmgr.c | 43 +
drivers/crypto/ccree/cc_cipher.c | 350 ++-
drivers/crypto/ccree/cc_cipher.h | 30 +---
3 files changed, 361 insertions(+), 62 deletions(-)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 397b117..c31da0f 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -2582,6 +2582,13 @@ static const struct alg_test_desc alg_test_descs[] = {
}
}
}, {
+ /* Same as cbc(aes) except the key is stored in
+* hardware secure memory which we reference by index
+*/
+ .alg = "cbc(paes)",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
.alg = "cbc(serpent)",
.test = alg_test_skcipher,
.suite = {
@@ -2728,6 +2735,13 @@ static const struct alg_test_desc alg_test_descs[] = {
}
}
}, {
+ /* Same as ctr(aes) except the key is stored in
+* hardware secure memory which we reference by index
+*/
+ .alg = "ctr(paes)",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
.alg = "ctr(serpent)",
.test = alg_test_skcipher,
.suite = {
@@ -2998,6 +3012,13 @@ static const struct alg_test_desc alg_test_descs[] = {
}
}
}, {
+ /* Same as ecb(aes) except the key is stored in
+* hardware secure memory which we reference by index
+*/
+ .alg = "ecb(paes)",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
.alg = "ecb(khazad)",
.test = alg_test_skcipher,
.suite = {
@@ -3325,6 +3346,13 @@ static const struct alg_test_desc alg_test_descs[] = {
}
}
}, {
+ /* Same as ofb(aes) except the key is stored in
+* hardware secure memory which we reference by index
+*/
+ .alg = "ofb(paes)",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
.alg = "pcbc(fcrypt)",
.test = alg_test_skcipher,
.suite = {
@@ -3582,6 +3610,21 @@ static const struct alg_test_desc alg_test_descs[] = {
}
}
}, {
+ /* Same as xts(aes) except the key is stored in
+* hardware secure memory which we reference by index
+*/
+ .alg = "xts(paes)",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
+ .alg = "xts4096(paes)",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
+ .alg = "xts512(paes)",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
.alg = "xts(camellia)",
.test = alg_test_skcipher,
.suite = {
diff --git a/drivers/crypto/ccree/cc_cipher.c b/drivers/crypto/ccree/cc_cipher.c
index df98f7a..d2810c1 100644
--- a/drivers/crypto/ccree/cc_cipher.c
+++ b/drivers/crypto/ccree/cc_cipher.c
@@ -42,6 +42,7 @@ struct cc_cipher_ctx {
int cipher_mode;
int flow_mode;
unsigned int flags;
+ bool hw_key;
struct cc_user_key_info user;
struct cc_hw_key_info hw;
struct crypto_shash *shash_tfm;
@@ -49,6 +50,13 @@ struct cc_cipher_ctx {
static void cc_cipher_complete(struct device *dev, void *cc_req, int err);
+static inline bool cc_is_hw_key(struct crypto_tfm *tfm)
+{
+ struct cc_cipher_ctx *ctx_p = crypto_tfm_ctx(tfm);
+
+ return ctx_p->hw_key;
+}
+
static int validate_keys_sizes(struct cc_cipher_ctx *ctx_p, u32 size)
{
switch (ctx_p->flow_mode) {
@@ -211,7 +219,7 @@ struct tdes_keys {
u8 key3[DES_KEY_SIZE];
};
-static enum cc_hw_crypto_key hw_key_to_cc_hw_key(int slot_num)
+static enum cc_hw_crypto_ke
[PATCH v2 0/2] cleanup and hardware keys
Small cleanup and add support for CryptoCell hardware keys. Changes from v1: - The cleanup patch is new, as Herbert took the previous one :-) - Hardware key API uses the "paes" designator to indicate a protected key, same as s390, as per Herbert preference - Avoid direct casting and reference of key material, as pointed out by Herbert Gilad Ben-Yossef (2): crypto: ccree: enable support for hardware keys crypto: ccree: use proper printk format crypto/testmgr.c | 43 + drivers/crypto/ccree/cc_cipher.c | 350 ++- drivers/crypto/ccree/cc_cipher.h | 30 +--- drivers/crypto/ccree/cc_driver.c | 2 +- 4 files changed, 362 insertions(+), 63 deletions(-) -- 2.7.4
Re: [PATCH 2/2] crypto: ccree: enable support for hardware keys
On Thu, Apr 19, 2018 at 6:35 AM, Herbert Xu <herb...@gondor.apana.org.au> wrote: > On Mon, Apr 09, 2018 at 11:42:31AM +0300, Gilad Ben-Yossef wrote: >> >> Please look again. The stub version of cc_is_hw_key() doing that is being >> replaced in this patch. > > The point is that the existing mechanism was unused before and this > is new code. So you can't really point to the stubbed-out function > as a precedent. hm... I was trying to point to the s390 implementation as a precedent, not my own stub code. Sorry if I miscommunicated my intent. > >> The s390 key and the cryptocell keys are not the same: >> >> Their is, I believe, is an AES key encrypted by some internal key/algorithm. >> >> The cryptocell "key" is a token, which is internally comprised of one >> or two indexes, referencing slots in the internal memory in the >> hardware, and a key size, that describe the size of the key. >> >> I thought it would be confusing to use "paes" to describe both, since >> they are not interchangeable. >> You would not be able to feed an paes key that works with the s390 >> version to cryptocell and vice verse and get it work. > > Thanks for the info. > >> Having said, if you prefer to have "paes" simply designate >> "implementation specific token for an AES key" I'm perfectly fine with >> that. > > Well by definition none of these hardware keys will be compatible > with each other so I don't really see the point of using individual > algorithm names such as paes or haes. This would make sense only if > they were somehow compatible with each other. > > So instead of using algorithm names, you really want refer to the > specific driver name, which means that they can all use the same > algorithm name. Sounds good to me. > >> > As to your patch specifically, there is one issue where you're >> > directly dereferencing the key as a struct. This is a no-no because >> > the key may have come from user-space. You must treat it as a >> > binary blob. The s390 code seems to do this correctly. >> >> As noted above, the haes "key" is really a token encoding 3 different >> pieces of information: > > My point is that you should not just cast it but instead do a > copy to properly aligned kernel memory. That is a good point I completely missed. Thanks! A v2 will follow shortly. Thanks, Gilad -- Gilad Ben-Yossef Chief Coffee Drinker "If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru
Re: [PATCH/RFC] crypto: Add platform dependencies for CRYPTO_DEV_CCREE
Hi Geert, On Tue, Apr 17, 2018 at 9:14 PM, Geert Uytterhoeven <ge...@linux-m68k.org> wrote: > The ARM TrustZone CryptoCell is found on ARM SoCs only. Hence make it > depend on ARM or ARM64, unless compile-testing. > Actually it is not. Despite what the name suggest, CryptoCell is designed by Arm but is not in fact limited to Arm cores. I think the only requirement is ability to provide an AMBA bus interface. Kudos to our marketing department to make that so clear and so on... :-) There are in fact licensees of this IP which use it with other (Linux running) architectures, perhaps thanks to the fact that the design originated in an outside company (Discretix) which was bought by Arm. Therefore, NAK on the specific patch. However, if there is some build issue with a none Arm architecture I of course very interested to hear about it. Many thanks, Gilad -- Gilad Ben-Yossef Chief Coffee Drinker "If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru
Re: [PATCH 2/2] crypto: ccree: enable support for hardware keys
On Tue, Apr 3, 2018 at 3:22 PM, Milan Broz <gmazyl...@gmail.com> wrote: > On 03/31/2018 07:30 PM, Gilad Ben-Yossef wrote: > ... >>> Are there other crypto drivers doing this? >> >> I thought the exact same thing until I ran into a presentation about the s390 >> secure keys implementation. I basically imitated their use (or abuse?) >> of the Crypto API >> assuming it is the way to go. >> >> Take a look at arch/s390/crypto/paes_s390.c >> >> The slide for the presentation describing this is here: >> http://schd.ws/hosted_files/ossna2017/89/LC2017SecKeyDmCryptV5.pdf >> >> And they seem to even have support for it in the DM-Crypt tools, which at >> the time they claimed to be in the process of getting it up-streamed. > > It is "in the process", but definitely not accepted. > > We are just discussing how to integrate paes wrapped keys in cryptsetup and > it will definitely not be the way presented in the slides above. > > If you plan more such ciphers, I would welcome some unified way in crypto API > how to handle these HSM keys flavors. That would be good. Note however the fine difference - the s390 usage is a wrapped key. Ours is a token for a key (a slot number really). Probably makes no difference for any practical sense, but I thought it is worth mentioning it. > > For kernel dm-crypt, there is no change needed (dmcrypt just treats it as a > normal cipher key). > (I would say that it is not the best idea either, IMHO it would be better to > use > kernel keyring reference instead and somehow handle hw keys through keyring.) > I am all for the keyring approach. In fact, that was the way I wanted to to go to introduce this feature for cryptocell when I discovered that was already upstream code using a different approach. Any suggestion how this would work vis a vis the crypto API usage? e.g. - have a parallel setkey variant added to crypto APi that takes a kernel keyring object rather than actual key? Thanks, Gilad -- Gilad Ben-Yossef Chief Coffee Drinker "If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru
Re: [PATCH 2/2] crypto: ccree: enable support for hardware keys
On Tue, Apr 3, 2018 at 1:19 PM, Herbert Xu <herb...@gondor.apana.org.au> wrote: > On Sat, Mar 31, 2018 at 08:30:46PM +0300, Gilad Ben-Yossef wrote: >> >> However, as it uses the exact same mechanism of the regular xts-aes-ccree >> but takes the key from another source, I've marked it with a test of >> alg_test_null() on the premise that if the xts-aes-ccree works, so must this. > > Well it appears to be stubbed out as cc_is_hw_key always returns > false. Please look again. The stub version of cc_is_hw_key() doing that is being replaced in this patch. >> > Are there other crypto drivers doing this? >> >> I thought the exact same thing until I ran into a presentation about the s390 >> secure keys implementation. I basically imitated their use (or abuse?) >> of the Crypto API >> assuming it is the way to go. >> >> Take a look at arch/s390/crypto/paes_s390.c > > It's always nice to discover code that was never reviewed. :-) > > The general approach seems sane though. > >> Anyway, if this is not the way to go I'd be more than happy to do whatever >> work is needed to create the right interface. >> >> PS. I'd be out of the office and away from email access to the coming week, >> so >> kindly excuse any delay in response. > > I think it's fine. However, I don't really like the idea of everyone > coming up with their own "paes", i.e., your patch's use of "haes". > It should be OK to just use paes for everyone, no? The s390 key and the cryptocell keys are not the same: Their is, I believe, is an AES key encrypted by some internal key/algorithm. The cryptocell "key" is a token, which is internally comprised of one or two indexes, referencing slots in the internal memory in the hardware, and a key size, that describe the size of the key. I thought it would be confusing to use "paes" to describe both, since they are not interchangeable. You would not be able to feed an paes key that works with the s390 version to cryptocell and vice verse and get it work. Having said, if you prefer to have "paes" simply designate "implementation specific token for an AES key" I'm perfectly fine with that. > > As to your patch specifically, there is one issue where you're > directly dereferencing the key as a struct. This is a no-no because > the key may have come from user-space. You must treat it as a > binary blob. The s390 code seems to do this correctly. > As noted above, the haes "key" is really a token encoding 3 different pieces of information: 1. The index of the first key slot to use 2. Potentially, the index of a 2nd key slot to use (for XTS) 3. a key size, denoting the actual key size used, not the slot number I than have to parse this information encoded in the token and feed it to the HW (via 3 different registers) Therefore, I do not see how I can avoid parsing the token. I hope I've managed to explain things better now. Thanks, Gilad -- Gilad Ben-Yossef Chief Coffee Drinker "If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru
Re: [PATCH 2/2] crypto: ccree: enable support for hardware keys
On Fri, Mar 30, 2018 at 8:26 PM, Herbert Xu <herb...@gondor.apana.org.au> wrote:
> On Mon, Mar 26, 2018 at 08:32:19AM +0100, Gilad Ben-Yossef wrote:
>> Enable CryptoCell support for hardware keys.
>>
>> Hardware keys are regular AES keys loaded into CryptoCell internal memory
>> via firmware, often from secure boot ROM or hardware fuses at boot time.
>>
>> As such, they can be used for enc/dec purposes like any other key but
>> cannot (read: extremely hard to) be extracted since since they are not
>> available anywhere in RAM during runtime.
>>
>> The mechanism has some similarities to s390 secure keys although the keys
>> are not wrapped or sealed, but simply loaded offline. The interface was
>> therefore modeled based on the s390 secure keys support.
>>
>> Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com>
>
> ...
>
>> static const struct cc_alg_template skcipher_algs[] = {
>> {
>> + .name = "xts(haes)",
>> + .driver_name = "xts-haes-ccree",
>> + .blocksize = AES_BLOCK_SIZE,
>> + .template_skcipher = {
>> + .setkey = cc_cipher_sethkey,
>> + .encrypt = cc_cipher_encrypt,
>> + .decrypt = cc_cipher_decrypt,
>> + .min_keysize = CC_HW_KEY_SIZE,
>> + .max_keysize = CC_HW_KEY_SIZE,
>> + .ivsize = AES_BLOCK_SIZE,
>> + },
>> + .cipher_mode = DRV_CIPHER_XTS,
>> + .flow_mode = S_DIN_to_AES,
>> + .min_hw_rev = CC_HW_REV_630,
>> + },
>
> How can this possibly pass the self-test?
Indeed, I could not figure a way to test the mechanism directly.
However, as it uses the exact same mechanism of the regular xts-aes-ccree
but takes the key from another source, I've marked it with a test of
alg_test_null() on the premise that if the xts-aes-ccree works, so must this.
>
> If we want to add hardware keys we will need to figure out how
> to deal with it in the top-level API first.
>
> Are there other crypto drivers doing this?
I thought the exact same thing until I ran into a presentation about the s390
secure keys implementation. I basically imitated their use (or abuse?)
of the Crypto API
assuming it is the way to go.
Take a look at arch/s390/crypto/paes_s390.c
The slide for the presentation describing this is here:
http://schd.ws/hosted_files/ossna2017/89/LC2017SecKeyDmCryptV5.pdf
And they seem to even have support for it in the DM-Crypt tools, which at
the time they claimed to be in the process of getting it up-streamed.
Anyway, if this is not the way to go I'd be more than happy to do whatever
work is needed to create the right interface.
PS. I'd be out of the office and away from email access to the coming week, so
kindly excuse any delay in response.
Thanks!
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
-- Jean-Baptiste Queru
[PATCH 0/2] crypto: ccree: cleanup and hardware keys
Small cleanup and add support for CryptoCell hardware keys. Gilad Ben-Yossef (2): crypto: ccree: remove unused enums crypto: ccree: enable support for hardware keys crypto/testmgr.c| 43 drivers/crypto/ccree/cc_cipher.c| 348 drivers/crypto/ccree/cc_cipher.h| 30 +-- drivers/crypto/ccree/cc_hw_queue_defs.h | 28 +-- 4 files changed, 366 insertions(+), 83 deletions(-) -- 2.7.4
[PATCH 1/2] crypto: ccree: remove unused enums
Remove enums definitions unused in the driver code.
Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com>
---
drivers/crypto/ccree/cc_hw_queue_defs.h | 28 +++-
1 file changed, 7 insertions(+), 21 deletions(-)
diff --git a/drivers/crypto/ccree/cc_hw_queue_defs.h
b/drivers/crypto/ccree/cc_hw_queue_defs.h
index bf0d235..a091ae5 100644
--- a/drivers/crypto/ccree/cc_hw_queue_defs.h
+++ b/drivers/crypto/ccree/cc_hw_queue_defs.h
@@ -124,13 +124,6 @@ enum cc_flow_mode {
FLOW_MODE_END = S32_MAX,
};
-enum cc_tunnel_op {
- TUNNEL_OP_INVALID = -1,
- TUNNEL_OFF = 0,
- TUNNEL_ON = 1,
- TUNNEL_OP_END = S32_MAX,
-};
-
enum cc_setup_op {
SETUP_LOAD_NOP = 0,
SETUP_LOAD_STATE0 = 1,
@@ -145,6 +138,13 @@ enum cc_setup_op {
SETUP_OP_END = S32_MAX,
};
+enum cc_hash_conf_pad {
+ HASH_PADDING_DISABLED = 0,
+ HASH_PADDING_ENABLED = 1,
+ HASH_DIGEST_RESULT_LITTLE_ENDIAN = 2,
+ HASH_CONFIG1_PADDING_RESERVE32 = S32_MAX,
+};
+
enum cc_aes_mac_selector {
AES_SK = 1,
AES_CMAC_INIT = 2,
@@ -179,20 +179,6 @@ enum cc_hw_aes_key_size {
END_OF_AES_KEYS = S32_MAX,
};
-enum cc_hw_des_key_size {
- DES_ONE_KEY = 0,
- DES_TWO_KEYS = 1,
- DES_THREE_KEYS = 2,
- END_OF_DES_KEYS = S32_MAX,
-};
-
-enum cc_hash_conf_pad {
- HASH_PADDING_DISABLED = 0,
- HASH_PADDING_ENABLED = 1,
- HASH_DIGEST_RESULT_LITTLE_ENDIAN = 2,
- HASH_CONFIG1_PADDING_RESERVE32 = S32_MAX,
-};
-
enum cc_hash_cipher_pad {
DO_NOT_PAD = 0,
DO_PAD = 1,
--
2.7.4
[PATCH 2/2] crypto: ccree: enable support for hardware keys
Enable CryptoCell support for hardware keys.
Hardware keys are regular AES keys loaded into CryptoCell internal memory
via firmware, often from secure boot ROM or hardware fuses at boot time.
As such, they can be used for enc/dec purposes like any other key but
cannot (read: extremely hard to) be extracted since since they are not
available anywhere in RAM during runtime.
The mechanism has some similarities to s390 secure keys although the keys
are not wrapped or sealed, but simply loaded offline. The interface was
therefore modeled based on the s390 secure keys support.
Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com>
---
crypto/testmgr.c | 43 +
drivers/crypto/ccree/cc_cipher.c | 348 ++-
drivers/crypto/ccree/cc_cipher.h | 30 +---
3 files changed, 359 insertions(+), 62 deletions(-)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index af4a01c..8a5a60c 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -2558,6 +2558,13 @@ static const struct alg_test_desc alg_test_descs[] = {
}
}
}, {
+ /* Same as cbc(aes) except the key is stored in
+* hardware secure memory which we reference by index
+*/
+ .alg = "cbc(haes)",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
.alg = "cbc(serpent)",
.test = alg_test_skcipher,
.suite = {
@@ -2704,6 +2711,13 @@ static const struct alg_test_desc alg_test_descs[] = {
}
}
}, {
+ /* Same as ctr(aes) except the key is stored in
+* hardware secure memory which we reference by index
+*/
+ .alg = "ctr(haes)",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
.alg = "ctr(serpent)",
.test = alg_test_skcipher,
.suite = {
@@ -2974,6 +2988,13 @@ static const struct alg_test_desc alg_test_descs[] = {
}
}
}, {
+ /* Same as ecb(aes) except the key is stored in
+* hardware secure memory which we reference by index
+*/
+ .alg = "ecb(haes)",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
.alg = "ecb(khazad)",
.test = alg_test_skcipher,
.suite = {
@@ -3301,6 +3322,13 @@ static const struct alg_test_desc alg_test_descs[] = {
}
}
}, {
+ /* Same as ofb(aes) except the key is stored in
+* hardware secure memory which we reference by index
+*/
+ .alg = "ofb(haes)",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
.alg = "pcbc(fcrypt)",
.test = alg_test_skcipher,
.suite = {
@@ -3558,6 +3586,21 @@ static const struct alg_test_desc alg_test_descs[] = {
}
}
}, {
+ /* Same as xts(aes) except the key is stored in
+* hardware secure memory which we reference by index
+*/
+ .alg = "xts(haes)",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
+ .alg = "xts4096(haes)",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
+ .alg = "xts512(haes)",
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
.alg = "xts(camellia)",
.test = alg_test_skcipher,
.suite = {
diff --git a/drivers/crypto/ccree/cc_cipher.c b/drivers/crypto/ccree/cc_cipher.c
index df98f7a..8ccb7c4 100644
--- a/drivers/crypto/ccree/cc_cipher.c
+++ b/drivers/crypto/ccree/cc_cipher.c
@@ -42,6 +42,7 @@ struct cc_cipher_ctx {
int cipher_mode;
int flow_mode;
unsigned int flags;
+ bool hw_key;
struct cc_user_key_info user;
struct cc_hw_key_info hw;
struct crypto_shash *shash_tfm;
@@ -49,6 +50,13 @@ struct cc_cipher_ctx {
static void cc_cipher_complete(struct device *dev, void *cc_req, int err);
+static inline bool cc_is_hw_key(struct crypto_tfm *tfm)
+{
+ struct cc_cipher_ctx *ctx_p = crypto_tfm_ctx(tfm);
+
+ return ctx_p->hw_key;
+}
+
static int validate_keys_sizes(struct cc_cipher_ctx *ctx_p, u32 size)
{
switch (ctx_p->flow_mode) {
@@ -211,7 +219,7 @@ struct tdes_keys {
u8 key3[DES_KEY_SIZE];
};
-static enum cc_hw_crypto_key hw_key_to_cc_hw_key(int slot_num)
+static enum cc_hw_crypto_k
[PATCH 1/2] crypto: introduce SM4 symmetric cipher algorithm
Introduce the SM4 cipher algorithms (OSCCA GB/T 32907-2016).
SM4 (GBT.32907-2016) is a cryptographic standard issued by the
Organization of State Commercial Administration of China (OSCCA)
as an authorized cryptographic algorithms for the use within China.
SMS4 was originally created for use in protecting wireless
networks, and is mandated in the Chinese National Standard for
Wireless LAN WAPI (Wired Authentication and Privacy Infrastructure)
(GB.15629.11-2003).
Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com>
---
crypto/Kconfig | 25 ++
crypto/Makefile | 1 +
crypto/sm4_generic.c | 244 +++
include/crypto/sm4.h | 28 ++
4 files changed, 298 insertions(+)
create mode 100644 crypto/sm4_generic.c
create mode 100644 include/crypto/sm4.h
diff --git a/crypto/Kconfig b/crypto/Kconfig
index de693e0..4b8df3a 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -1475,6 +1475,31 @@ config CRYPTO_SERPENT_AVX2_X86_64
See also:
<http://www.cl.cam.ac.uk/~rja14/serpent.html>
+config CRYPTO_SM4
+ tristate "SM4 cipher algorithm"
+ select CRYPTO_ALGAPI
+ help
+ SM4 cipher algorithms (OSCCA GB/T 32907-2016).
+
+ SM4 (GBT.32907-2016) is a cryptographic standard issued by the
+ Organization of State Commercial Administration of China (OSCCA)
+ as an authorized cryptographic algorithms for the use within China.
+
+ SMS4 was originally created for use in protecting wireless
+ networks, and is mandated in the Chinese National Standard for
+ Wireless LAN WAPI (Wired Authentication and Privacy Infrastructure)
+ (GB.15629.11-2003).
+
+ The latest SM4 standard (GBT.32907-2016) was proposed by OSCCA and
+ standardized through TC 260 of the Standardization Administration
+ of the People's Republic of China (SAC).
+
+ The input, output, and key of SMS4 are each 128 bits.
+
+ See also: <https://eprint.iacr.org/2008/329.pdf>
+
+ If unsure, say N.
+
config CRYPTO_SPECK
tristate "Speck cipher algorithm"
select CRYPTO_ALGAPI
diff --git a/crypto/Makefile b/crypto/Makefile
index 04517b2..eb4d9cd 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -100,6 +100,7 @@ obj-$(CONFIG_CRYPTO_SERPENT) += serpent_generic.o
CFLAGS_serpent_generic.o := $(call cc-option,-fsched-pressure) #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79149
obj-$(CONFIG_CRYPTO_AES) += aes_generic.o
CFLAGS_aes_generic.o := $(call cc-option,-fno-code-hoisting) #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83356
+obj-$(CONFIG_CRYPTO_SM4) += sm4_generic.o
obj-$(CONFIG_CRYPTO_AES_TI) += aes_ti.o
obj-$(CONFIG_CRYPTO_CAMELLIA) += camellia_generic.o
obj-$(CONFIG_CRYPTO_CAST_COMMON) += cast_common.o
diff --git a/crypto/sm4_generic.c b/crypto/sm4_generic.c
new file mode 100644
index 000..f537a27
--- /dev/null
+++ b/crypto/sm4_generic.c
@@ -0,0 +1,244 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/*
+ * SM4 Cipher Algorithm.
+ *
+ * Copyright (C) 2018 ARM Limited or its affiliates.
+ * All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static const u32 fk[4] = {
+ 0xa3b1bac6, 0x56aa3350, 0x677d9197, 0xb27022dc
+};
+
+static const u8 sbox[256] = {
+ 0xd6, 0x90, 0xe9, 0xfe, 0xcc, 0xe1, 0x3d, 0xb7,
+ 0x16, 0xb6, 0x14, 0xc2, 0x28, 0xfb, 0x2c, 0x05,
+ 0x2b, 0x67, 0x9a, 0x76, 0x2a, 0xbe, 0x04, 0xc3,
+ 0xaa, 0x44, 0x13, 0x26, 0x49, 0x86, 0x06, 0x99,
+ 0x9c, 0x42, 0x50, 0xf4, 0x91, 0xef, 0x98, 0x7a,
+ 0x33, 0x54, 0x0b, 0x43, 0xed, 0xcf, 0xac, 0x62,
+ 0xe4, 0xb3, 0x1c, 0xa9, 0xc9, 0x08, 0xe8, 0x95,
+ 0x80, 0xdf, 0x94, 0xfa, 0x75, 0x8f, 0x3f, 0xa6,
+ 0x47, 0x07, 0xa7, 0xfc, 0xf3, 0x73, 0x17, 0xba,
+ 0x83, 0x59, 0x3c, 0x19, 0xe6, 0x85, 0x4f, 0xa8,
+ 0x68, 0x6b, 0x81, 0xb2, 0x71, 0x64, 0xda, 0x8b,
+ 0xf8, 0xeb, 0x0f, 0x4b, 0x70, 0x56, 0x9d, 0x35,
+ 0x1e, 0x24, 0x0e, 0x5e, 0x63, 0x58, 0xd1, 0xa2,
+ 0x25, 0x22, 0x7c, 0x3b, 0x01, 0x21, 0x78, 0x87,
+ 0xd4, 0x00, 0x46, 0x57, 0x9f, 0xd3, 0x27, 0x52,
+ 0x4c, 0x36, 0x02, 0xe7, 0xa0, 0xc4, 0xc8, 0x9e,
+ 0xea, 0xbf, 0x8a, 0xd2, 0x40, 0xc7, 0x38, 0xb5,
+ 0xa3, 0xf7, 0xf2, 0xce, 0xf9, 0x61, 0x15, 0xa1,
+ 0xe0, 0xae, 0x5d, 0xa4, 0x9b, 0x34, 0x1a, 0x55,
+ 0xad, 0x93, 0x32, 0x30, 0xf5, 0x8c, 0xb1, 0xe3,
+ 0x1d, 0xf6, 0xe2, 0x2e, 0x82, 0x66, 0xca, 0x60,
+ 0xc0, 0x29, 0x23, 0xab, 0x0d, 0x53, 0x4e, 0x6f,
+ 0xd5, 0xdb, 0x37, 0x45, 0xde, 0xfd, 0x8e, 0x2f,
+ 0x03, 0xff, 0x6a, 0x72, 0x6d, 0x6c, 0x5b, 0x51,
+ 0x8d, 0x1b, 0xaf, 0x92, 0xbb, 0xdd, 0xbc, 0x7f,
+ 0x11, 0xd9, 0x5c, 0x41, 0x1f, 0x10, 0x5a, 0xd8,
+ 0x0a, 0xc1, 0x31, 0x88, 0xa5, 0xcd, 0x7b, 0xbd,
+ 0x2d, 0x74, 0xd0, 0x12, 0xb8, 0xe5, 0xb4, 0xb0,
+ 0x89, 0x69, 0x97, 0x4a
[PATCH 2/2] crypto: introduce SM4 testmgr tests
Add testmgr tests for the newly introduced SM4 ECB symmetric cipher.
Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com>
---
crypto/tcrypt.c | 3 ++
crypto/testmgr.c | 9
crypto/testmgr.h | 131 +++
3 files changed, 143 insertions(+)
diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
index 14213a0..51fe7c8 100644
--- a/crypto/tcrypt.c
+++ b/crypto/tcrypt.c
@@ -1983,6 +1983,9 @@ static int do_test(const char *alg, u32 type, u32 mask,
int m)
case 190:
ret += tcrypt_test("authenc(hmac(sha512),cbc(des3_ede))");
break;
+ case 191:
+ ret += tcrypt_test("ecb(sm4)");
+ break;
case 200:
test_cipher_speed("ecb(aes)", ENCRYPT, sec, NULL, 0,
speed_template_16_24_32);
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 9f82e7b..af4a01c 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -3001,6 +3001,15 @@ static const struct alg_test_desc alg_test_descs[] = {
}
}
}, {
+ .alg = "ecb(sm4)",
+ .test = alg_test_skcipher,
+ .suite = {
+ .cipher = {
+ .enc = __VECS(sm4_enc_tv_template),
+ .dec = __VECS(sm4_dec_tv_template)
+ }
+ }
+ }, {
.alg = "ecb(speck128)",
.test = alg_test_skcipher,
.suite = {
diff --git a/crypto/testmgr.h b/crypto/testmgr.h
index 73ba22c..c80ed56 100644
--- a/crypto/testmgr.h
+++ b/crypto/testmgr.h
@@ -14324,6 +14324,137 @@ static const struct cipher_testvec
serpent_xts_dec_tv_template[] = {
};
/*
+ * SM4 test vector taken from the draft RFC
+ * https://tools.ietf.org/html/draft-crypto-sm4-00#ref-GBT.32907-2016
+ */
+
+static const struct cipher_testvec sm4_enc_tv_template[] = {
+ { /* SM4 Appendix A: Example Calculations. Example 1. */
+ .key= "\x01\x23\x45\x67\x89\xAB\xCD\xEF"
+ "\xFE\xDC\xBA\x98\x76\x54\x32\x10",
+ .klen = 16,
+ .input = "\x01\x23\x45\x67\x89\xAB\xCD\xEF"
+ "\xFE\xDC\xBA\x98\x76\x54\x32\x10",
+ .ilen = 16,
+ .result = "\x68\x1E\xDF\x34\xD2\x06\x96\x5E"
+ "\x86\xB3\xE9\x4F\x53\x6E\x42\x46",
+ .rlen = 16,
+ }, { /*
+ * SM4 Appendix A: Example Calculations.
+ * Last 10 iterations of Example 2.
+ */
+ .key= "\x01\x23\x45\x67\x89\xAB\xCD\xEF"
+ "\xFE\xDC\xBA\x98\x76\x54\x32\x10",
+ .klen = 16,
+ .input = "\x99\x4a\xc3\xe7\xc3\x57\x89\x6a"
+ "\x81\xfc\xa8\xe\x38\x3e\xef\x80"
+ "\xb1\x98\xf2\xde\x3f\x4b\xae\xd1"
+ "\xf0\xf1\x30\x4c\x1\x27\x5a\x8f"
+ "\x45\xe1\x39\xb7\xae\xff\x1f\x27"
+ "\xad\x57\x15\xab\x31\x5d\xc\xef"
+ "\x8c\xc8\x80\xbd\x11\x98\xf3\x7b"
+ "\xa2\xdd\x14\x20\xf9\xe8\xbb\x82"
+ "\xf7\x32\xca\x4b\xa8\xf7\xb3\x4d"
+ "\x27\xd1\xcd\xe6\xb6\x65\x5a\x23"
+ "\xc2\xf3\x54\x84\x53\xe3\xb9\x20"
+ "\xa5\x37\x0\xbe\xe7\x7b\x48\xfb"
+ "\x21\x3d\x9e\x48\x1d\x9e\xf5\xbf"
+ "\x77\xd5\xb4\x4a\x53\x71\x94\x7a"
+ "\x88\xa6\x6e\x6\x93\xca\x43\xa5"
+ "\xc4\xf6\xcd\x53\x4b\x7b\x8e\xfe"
+ "\xb4\x28\x7c\x42\x29\x32\x5d\x88"
+ "\xed\xce\x0\x19\xe\x16\x2\x6e"
+ "\x87\xff\x2c\xac\xe8\xe7\xe9\xbf"
+ "\x31\x51\xec\x47\xc3\x51\x83\xc1",
+ .ilen = 160,
+ .result = "\xb1\x98\xf2\xde\x3f\x4b\xae\xd1"
+ "\xf0\xf1\x30\x4c\x1\x27\x5a\x8f"
+ "\x45\xe1\x39\xb7\xae\xff\x1f\x27"
+ "\xad\x57\x15\xab\x31\x5d\xc\xef"
+ "\x8c\xc8\x80\xbd\x11\x98\xf3\x7b"
+ "\xa2\xdd\x14\x20\xf9\xe8\xbb\x82"
+ "\xf7\x32\xca\x4b\xa8\xf7\xb3\x4d"
+ "\x27\xd1\xcd\xe6\xb6\x65\x5a\x23"
+ "\xc2\xf3\x54\x84\x53\xe3\x
[PATCH 0/2] crypto: introduce SM4 symmetric cipher algorithm
Introduce the SM4 cipher algorithms (OSCCA GB/T 32907-2016) and related tests. SM4 (GBT.32907-2016) is a cryptographic standard issued by the Organization of State Commercial Administration of China (OSCCA) as an authorized cryptographic algorithms for the use within China. SMS4 was originally created for use in protecting wireless networks, and is mandated in the Chinese National Standard for Wireless LAN WAPI (Wired Authentication and Privacy Infrastructure) (GB.15629.11-2003). Tested on arm 64 and 32 bit. Gilad Ben-Yossef (2): crypto: introduce SM4 symmetric cipher algorithm crypto: introduce SM4 testmgr tests crypto/Kconfig | 25 ++ crypto/Makefile | 1 + crypto/sm4_generic.c | 244 +++ crypto/tcrypt.c | 3 + crypto/testmgr.c | 9 ++ crypto/testmgr.h | 131 +++ include/crypto/sm4.h | 28 ++ 7 files changed, 441 insertions(+) create mode 100644 crypto/sm4_generic.c create mode 100644 include/crypto/sm4.h -- 2.7.4
Re: [dm-devel] Integrity checking fails with Atmel SHA hw accelerator enabled
Hi,
I'm adding the linux crypto mailing list because it seems relevant.
On Fri, Feb 23, 2018 at 2:25 PM, Gigi W <gigitekw...@gmail.com> wrote:
> Thanks for the input!
>
> See below
>
>
> On Fri, Feb 23, 2018 at 10:53 AM Gilad Ben-Yossef <gi...@benyossef.com>
> wrote:
>>
>> On Fri, Feb 23, 2018 at 10:30 AM, Gigi W <gigitekw...@gmail.com> wrote:
>> > Hi
>> >
>> > I'm having some trouble using dm-verity for a squashfs root file system
>> > that
>> > seems to be related to the
>> > Atmel SHA hw accelerator in the kernel, CONFIG_CRYPTO_DEV_ATMEL_SHA
>> >
>> > Some info about my setup:
>> > * I'm using a board with a SAMA5D4 CPU.
>> > * I'm using Yocto rocko for building an image for that device.
>> >
>> > The idea is that Using the 4.14.14 Kernel, Integrity checking using
>> > Kernel
>> > crypto fails with Atmel SHA hw accelerator enabled in kernel.
>> > By disabling it, `CONFIG_CRYPTO_DEV_ATMEL_SHA=n`, and using the software
>> > sha256 algo, integrity checking works as expected.
>> > This is my kernel config [3]
>> >
>> > Using the 4.8.4 Kernel and Atmel SHA hw accelerator enabled, everything
>> > was
>> > ok.
>> >
>> > This is what triggers the error during verified boot:
>> >
>> > status=`veritysetup create vroot $root_dev $verity_dev --hash-offset
>> > $hashoffset $root_hash`
>> >
>> > mount /dev/mapper/vroot /mnt/
>> > mount_ok=`cat /proc/mounts | grep mnt`
>> > if [ -z "$mount_ok" ] ; then
>> > echo "Failed to mount $root_dev on mnt/"
>> > else
>> > echo "Switch rootfs"
>> > exec switch_root -c /dev/console /mnt /sbin/init
>> > fi
>> >
>> > The mount operation fails:
>> >
>> > device-mapper: verity: 179:4: metadata block 2 is corrupted
>> > EXT4-fs (dm-0): unable to read superblock
>> > device-mapper: verity: 179:4: metadata block 2 is corrupted
>> > EXT4-fs (dm-0): unable to read superblock
>> > device-mapper: verity: 179:4: metadata block 2 is corrupted
>> > EXT4-fs (dm-0): unable to read superblock
>> > device-mapper: verity: 179:4: metadata block 2 is corrupted
>> > SQUASHFS error: squashfs_read_data failed to read block 0x0
>> > squashfs: SQUASHFS error: unable to read squashfs_super_block
>> > device-mapper: verity: 179:4: metadata block 2 is corrupted
>> > FAT-fs (dm-0): unable to read boot sector
>> > mount: mounting /dev/mapper/vroot on /mnt/ failed: Input/output error
>> > Failed to mount /dev/mmcblk0p4 on mnt/
>> > reboot: Restarting system
>> > Reboot failed -- System halted
>> >
>> > Using veritysetup to verify the integrity against the hashes is
>> > successful,
>> > as it's not using the kernel for that ...
>> >
>> >
>> > So it looks like it something changed from 4.8.4 to 4.14.14.
>>
>> If I am not mistaken the Atmel SHA hw accelerator is an async (read:
>> off CPU) crypto accelerator.
>> Up until 4.12 (I think...) DM-Verity did not use async crypto
>> accelerators (even if present and have high
>> priority). I've changed this is commit d1ac3ff008fb ("dm verity:
>> switch to using asynchronous hash crypto API").
>
>
> This would explain some things, like the same speeds while reading from a
> verity device, having the CONFIG_CRYPTO_DEV_ATMEL_SHA enabled and then
> disabled, on the 4.8.4 kernel -> it was always using the sync API.
>
>>
>>
>> Is it possible that whatever issue you are seeing has always been
>> there and when DM-Verity started using
>> async. accelerators it was only exposed?
>
>
> It looks like it.
>
> From my understandings + tests described above, Atmel SHA hw accelerator
> works correctly - output hashes are ok, dm-verity with other async crypto
> accelerators is working ok,
> but dm-verity + Atmel SHA hw accelerator don't play nice together.
>
> I couldn't find anyone else complaining about this.
>
I agree that that the possibility that there is something wrong in the
Atmel SHA accelerator is one possible direction.
The other one is that there is something wrong in DM-Verity that only
manifests under certain conditions when working with async crypto HW
providers.
I don't think it is the case, because I tested DM-Verity after my
changes with the CryptoCell async HW provider and did not get any
other bug reports, but I'd like to be sure.
Can you do a little experiment? add debug printk to show the data
being hashed, the hash produced by atmel and the expected
pre-calculated hash.
If the theory that there is something wrong with atmel accelerator, we
can calculate the hash on the data with other means (software) and
should get a different hash.
If you are having trouble adding the printk's in the right place let
me know and I'll create a patch for you to test.
Cheers,
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
-- Jean-Baptiste Queru
[PATCH 1/4] crypto: ccree: remove unused definitions
Remove enum definition which are not used by the REE interface
driver.
Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com>
---
drivers/crypto/ccree/cc_crypto_ctx.h | 20
1 file changed, 20 deletions(-)
diff --git a/drivers/crypto/ccree/cc_crypto_ctx.h
b/drivers/crypto/ccree/cc_crypto_ctx.h
index 5cb4dde..06a7860 100644
--- a/drivers/crypto/ccree/cc_crypto_ctx.h
+++ b/drivers/crypto/ccree/cc_crypto_ctx.h
@@ -146,24 +146,4 @@ enum drv_hash_hw_mode {
DRV_HASH_HW_RESERVE32B = S32_MAX
};
-/* drv_crypto_key_type[1:0] is mapped to cipher_do[1:0] */
-/* drv_crypto_key_type[2] is mapped to cipher_config2 */
-enum drv_crypto_key_type {
- DRV_NULL_KEY = -1,
- DRV_USER_KEY = 0, /* 0x000 */
- DRV_ROOT_KEY = 1, /* 0x001 */
- DRV_PROVISIONING_KEY = 2, /* 0x010 */
- DRV_SESSION_KEY = 3,/* 0x011 */
- DRV_APPLET_KEY = 4, /* NA */
- DRV_PLATFORM_KEY = 5, /* 0x101 */
- DRV_CUSTOMER_KEY = 6, /* 0x110 */
- DRV_END_OF_KEYS = S32_MAX,
-};
-
-enum drv_crypto_padding_type {
- DRV_PADDING_NONE = 0,
- DRV_PADDING_PKCS7 = 1,
- DRV_PADDING_RESERVE32B = S32_MAX
-};
-
#endif /* _CC_CRYPTO_CTX_H_ */
--
2.7.4
[PATCH 0/4] cleanups and new HW rev support
This patch set introduces backward compatible support for the older CryptoCell hardware revision 710 and 630 along some minor code cleanups. Gilad Ben-Yossef (4): crypto: ccree: remove unused definitions dt-bindings: Add DT bindings for ccree 710 and 630p crypto: ccree: add support for older HW revs crypto: ccree: replace memset+kfree with kzfree .../devicetree/bindings/crypto/arm-cryptocell.txt | 3 +- drivers/crypto/Kconfig | 6 +- drivers/crypto/ccree/cc_aead.c | 34 +++-- drivers/crypto/ccree/cc_cipher.c | 25 +++- drivers/crypto/ccree/cc_crypto_ctx.h | 36 - drivers/crypto/ccree/cc_driver.c | 68 -- drivers/crypto/ccree/cc_driver.h | 23 +++- drivers/crypto/ccree/cc_fips.c | 13 +- drivers/crypto/ccree/cc_hash.c | 149 +++-- drivers/crypto/ccree/cc_hash.h | 12 +- drivers/crypto/ccree/cc_host_regs.h| 3 + drivers/crypto/ccree/cc_hw_queue_defs.h| 2 +- drivers/crypto/ccree/cc_kernel_regs.h | 1 + drivers/crypto/ccree/cc_request_mgr.c | 9 +- drivers/crypto/ccree/cc_sram_mgr.c | 14 ++ 15 files changed, 240 insertions(+), 158 deletions(-) -- 2.7.4
[PATCH 3/4] crypto: ccree: add support for older HW revs
Add support for the legacy CryptoCell 630 and 710 revs.
Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com>
---
drivers/crypto/Kconfig | 6 +-
drivers/crypto/ccree/cc_aead.c | 34 ++--
drivers/crypto/ccree/cc_cipher.c| 25 +-
drivers/crypto/ccree/cc_crypto_ctx.h| 16
drivers/crypto/ccree/cc_driver.c| 68 ---
drivers/crypto/ccree/cc_driver.h| 23 -
drivers/crypto/ccree/cc_fips.c | 13 ++-
drivers/crypto/ccree/cc_hash.c | 149
drivers/crypto/ccree/cc_hash.h | 12 +--
drivers/crypto/ccree/cc_host_regs.h | 3 +
drivers/crypto/ccree/cc_hw_queue_defs.h | 2 +-
drivers/crypto/ccree/cc_kernel_regs.h | 1 +
drivers/crypto/ccree/cc_request_mgr.c | 6 +-
drivers/crypto/ccree/cc_sram_mgr.c | 14 +++
14 files changed, 237 insertions(+), 135 deletions(-)
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index b26e5d2..5c41069 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -750,9 +750,9 @@ config CRYPTO_DEV_CCREE
select CRYPTO_CTR
select CRYPTO_XTS
help
- Say 'Y' to enable a driver for the Arm TrustZone CryptoCell
- family of processors. Currently only the CryptoCell 712 REE
- is supported.
+ Say 'Y' to enable a driver for the REE interface of the Arm
+ TrustZone CryptoCell family of processors. Currently the
+ CryptoCell 712, 710 and 630 are supported.
Choose this if you wish to use hardware acceleration of
cryptographic operations on the system REE.
If unsure say Y.
diff --git a/drivers/crypto/ccree/cc_aead.c b/drivers/crypto/ccree/cc_aead.c
index 3e1046a..03f4b9f 100644
--- a/drivers/crypto/ccree/cc_aead.c
+++ b/drivers/crypto/ccree/cc_aead.c
@@ -327,7 +327,7 @@ static int hmac_setkey(struct cc_hw_desc *desc, struct
cc_aead_ctx *ctx)
/* Load the hash current length*/
hw_desc_init([idx]);
set_cipher_mode([idx], hash_mode);
- set_din_const([idx], 0, HASH_LEN_SIZE);
+ set_din_const([idx], 0, ctx->drvdata->hash_len_sz);
set_flow_mode([idx], S_DIN_to_HASH);
set_setup_mode([idx], SETUP_LOAD_KEY0);
idx++;
@@ -465,7 +465,7 @@ static int cc_get_plain_hmac_key(struct crypto_aead *tfm,
const u8 *key,
/* Load the hash current length*/
hw_desc_init([idx]);
set_cipher_mode([idx], hashmode);
- set_din_const([idx], 0, HASH_LEN_SIZE);
+ set_din_const([idx], 0, ctx->drvdata->hash_len_sz);
set_cipher_config1([idx], HASH_PADDING_ENABLED);
set_flow_mode([idx], S_DIN_to_HASH);
set_setup_mode([idx], SETUP_LOAD_KEY0);
@@ -877,7 +877,7 @@ static void cc_proc_digest_desc(struct aead_request *req,
set_setup_mode([idx], SETUP_WRITE_STATE0);
set_dout_dlli([idx], req_ctx->icv_dma_addr, ctx->authsize,
NS_BIT, 1);
- set_queue_last_ind([idx]);
+ set_queue_last_ind(ctx->drvdata, [idx]);
if (ctx->auth_mode == DRV_HASH_XCBC_MAC) {
set_aes_not_hash_mode([idx]);
set_cipher_mode([idx], DRV_CIPHER_XCBC_MAC);
@@ -893,7 +893,7 @@ static void cc_proc_digest_desc(struct aead_request *req,
set_flow_mode([idx], S_HASH_to_DOUT);
set_dout_dlli([idx], req_ctx->mac_buf_dma_addr,
ctx->authsize, NS_BIT, 1);
- set_queue_last_ind([idx]);
+ set_queue_last_ind(ctx->drvdata, [idx]);
set_cipher_config0([idx],
HASH_DIGEST_RESULT_LITTLE_ENDIAN);
set_cipher_config1([idx], HASH_PADDING_DISABLED);
@@ -1001,7 +1001,7 @@ static void cc_set_hmac_desc(struct aead_request *req,
struct cc_hw_desc desc[],
hw_desc_init([idx]);
set_cipher_mode([idx], hash_mode);
set_din_sram([idx], cc_digest_len_addr(ctx->drvdata, hash_mode),
-HASH_LEN_SIZE);
+ctx->drvdata->hash_len_sz);
set_flow_mode([idx], S_DIN_to_HASH);
set_setup_mode([idx], SETUP_LOAD_KEY0);
idx++;
@@ -1098,7 +1098,7 @@ static void cc_proc_scheme_desc(struct aead_request *req,
hw_desc_init([idx]);
set_cipher_mode([idx], hash_mode);
set_dout_sram([idx], aead_handle->sram_workspace_addr,
- HASH_LEN_SIZE);
+ ctx->drvdata->hash_len_sz);
set_flow_mode([idx], S_HASH_to_DOUT);
set_setup_mode([idx], SETUP_WRITE_STATE1);
set_cipher_do([idx], DO_PAD);
@@ -1128,7 +1128,7 @@
[PATCH 2/4] dt-bindings: Add DT bindings for ccree 710 and 630p
Add device tree bindings for Arm CryptoCell 710 and 630p hardware revisions. Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com> --- Documentation/devicetree/bindings/crypto/arm-cryptocell.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt b/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt index cec8d5d..c2598ab 100644 --- a/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt +++ b/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt @@ -1,7 +1,8 @@ Arm TrustZone CryptoCell cryptographic engine Required properties: -- compatible: Should be "arm,cryptocell-712-ree". +- compatible: Should be one of: "arm,cryptocell-712-ree", + "arm,cryptocell-710-ree" or "arm,cryptocell-630p-ree". - reg: Base physical address of the engine and length of memory mapped region. - interrupts: Interrupt number for the device. -- 2.7.4
[PATCH 4/4] crypto: ccree: replace memset+kfree with kzfree
Replace memset to 0 followed by kfree with kzfree for simplicity. Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com> --- drivers/crypto/ccree/cc_request_mgr.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/crypto/ccree/cc_request_mgr.c b/drivers/crypto/ccree/cc_request_mgr.c index 2fa0663..83a8aaae 100644 --- a/drivers/crypto/ccree/cc_request_mgr.c +++ b/drivers/crypto/ccree/cc_request_mgr.c @@ -81,8 +81,7 @@ void cc_req_mgr_fini(struct cc_drvdata *drvdata) /* Kill tasklet */ tasklet_kill(_mgr_h->comptask); #endif - memset(req_mgr_h, 0, sizeof(struct cc_req_mgr_handle)); - kfree(req_mgr_h); + kzfree(req_mgr_h); drvdata->request_mgr_handle = NULL; } -- 2.7.4
Re: [PATCH v3 4/4] crypto: add CRYPTO_TFM_REQ_IV_SERIALIZE flag
On Sat, Feb 10, 2018 at 12:04 AM, Stephan Müller <smuel...@chronox.de> wrote: > Crypto drivers may implement a streamlined serialization support for AIO > requests that is reported by the CRYPTO_ALG_SERIALIZES_IV_ACCESS flag to > the crypto user. When the user decides that he wants to send multiple > AIO requests concurrently and wants the crypto driver to handle the > serialization, the caller has to set CRYPTO_TFM_REQ_IV_SERIALIZE to notify > the crypto driver. > > Only when this flag is enabled, the crypto driver shall apply its > serialization logic for handling IV updates between requests. If this > flag is not provided, the serialization logic shall not be applied by > the driver as the caller decides that it does not need it (because no > parallel AIO requests are sent) or that it performs its own > serialization. Tested and it is working with the ccree driver which supports IV serialization. Tested-by: Gilad Ben-Yossef <gi...@benyossef.com> Gilad -- Gilad Ben-Yossef Chief Coffee Drinker "If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru
Re: [PATCH] crypto: AF_ALG AIO - lock context IV
On Thu, Feb 1, 2018 at 12:04 PM, Stephan Mueller <smuel...@chronox.de> wrote: > Am Donnerstag, 1. Februar 2018, 10:35:07 CET schrieb Gilad Ben-Yossef: > > Hi Gilad, > >> > >> > Which works well for the sort of optimization I did and for hardware that >> > can do iv dependency tracking itself. If hardware dependency tracking was >> > avilable, you would be able to queue up requests with a chained IV >> > without taking any special precautions at all. The hardware would >> > handle the IV update dependencies. >> > >> > So in conclusion, Stephan's approach should work and give us a nice >> > small patch suitable for stable inclusion. >> > >> > However, if people know that their setup overhead can be put in parallel >> > with previous requests (even when the IV is not yet updated) then they >> > will >> > probably want to do something inside their own driver and set the flag >> > that Stephan is proposing adding to bypass the mutex approach. >> >> The patches from Stephan looks good to me, but I think we can do better >> for the long term approach you are discussing. > > What you made me think of is the following: shouldn't we relay the inline IV > flag on to the crypto drivers? > > The reason is to allow a clean implementation of the enabling or disabling of > the dependency handling in the driver. Jonathan's driver, for example, decides > based on the pointer value of the IV buffer whether it is the same buffer and > thus dependency handling is to be applied. This is fragile. > > As AF_ALG knows whether the inline IV with separate IVs per request or the > serialization with one IV buffer for all requests is requested, it should > relay this state on to the drivers. Thus, for example, Jonathan's driver can > be changed to rely on this flag instead on the buffer pointer value to decide > whether to enable its dependency handling. Yes, that is exactly what I was trying to point out :-) Thanks, Gilad -- Gilad Ben-Yossef Chief Coffee Drinker "If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru
Re: [PATCH] crypto: AF_ALG AIO - lock context IV
On Thu, Feb 1, 2018 at 11:46 AM, Stephan Mueller <smuel...@chronox.de> wrote: > Am Donnerstag, 1. Februar 2018, 10:35:07 CET schrieb Gilad Ben-Yossef: > > Hi Gilad, > >> Hi, >> >> > >> > Quoting a private email from Stephan (at Stephan's suggestion) >> > >> >> What I however could fathom is that we introduce a flag where a driver >> >> implements its own queuing mechanism. In this case, the mutex handling >> >> would be disregarded. >> > >> > Which works well for the sort of optimization I did and for hardware that >> > can do iv dependency tracking itself. If hardware dependency tracking was >> > avilable, you would be able to queue up requests with a chained IV >> > without taking any special precautions at all. The hardware would >> > handle the IV update dependencies. >> > >> > So in conclusion, Stephan's approach should work and give us a nice >> > small patch suitable for stable inclusion. >> > >> > However, if people know that their setup overhead can be put in parallel >> > with previous requests (even when the IV is not yet updated) then they >> > will >> > probably want to do something inside their own driver and set the flag >> > that Stephan is proposing adding to bypass the mutex approach. >> >> The patches from Stephan looks good to me, but I think we can do better >> for the long term approach you are discussing. >> >> Consider that the issue we are dealing with is in no way unique to the >> AF_ALG use case, it just happens to expose it. >> >> The grander issue is, I believe, that we are missing an API for chained >> crypto operations. One that allows submitting multiple concurrent but >> dependent requests >> to tfm providers. >> >> Trying to second guess whether or not there is a dependency between calls >> from the address of the IV is not a clean solution. Why don't we make it >> explicit? >> >> For example, a flag that can be set on a tfm that states that the subsequent >> series of requests are interdependent. If you need a different stream, >> simply allocated anotehr >> tfm object. > > But this is already implemented, is it not considering the discussed patches? > > Again, here are the use cases I see for AIO: > > - multiple IOCBs which are totally separate and have no interdependencies: the > inline IV approach > > - multiple IOCBs which are interdependent: the current API with the patches > that we are discussing here (note, a new patch set is coming after the merge > window) > > - if you have several independent invocations of multiple interdependent > IOCBs: call accept() again on the TFM-FD to get another operations FD. This is > followed either option one or two above. Note, this is the idea behind the > kcapi_handle_reinit() call just added to libkcapi. So, you have multiple > operation-FDs on which you do either interdependent operation or inline IV > handling. >> >> This will let each driver do it's best, be it a simple mutex, software >> queuing or hardware >> dependency tracking as the case m may be. > > Again, I am wondering that with the discussed patch set we have this > functionality already. >> >> Than of course, AF_ALG code (or any other user for that matter) will >> not need to handle >> interdependence, just set the right flag. > > The issue is that some drivers simply do not handle this interdependency at > all -- see the bug report from Harsh. > > Thus, the current patch set (again which will be updated after the merge > window) contains: > > 1. adding a mutex to AF_ALG to ensure serialization of interdependent calls > (option 2 from above) irrespective whether the driver implements support for > it or not. > > 2. add the inline IV handling (to serve option 1) > > 3. add a flag that can be set by the crypto implementation. If this flag is > set, then the mutex of AF_ALG is *not* set assuming that the crypto driver > handles the serialization. > > Note, option 3 from above is implemented in the proper usage of the AF_ALG > interface. Sorry for not communicating clearly enough. I was not objecting at all. Let me try again. What I was trying to say is, more succinctly hopefully this time: 1. Advocating for that 3rd option. I did not understand the plan include adding it, 2. Pointing out that the problem solved (and rightfully so) by mutex in AF_ALG AIO implementation must exists elsewhere as well - for example IPsec, and is probably solved there too, so if we add the flag as suggested, it can be used there as well to gain similar benefits to what Jonathan is suggesting. Thanks, Gilad -- Gilad Ben-Yossef Chief Coffee Drinker "If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru
Re: [PATCH] crypto: AF_ALG AIO - lock context IV
t;| [REQUEST 2 from userspace] > [AF_ALG/SOCKET] | >| [AF_ALG/SOCKET] > [BUILD / MAP HW DESCS] | >| [BUILD / MAP HW DESCS] * BEFORE > SERIALIZATION * > NOTHING BLOCKING | >| IV in flight (enqueue sw queue) >[Place in HW Queue]| >| | >[Process] | >| | > [Interrupt] | >| | > [Respond and update IV] Nothing Blocking (dequeue sw queue) >| [Place in HW Queue] > Don't care beyond here. | > [Process] > | > [Interrupt] > | > [Respond and update IV] > | > Don't care beyond here. > >> >> This maintains chaining when needed and gets a good chunk of the lost >> performance back. I believe (though yet to verify) the remaining lost >> performance is mostly down to the fact we can't coalesce interrupts if >> chaining. >> >> Note the driver is deliberately a touch 'simplistic' so there may be other >> optimization opportunities to get some of the lost performance back or >> it may be fundamental due to the fact the raw processing can't be in >> parallel. >> > > Quoting a private email from Stephan (at Stephan's suggestion) > >> What I however could fathom is that we introduce a flag where a driver >> implements its own queuing mechanism. In this case, the mutex handling would >> be disregarded. > > Which works well for the sort of optimization I did and for hardware that > can do iv dependency tracking itself. If hardware dependency tracking was > avilable, you would be able to queue up requests with a chained IV > without taking any special precautions at all. The hardware would > handle the IV update dependencies. > > So in conclusion, Stephan's approach should work and give us a nice > small patch suitable for stable inclusion. > > However, if people know that their setup overhead can be put in parallel > with previous requests (even when the IV is not yet updated) then they will > probably want to do something inside their own driver and set the flag > that Stephan is proposing adding to bypass the mutex approach. > The patches from Stephan looks good to me, but I think we can do better for the long term approach you are discussing. Consider that the issue we are dealing with is in no way unique to the AF_ALG use case, it just happens to expose it. The grander issue is, I believe, that we are missing an API for chained crypto operations. One that allows submitting multiple concurrent but dependent requests to tfm providers. Trying to second guess whether or not there is a dependency between calls from the address of the IV is not a clean solution. Why don't we make it explicit? For example, a flag that can be set on a tfm that states that the subsequent series of requests are interdependent. If you need a different stream, simply allocated anotehr tfm object. This will let each driver do it's best, be it a simple mutex, software queuing or hardware dependency tracking as the case m may be. Than of course, AF_ALG code (or any other user for that matter) will not need to handle interdependence, just set the right flag. Do you think this makes sense? Thanks, Gilad -- Gilad Ben-Yossef Chief Coffee Drinker "If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru
Re: [PATCHv2] tls: Add support for encryption using async offload accelerator
On Wed, Jan 31, 2018 at 7:34 PM, Dave Watson <davejwat...@fb.com> wrote:
> On 01/31/18 05:22 PM, Vakul Garg wrote:
>> > > On second though in stable we should probably just disable async tfm
>> > > allocations.
>> > > It's simpler. But this approach is still good for -next
>> > >
>> > >
>> > > Gilad
>> >
>> > I agree with Gilad, just disable async for now.
>> >
>>
>> How to do it? Can you help with the api name?
>
> *aead = crypto_alloc_aead("gcm(aes)", 0, CRYPTO_ALG_ASYNC);
>
> https://github.com/ktls/net_next_ktls/commit/f3b9b402e755e4b0623fa83f88137173fc249f2d
I said disabling async tfms is the right way to go for -stable since
it's the simplest and less risky way
of plugging this bug.
I don't think this is the way to go for -next (and it seems davem
agrees with me). Vakul's
patch looks good to me for now.
>
>> > If the flag MSG_DONTWAIT is set, we should be returning -EINPROGRESS and
>> > not wait for a response. I had started working on a patch for that, but
>> > it's
>> > pretty tricky to get right.
>>
That would be a great addition, but I don't think we need to wait for
that. It can come later.
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
-- Jean-Baptiste Queru
Re: [PATCH] tls: Add support for encryption using async offload accelerator
On Wed, Jan 31, 2018 at 8:10 AM, Gilad Ben-Yossef <gi...@benyossef.com> wrote: > Hi Vakul, > > On Wed, Jan 31, 2018 at 12:36 PM, Vakul Garg <vakul.g...@nxp.com> wrote: >> Async crypto accelerators (e.g. drivers/crypto/caam) support offloading >> GCM operation. If they are enabled, crypto_aead_encrypt() return error >> code -EINPROGRESS. In this case tls_do_encryption() needs to wait on a >> completion till the time the response for crypto offload request is >> received. >> > > Thank you for this patch. I think it is actually a bug fix and should > probably go into stable On second though in stable we should probably just disable async tfm allocations. It's simpler. But this approach is still good for -next Gilad -- Gilad Ben-Yossef Chief Coffee Drinker "If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru
Re: [PATCH] tls: Add support for encryption using async offload accelerator
Hi Vakul,
On Wed, Jan 31, 2018 at 12:36 PM, Vakul Garg <vakul.g...@nxp.com> wrote:
> Async crypto accelerators (e.g. drivers/crypto/caam) support offloading
> GCM operation. If they are enabled, crypto_aead_encrypt() return error
> code -EINPROGRESS. In this case tls_do_encryption() needs to wait on a
> completion till the time the response for crypto offload request is
> received.
>
Thank you for this patch. I think it is actually a bug fix and should
probably go into stable
since I believe current code is broken on machines where any async GCM
transformation
is registered with a high enough priority as it will try to call a
NULL callback.
But, please use the new crypto_wait_req() and friends to implement the waiting.
Take a look at the code example in
Documentation/crypto/api-samples.rst to see how.
Also, maybe add an explanation why CRYPTO_TFM_REQ_MAY_BACKLOG
flag should not be used here, if this was on purpose?
I mean I'm not sure using backlog here is a good idea but probably
should explain why
not.
Thanks!
Gilad
> Signed-off-by: Vakul Garg <vakul.g...@nxp.com>
> ---
> net/tls/tls_sw.c | 22 ++
> 1 file changed, 22 insertions(+)
>
> diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
> index 73d19210dd49..390e6dc7b135 100644
> --- a/net/tls/tls_sw.c
> +++ b/net/tls/tls_sw.c
> @@ -39,6 +39,11 @@
>
> #include
>
> +struct crypto_completion {
> + struct completion comp;
> + int result;
> +};
> +
> static void trim_sg(struct sock *sk, struct scatterlist *sg,
> int *sg_num_elem, unsigned int *sg_size, int target_size)
> {
> @@ -194,6 +199,14 @@ static void tls_free_both_sg(struct sock *sk)
> >sg_plaintext_size);
> }
>
> +static void crypto_complete(struct crypto_async_request *req, int err)
> +{
> + struct crypto_completion *x = req->data;
> +
> + x->result = err;
> + complete(>comp);
> +}
> +
> static int tls_do_encryption(struct tls_context *tls_ctx,
> struct tls_sw_context *ctx, size_t data_len,
> gfp_t flags)
> @@ -202,6 +215,7 @@ static int tls_do_encryption(struct tls_context *tls_ctx,
> crypto_aead_reqsize(ctx->aead_send);
> struct aead_request *aead_req;
> int rc;
> + struct crypto_completion crypto_done;
>
> aead_req = kzalloc(req_size, flags);
> if (!aead_req)
> @@ -214,7 +228,15 @@ static int tls_do_encryption(struct tls_context *tls_ctx,
> aead_request_set_ad(aead_req, TLS_AAD_SPACE_SIZE);
> aead_request_set_crypt(aead_req, ctx->sg_aead_in, ctx->sg_aead_out,
>data_len, tls_ctx->iv);
> + aead_request_set_callback(aead_req, 0, crypto_complete, _done);
> +
> + init_completion(_done.comp);
> +
> rc = crypto_aead_encrypt(aead_req);
> + if (rc == -EINPROGRESS) {
> + wait_for_completion(_done.comp);
> + rc = crypto_done.result;
> + }
>
> ctx->sg_encrypted_data[0].offset -= tls_ctx->prepend_size;
> ctx->sg_encrypted_data[0].length += tls_ctx->prepend_size;
> --
> 2.13.6
>
--
Gilad Ben-Yossef
Chief Coffee Drinker
"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
-- Jean-Baptiste Queru
[PATCH v2 3/7] crypto: ccree: add skcipher support
Add CryptoCell skcipher support
Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com>
---
drivers/crypto/ccree/Makefile|2 +-
drivers/crypto/ccree/cc_buffer_mgr.c | 125
drivers/crypto/ccree/cc_buffer_mgr.h |8 +
drivers/crypto/ccree/cc_cipher.c | 1130 ++
drivers/crypto/ccree/cc_cipher.h | 59 ++
drivers/crypto/ccree/cc_driver.c | 11 +
drivers/crypto/ccree/cc_driver.h |6 +-
7 files changed, 1339 insertions(+), 2 deletions(-)
create mode 100644 drivers/crypto/ccree/cc_cipher.c
create mode 100644 drivers/crypto/ccree/cc_cipher.h
diff --git a/drivers/crypto/ccree/Makefile b/drivers/crypto/ccree/Makefile
index 6b204ab..a7fecad 100644
--- a/drivers/crypto/ccree/Makefile
+++ b/drivers/crypto/ccree/Makefile
@@ -1,6 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_CRYPTO_DEV_CCREE) := ccree.o
-ccree-y := cc_driver.o cc_buffer_mgr.o cc_request_mgr.o cc_ivgen.o
cc_sram_mgr.o
+ccree-y := cc_driver.o cc_buffer_mgr.o cc_request_mgr.o cc_cipher.o cc_ivgen.o
cc_sram_mgr.o
ccree-$(CONFIG_DEBUG_FS) += cc_debugfs.o
ccree-$(CONFIG_PM) += cc_pm.o
diff --git a/drivers/crypto/ccree/cc_buffer_mgr.c
b/drivers/crypto/ccree/cc_buffer_mgr.c
index 4c67579..46be101 100644
--- a/drivers/crypto/ccree/cc_buffer_mgr.c
+++ b/drivers/crypto/ccree/cc_buffer_mgr.c
@@ -8,6 +8,7 @@
#include "cc_buffer_mgr.h"
#include "cc_lli_defs.h"
+#include "cc_cipher.h"
enum dma_buffer_type {
DMA_NULL_TYPE = -1,
@@ -347,6 +348,130 @@ static int cc_map_sg(struct device *dev, struct
scatterlist *sg,
return 0;
}
+void cc_unmap_cipher_request(struct device *dev, void *ctx,
+unsigned int ivsize, struct scatterlist *src,
+struct scatterlist *dst)
+{
+ struct cipher_req_ctx *req_ctx = (struct cipher_req_ctx *)ctx;
+
+ if (req_ctx->gen_ctx.iv_dma_addr) {
+ dev_dbg(dev, "Unmapped iv: iv_dma_addr=%pad iv_size=%u\n",
+ _ctx->gen_ctx.iv_dma_addr, ivsize);
+ dma_unmap_single(dev, req_ctx->gen_ctx.iv_dma_addr,
+ivsize,
+req_ctx->is_giv ? DMA_BIDIRECTIONAL :
+DMA_TO_DEVICE);
+ }
+ /* Release pool */
+ if (req_ctx->dma_buf_type == CC_DMA_BUF_MLLI &&
+ req_ctx->mlli_params.mlli_virt_addr) {
+ dma_pool_free(req_ctx->mlli_params.curr_pool,
+ req_ctx->mlli_params.mlli_virt_addr,
+ req_ctx->mlli_params.mlli_dma_addr);
+ }
+
+ dma_unmap_sg(dev, src, req_ctx->in_nents, DMA_BIDIRECTIONAL);
+ dev_dbg(dev, "Unmapped req->src=%pK\n", sg_virt(src));
+
+ if (src != dst) {
+ dma_unmap_sg(dev, dst, req_ctx->out_nents, DMA_BIDIRECTIONAL);
+ dev_dbg(dev, "Unmapped req->dst=%pK\n", sg_virt(dst));
+ }
+}
+
+int cc_map_cipher_request(struct cc_drvdata *drvdata, void *ctx,
+ unsigned int ivsize, unsigned int nbytes,
+ void *info, struct scatterlist *src,
+ struct scatterlist *dst, gfp_t flags)
+{
+ struct cipher_req_ctx *req_ctx = (struct cipher_req_ctx *)ctx;
+ struct mlli_params *mlli_params = _ctx->mlli_params;
+ struct buff_mgr_handle *buff_mgr = drvdata->buff_mgr_handle;
+ struct device *dev = drvdata_to_dev(drvdata);
+ struct buffer_array sg_data;
+ u32 dummy = 0;
+ int rc = 0;
+ u32 mapped_nents = 0;
+
+ req_ctx->dma_buf_type = CC_DMA_BUF_DLLI;
+ mlli_params->curr_pool = NULL;
+ sg_data.num_of_buffers = 0;
+
+ /* Map IV buffer */
+ if (ivsize) {
+ dump_byte_array("iv", (u8 *)info, ivsize);
+ req_ctx->gen_ctx.iv_dma_addr =
+ dma_map_single(dev, (void *)info,
+ ivsize,
+ req_ctx->is_giv ? DMA_BIDIRECTIONAL :
+ DMA_TO_DEVICE);
+ if (dma_mapping_error(dev, req_ctx->gen_ctx.iv_dma_addr)) {
+ dev_err(dev, "Mapping iv %u B at va=%pK for DMA
failed\n",
+ ivsize, info);
+ return -ENOMEM;
+ }
+ dev_dbg(dev, "Mapped iv %u B at va=%pK to dma=%pad\n",
+ ivsize, info, _ctx->gen_ctx.iv_dma_addr);
+ } else {
+ req_ctx->gen_ctx.iv_dma_addr = 0;
+ }
+
+ /* Map the src SGL */
+ rc = cc_map_sg(dev, src, nbytes, DMA_BIDIRECTIONAL, _ctx->in_nents,
+ LLI_MAX_NUM_OF_DATA_ENTRIES, , _nents);
+ if (rc) {
+ rc = -ENOMEM;
+
[PATCH v2 1/7] staging: ccree: rename staging ver and mark as broken
Rename the Kconfig var of the staging tree version of the driver in preparation of introducing the final version of the driver into the cryptodev tree to avoid link time symbol collisions. Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com> --- drivers/staging/ccree/Kconfig | 4 ++-- drivers/staging/ccree/Makefile | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/staging/ccree/Kconfig b/drivers/staging/ccree/Kconfig index 0b3092b..a84b6ab 100644 --- a/drivers/staging/ccree/Kconfig +++ b/drivers/staging/ccree/Kconfig @@ -1,6 +1,6 @@ -config CRYPTO_DEV_CCREE +config CRYPTO_DEV_CCREE_OLD tristate "Support for ARM TrustZone CryptoCell C7XX family of Crypto accelerators" - depends on CRYPTO && CRYPTO_HW && OF && HAS_DMA + depends on CRYPTO && CRYPTO_HW && OF && HAS_DMA && BROKEN default n select CRYPTO_HASH select CRYPTO_BLKCIPHER diff --git a/drivers/staging/ccree/Makefile b/drivers/staging/ccree/Makefile index ae702f3..1e7d105 100644 --- a/drivers/staging/ccree/Makefile +++ b/drivers/staging/ccree/Makefile @@ -1,3 +1,3 @@ -obj-$(CONFIG_CRYPTO_DEV_CCREE) := ccree.o +obj-$(CONFIG_CRYPTO_DEV_CCREE_OLD) := ccree.o ccree-y := ssi_driver.o ssi_sysfs.o ssi_buffer_mgr.o ssi_request_mgr.o ssi_cipher.o ssi_hash.o ssi_aead.o ssi_ivgen.o ssi_sram_mgr.o ssi_pm.o ccree-$(CONFIG_CRYPTO_FIPS) += ssi_fips.o -- 2.7.4
[PATCH v2 0/7] crypto: ccree: Introduce Arm TrustZone CryptoCell
Arm TrustZone CryptoCell is a security hardware IP that includes support for hardware based hash, digest, cipher and AEAD operations. This driver provides support for these as part of the Linux Crypto sub-system. The driver spent some time now in the staging tree being cleaned up and is now submitted for review for the purpose of moving into the crypto tree. The first patch therefore renames its copy in the staging directory Kconfig define and marks it broken, otherwise there is a build failure due to global symbols collisions. Please note that the driver include stubs for yet unexposed functionality (ivgen and secure HW keys), which will be added later. Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com> Changes from v1: - Use KConfig directive to stop staging tree version to not collide during link time as opposed to deleting it as indicated by Greg KH. - Switched from legacy ablkcipher to skcipher interface as indicated by Corentin Labbe. - Removed unused zero_buff struct as indicated by Corentin Labbe. - Moved to kzfree for all IV/key buffers as indicated by Corentin Labbe. - Moved to using __des3_ede_setkey() in lieu of home grown version as indicated by Stephan Mueller. - Fixed multiple small coding style from Dan Carpenter and others. - Fixed pointer signedness sparse warnings as indicated by Jeremy Sowden. - Rename all registered algs driver name to -ccree prefix Gilad Ben-Yossef (7): staging: ccree: rename staging ver and mark as broken crypto: ccree: introduce CryptoCell driver crypto: ccree: add skcipher support crypto: ccree: add ahash support crypto: ccree: add AEAD support crypto: ccree: add FIPS support MAINTAINERS: update ccree entry MAINTAINERS |5 +- drivers/crypto/Kconfig | 27 + drivers/crypto/Makefile |1 + drivers/crypto/ccree/Makefile |7 + drivers/crypto/ccree/cc_aead.c | 2702 +++ drivers/crypto/ccree/cc_aead.h | 109 ++ drivers/crypto/ccree/cc_buffer_mgr.c| 1651 +++ drivers/crypto/ccree/cc_buffer_mgr.h| 72 + drivers/crypto/ccree/cc_cipher.c| 1130 + drivers/crypto/ccree/cc_cipher.h| 59 + drivers/crypto/ccree/cc_crypto_ctx.h| 170 ++ drivers/crypto/ccree/cc_debugfs.c | 101 ++ drivers/crypto/ccree/cc_debugfs.h | 32 + drivers/crypto/ccree/cc_driver.c| 476 ++ drivers/crypto/ccree/cc_driver.h| 194 +++ drivers/crypto/ccree/cc_fips.c | 111 ++ drivers/crypto/ccree/cc_fips.h | 37 + drivers/crypto/ccree/cc_hash.c | 2296 ++ drivers/crypto/ccree/cc_hash.h | 114 ++ drivers/crypto/ccree/cc_host_regs.h | 142 ++ drivers/crypto/ccree/cc_hw_queue_defs.h | 590 +++ drivers/crypto/ccree/cc_ivgen.c | 280 drivers/crypto/ccree/cc_ivgen.h | 55 + drivers/crypto/ccree/cc_kernel_regs.h | 167 ++ drivers/crypto/ccree/cc_lli_defs.h | 59 + drivers/crypto/ccree/cc_pm.c| 122 ++ drivers/crypto/ccree/cc_pm.h| 57 + drivers/crypto/ccree/cc_request_mgr.c | 713 drivers/crypto/ccree/cc_request_mgr.h | 51 + drivers/crypto/ccree/cc_sram_mgr.c | 107 ++ drivers/crypto/ccree/cc_sram_mgr.h | 65 + drivers/staging/ccree/Kconfig |4 +- drivers/staging/ccree/Makefile |2 +- 33 files changed, 11702 insertions(+), 6 deletions(-) create mode 100644 drivers/crypto/ccree/Makefile create mode 100644 drivers/crypto/ccree/cc_aead.c create mode 100644 drivers/crypto/ccree/cc_aead.h create mode 100644 drivers/crypto/ccree/cc_buffer_mgr.c create mode 100644 drivers/crypto/ccree/cc_buffer_mgr.h create mode 100644 drivers/crypto/ccree/cc_cipher.c create mode 100644 drivers/crypto/ccree/cc_cipher.h create mode 100644 drivers/crypto/ccree/cc_crypto_ctx.h create mode 100644 drivers/crypto/ccree/cc_debugfs.c create mode 100644 drivers/crypto/ccree/cc_debugfs.h create mode 100644 drivers/crypto/ccree/cc_driver.c create mode 100644 drivers/crypto/ccree/cc_driver.h create mode 100644 drivers/crypto/ccree/cc_fips.c create mode 100644 drivers/crypto/ccree/cc_fips.h create mode 100644 drivers/crypto/ccree/cc_hash.c create mode 100644 drivers/crypto/ccree/cc_hash.h create mode 100644 drivers/crypto/ccree/cc_host_regs.h create mode 100644 drivers/crypto/ccree/cc_hw_queue_defs.h create mode 100644 drivers/crypto/ccree/cc_ivgen.c create mode 100644 drivers/crypto/ccree/cc_ivgen.h create mode 100644 drivers/crypto/ccree/cc_kernel_regs.h create mode 100644 drivers/crypto/ccree/cc_lli_defs.h create mode 100644 drivers/crypto/ccree/cc_pm.c create mode 100644 drivers/crypto/ccree/cc_pm.h create mode 100644 drivers/crypto/ccree/cc_request_mgr.c create mode 100644 drivers/crypto/ccree/cc_request_mgr.h create mode 100644 drivers/crypto/ccree/cc_sram_mgr.c creat
[PATCH v2 2/7] crypto: ccree: introduce CryptoCell driver
Introduce basic low level Arm TrustZone CryptoCell HW support. This first patch doesn't actually register any Crypto API transformations, these will follow up in the next patch. This first revision supports the CC 712 REE component. Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com> --- drivers/crypto/Kconfig | 27 ++ drivers/crypto/Makefile | 1 + drivers/crypto/ccree/Makefile | 6 + drivers/crypto/ccree/cc_buffer_mgr.c| 387 + drivers/crypto/ccree/cc_buffer_mgr.h| 60 +++ drivers/crypto/ccree/cc_crypto_ctx.h| 170 drivers/crypto/ccree/cc_debugfs.c | 101 + drivers/crypto/ccree/cc_debugfs.h | 32 ++ drivers/crypto/ccree/cc_driver.c| 417 +++ drivers/crypto/ccree/cc_driver.h| 186 + drivers/crypto/ccree/cc_host_regs.h | 142 +++ drivers/crypto/ccree/cc_hw_queue_defs.h | 590 ++ drivers/crypto/ccree/cc_ivgen.c | 280 + drivers/crypto/ccree/cc_ivgen.h | 55 +++ drivers/crypto/ccree/cc_kernel_regs.h | 167 drivers/crypto/ccree/cc_lli_defs.h | 59 +++ drivers/crypto/ccree/cc_pm.c| 118 ++ drivers/crypto/ccree/cc_pm.h| 57 +++ drivers/crypto/ccree/cc_request_mgr.c | 713 drivers/crypto/ccree/cc_request_mgr.h | 51 +++ drivers/crypto/ccree/cc_sram_mgr.c | 107 + drivers/crypto/ccree/cc_sram_mgr.h | 65 +++ 22 files changed, 3791 insertions(+) create mode 100644 drivers/crypto/ccree/Makefile create mode 100644 drivers/crypto/ccree/cc_buffer_mgr.c create mode 100644 drivers/crypto/ccree/cc_buffer_mgr.h create mode 100644 drivers/crypto/ccree/cc_crypto_ctx.h create mode 100644 drivers/crypto/ccree/cc_debugfs.c create mode 100644 drivers/crypto/ccree/cc_debugfs.h create mode 100644 drivers/crypto/ccree/cc_driver.c create mode 100644 drivers/crypto/ccree/cc_driver.h create mode 100644 drivers/crypto/ccree/cc_host_regs.h create mode 100644 drivers/crypto/ccree/cc_hw_queue_defs.h create mode 100644 drivers/crypto/ccree/cc_ivgen.c create mode 100644 drivers/crypto/ccree/cc_ivgen.h create mode 100644 drivers/crypto/ccree/cc_kernel_regs.h create mode 100644 drivers/crypto/ccree/cc_lli_defs.h create mode 100644 drivers/crypto/ccree/cc_pm.c create mode 100644 drivers/crypto/ccree/cc_pm.h create mode 100644 drivers/crypto/ccree/cc_request_mgr.c create mode 100644 drivers/crypto/ccree/cc_request_mgr.h create mode 100644 drivers/crypto/ccree/cc_sram_mgr.c create mode 100644 drivers/crypto/ccree/cc_sram_mgr.h diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig index 47ec920..ed912bf 100644 --- a/drivers/crypto/Kconfig +++ b/drivers/crypto/Kconfig @@ -731,4 +731,31 @@ config CRYPTO_DEV_ARTPEC6 To compile this driver as a module, choose M here. +config CRYPTO_DEV_CCREE + tristate "Support for ARM TrustZone CryptoCell family of security processors" + depends on CRYPTO && CRYPTO_HW && OF && HAS_DMA + default n + select CRYPTO_HASH + select CRYPTO_BLKCIPHER + select CRYPTO_DES + select CRYPTO_AEAD + select CRYPTO_AUTHENC + select CRYPTO_SHA1 + select CRYPTO_MD5 + select CRYPTO_SHA256 + select CRYPTO_SHA512 + select CRYPTO_HMAC + select CRYPTO_AES + select CRYPTO_CBC + select CRYPTO_ECB + select CRYPTO_CTR + select CRYPTO_XTS + help + Say 'Y' to enable a driver for the Arm TrustZone CryptoCell + family of processors. Currently only the CryptoCell 712 REE + is supported. + Choose this if you wish to use hardware acceleration of + cryptographic operations on the system REE. + If unsure say Y. + endif # CRYPTO_HW diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile index 2513d13..ee5ec5c9 100644 --- a/drivers/crypto/Makefile +++ b/drivers/crypto/Makefile @@ -6,6 +6,7 @@ obj-$(CONFIG_CRYPTO_DEV_ATMEL_ECC) += atmel-ecc.o obj-$(CONFIG_CRYPTO_DEV_BFIN_CRC) += bfin_crc.o obj-$(CONFIG_CRYPTO_DEV_CAVIUM_ZIP) += cavium/ obj-$(CONFIG_CRYPTO_DEV_CCP) += ccp/ +obj-$(CONFIG_CRYPTO_DEV_CCREE) += ccree/ obj-$(CONFIG_CRYPTO_DEV_CHELSIO) += chelsio/ obj-$(CONFIG_CRYPTO_DEV_CPT) += cavium/cpt/ obj-$(CONFIG_CRYPTO_DEV_NITROX) += cavium/nitrox/ diff --git a/drivers/crypto/ccree/Makefile b/drivers/crypto/ccree/Makefile new file mode 100644 index 000..6b204ab --- /dev/null +++ b/drivers/crypto/ccree/Makefile @@ -0,0 +1,6 @@ +# SPDX-License-Identifier: GPL-2.0 + +obj-$(CONFIG_CRYPTO_DEV_CCREE) := ccree.o +ccree-y := cc_driver.o cc_buffer_mgr.o cc_request_mgr.o cc_ivgen.o cc_sram_mgr.o +ccree-$(CONFIG_DEBUG_FS) += cc_debugfs.o +ccree-$(CONFIG_PM) += cc_pm.o diff --git a/drivers/crypto/ccree/cc_buffer_mgr.c b/drivers/crypto/ccree/cc_buffer_mgr.c new file mode 100644 index 000..4c67579
[PATCH v2 5/7] crypto: ccree: add AEAD support
Add CryptoCell AEAD support
Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com>
---
drivers/crypto/ccree/Makefile|2 +-
drivers/crypto/ccree/cc_aead.c | 2702 ++
drivers/crypto/ccree/cc_aead.h | 109 ++
drivers/crypto/ccree/cc_buffer_mgr.c | 882 +++
drivers/crypto/ccree/cc_buffer_mgr.h |4 +
drivers/crypto/ccree/cc_driver.c | 10 +
drivers/crypto/ccree/cc_driver.h |2 +
7 files changed, 3710 insertions(+), 1 deletion(-)
create mode 100644 drivers/crypto/ccree/cc_aead.c
create mode 100644 drivers/crypto/ccree/cc_aead.h
diff --git a/drivers/crypto/ccree/Makefile b/drivers/crypto/ccree/Makefile
index 1109480..7cb3082 100644
--- a/drivers/crypto/ccree/Makefile
+++ b/drivers/crypto/ccree/Makefile
@@ -1,6 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_CRYPTO_DEV_CCREE) := ccree.o
-ccree-y := cc_driver.o cc_buffer_mgr.o cc_request_mgr.o cc_cipher.o cc_hash.o
cc_ivgen.o cc_sram_mgr.o
+ccree-y := cc_driver.o cc_buffer_mgr.o cc_request_mgr.o cc_cipher.o cc_hash.o
cc_aead.o cc_ivgen.o cc_sram_mgr.o
ccree-$(CONFIG_DEBUG_FS) += cc_debugfs.o
ccree-$(CONFIG_PM) += cc_pm.o
diff --git a/drivers/crypto/ccree/cc_aead.c b/drivers/crypto/ccree/cc_aead.c
new file mode 100644
index 000..3e1046a
--- /dev/null
+++ b/drivers/crypto/ccree/cc_aead.c
@@ -0,0 +1,2702 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (C) 2012-2018 ARM Limited or its affiliates. */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "cc_driver.h"
+#include "cc_buffer_mgr.h"
+#include "cc_aead.h"
+#include "cc_request_mgr.h"
+#include "cc_hash.h"
+#include "cc_sram_mgr.h"
+
+#define template_aead template_u.aead
+
+#define MAX_AEAD_SETKEY_SEQ 12
+#define MAX_AEAD_PROCESS_SEQ 23
+
+#define MAX_HMAC_DIGEST_SIZE (SHA256_DIGEST_SIZE)
+#define MAX_HMAC_BLOCK_SIZE (SHA256_BLOCK_SIZE)
+
+#define AES_CCM_RFC4309_NONCE_SIZE 3
+#define MAX_NONCE_SIZE CTR_RFC3686_NONCE_SIZE
+
+/* Value of each ICV_CMP byte (of 8) in case of success */
+#define ICV_VERIF_OK 0x01
+
+struct cc_aead_handle {
+ cc_sram_addr_t sram_workspace_addr;
+ struct list_head aead_list;
+};
+
+struct cc_hmac_s {
+ u8 *padded_authkey;
+ u8 *ipad_opad; /* IPAD, OPAD*/
+ dma_addr_t padded_authkey_dma_addr;
+ dma_addr_t ipad_opad_dma_addr;
+};
+
+struct cc_xcbc_s {
+ u8 *xcbc_keys; /* K1,K2,K3 */
+ dma_addr_t xcbc_keys_dma_addr;
+};
+
+struct cc_aead_ctx {
+ struct cc_drvdata *drvdata;
+ u8 ctr_nonce[MAX_NONCE_SIZE]; /* used for ctr3686 iv and aes ccm */
+ u8 *enckey;
+ dma_addr_t enckey_dma_addr;
+ union {
+ struct cc_hmac_s hmac;
+ struct cc_xcbc_s xcbc;
+ } auth_state;
+ unsigned int enc_keylen;
+ unsigned int auth_keylen;
+ unsigned int authsize; /* Actual (reduced?) size of the MAC/ICv */
+ enum drv_cipher_mode cipher_mode;
+ enum cc_flow_mode flow_mode;
+ enum drv_hash_mode auth_mode;
+};
+
+static inline bool valid_assoclen(struct aead_request *req)
+{
+ return ((req->assoclen == 16) || (req->assoclen == 20));
+}
+
+static void cc_aead_exit(struct crypto_aead *tfm)
+{
+ struct cc_aead_ctx *ctx = crypto_aead_ctx(tfm);
+ struct device *dev = drvdata_to_dev(ctx->drvdata);
+
+ dev_dbg(dev, "Clearing context @%p for %s\n", crypto_aead_ctx(tfm),
+ crypto_tfm_alg_name(>base));
+
+ /* Unmap enckey buffer */
+ if (ctx->enckey) {
+ dma_free_coherent(dev, AES_MAX_KEY_SIZE, ctx->enckey,
+ ctx->enckey_dma_addr);
+ dev_dbg(dev, "Freed enckey DMA buffer enckey_dma_addr=%pad\n",
+ >enckey_dma_addr);
+ ctx->enckey_dma_addr = 0;
+ ctx->enckey = NULL;
+ }
+
+ if (ctx->auth_mode == DRV_HASH_XCBC_MAC) { /* XCBC authetication */
+ struct cc_xcbc_s *xcbc = >auth_state.xcbc;
+
+ if (xcbc->xcbc_keys) {
+ dma_free_coherent(dev, CC_AES_128_BIT_KEY_SIZE * 3,
+ xcbc->xcbc_keys,
+ xcbc->xcbc_keys_dma_addr);
+ }
+ dev_dbg(dev, "Freed xcbc_keys DMA buffer
xcbc_keys_dma_addr=%pad\n",
+ >xcbc_keys_dma_addr);
+ xcbc->xcbc_keys_dma_addr = 0;
+ xcbc->xcbc_keys = NULL;
+ } else if (ctx->auth_mode != DRV_HASH_NULL) { /* HMAC auth. */
+ struct cc_hmac_s *hmac = >auth_state.hmac;
+
+ if (hmac->ipad_opad) {
+ dma_free_coherent(dev, 2 * MAX_HMAC_DIGEST_SIZE,
+ hmac->ipad_opad
[PATCH v2 4/7] crypto: ccree: add ahash support
Add CryptoCell async. hash and HMAC support.
Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com>
---
drivers/crypto/ccree/Makefile|2 +-
drivers/crypto/ccree/cc_buffer_mgr.c | 261 +++-
drivers/crypto/ccree/cc_driver.c | 13 +
drivers/crypto/ccree/cc_driver.h |1 +
drivers/crypto/ccree/cc_hash.c | 2296 ++
drivers/crypto/ccree/cc_hash.h | 114 ++
drivers/crypto/ccree/cc_pm.c |4 +
7 files changed, 2688 insertions(+), 3 deletions(-)
create mode 100644 drivers/crypto/ccree/cc_hash.c
create mode 100644 drivers/crypto/ccree/cc_hash.h
diff --git a/drivers/crypto/ccree/Makefile b/drivers/crypto/ccree/Makefile
index a7fecad..1109480 100644
--- a/drivers/crypto/ccree/Makefile
+++ b/drivers/crypto/ccree/Makefile
@@ -1,6 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_CRYPTO_DEV_CCREE) := ccree.o
-ccree-y := cc_driver.o cc_buffer_mgr.o cc_request_mgr.o cc_cipher.o cc_ivgen.o
cc_sram_mgr.o
+ccree-y := cc_driver.o cc_buffer_mgr.o cc_request_mgr.o cc_cipher.o cc_hash.o
cc_ivgen.o cc_sram_mgr.o
ccree-$(CONFIG_DEBUG_FS) += cc_debugfs.o
ccree-$(CONFIG_PM) += cc_pm.o
diff --git a/drivers/crypto/ccree/cc_buffer_mgr.c
b/drivers/crypto/ccree/cc_buffer_mgr.c
index 46be101..bb306b4 100644
--- a/drivers/crypto/ccree/cc_buffer_mgr.c
+++ b/drivers/crypto/ccree/cc_buffer_mgr.c
@@ -9,6 +9,7 @@
#include "cc_buffer_mgr.h"
#include "cc_lli_defs.h"
#include "cc_cipher.h"
+#include "cc_hash.h"
enum dma_buffer_type {
DMA_NULL_TYPE = -1,
@@ -348,9 +349,33 @@ static int cc_map_sg(struct device *dev, struct
scatterlist *sg,
return 0;
}
+static int cc_set_hash_buf(struct device *dev, struct ahash_req_ctx *areq_ctx,
+ u8 *curr_buff, u32 curr_buff_cnt,
+ struct buffer_array *sg_data)
+{
+ dev_dbg(dev, " handle curr buff %x set to DLLI\n", curr_buff_cnt);
+ /* create sg for the current buffer */
+ sg_init_one(areq_ctx->buff_sg, curr_buff, curr_buff_cnt);
+ if (dma_map_sg(dev, areq_ctx->buff_sg, 1, DMA_TO_DEVICE) != 1) {
+ dev_err(dev, "dma_map_sg() src buffer failed\n");
+ return -ENOMEM;
+ }
+ dev_dbg(dev, "Mapped curr_buff: dma_address=%pad page=%p addr=%pK
offset=%u length=%u\n",
+ _dma_address(areq_ctx->buff_sg), sg_page(areq_ctx->buff_sg),
+ sg_virt(areq_ctx->buff_sg), areq_ctx->buff_sg->offset,
+ areq_ctx->buff_sg->length);
+ areq_ctx->data_dma_buf_type = CC_DMA_BUF_DLLI;
+ areq_ctx->curr_sg = areq_ctx->buff_sg;
+ areq_ctx->in_nents = 0;
+ /* prepare for case of MLLI */
+ cc_add_sg_entry(dev, sg_data, 1, areq_ctx->buff_sg, curr_buff_cnt, 0,
+ false, NULL);
+ return 0;
+}
+
void cc_unmap_cipher_request(struct device *dev, void *ctx,
-unsigned int ivsize, struct scatterlist *src,
-struct scatterlist *dst)
+ unsigned int ivsize, struct scatterlist *src,
+ struct scatterlist *dst)
{
struct cipher_req_ctx *req_ctx = (struct cipher_req_ctx *)ctx;
@@ -472,6 +497,238 @@ int cc_map_cipher_request(struct cc_drvdata *drvdata,
void *ctx,
return rc;
}
+int cc_map_hash_request_final(struct cc_drvdata *drvdata, void *ctx,
+ struct scatterlist *src, unsigned int nbytes,
+ bool do_update, gfp_t flags)
+{
+ struct ahash_req_ctx *areq_ctx = (struct ahash_req_ctx *)ctx;
+ struct device *dev = drvdata_to_dev(drvdata);
+ u8 *curr_buff = cc_hash_buf(areq_ctx);
+ u32 *curr_buff_cnt = cc_hash_buf_cnt(areq_ctx);
+ struct mlli_params *mlli_params = _ctx->mlli_params;
+ struct buffer_array sg_data;
+ struct buff_mgr_handle *buff_mgr = drvdata->buff_mgr_handle;
+ u32 dummy = 0;
+ u32 mapped_nents = 0;
+
+ dev_dbg(dev, "final params : curr_buff=%pK curr_buff_cnt=0x%X nbytes =
0x%X src=%pK curr_index=%u\n",
+ curr_buff, *curr_buff_cnt, nbytes, src, areq_ctx->buff_index);
+ /* Init the type of the dma buffer */
+ areq_ctx->data_dma_buf_type = CC_DMA_BUF_NULL;
+ mlli_params->curr_pool = NULL;
+ sg_data.num_of_buffers = 0;
+ areq_ctx->in_nents = 0;
+
+ if (nbytes == 0 && *curr_buff_cnt == 0) {
+ /* nothing to do */
+ return 0;
+ }
+
+ /*TODO: copy data in case that buffer is enough for operation */
+ /* map the previous buffer */
+ if (*curr_buff_cnt) {
+ if (cc_set_hash_buf(dev, areq_ctx, curr_buff, *curr_buff_cnt,
+ _data)) {
+
[PATCH v2 7/7] MAINTAINERS: update ccree entry
Update Arm TrustZone CryptoCell driver entry move into drivers/crypto/ Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com> --- MAINTAINERS | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 1082846..560e068 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3273,12 +3273,11 @@ F: drivers/net/ieee802154/cc2520.c F: include/linux/spi/cc2520.h F: Documentation/devicetree/bindings/net/ieee802154/cc2520.txt -CCREE ARM TRUSTZONE CRYPTOCELL 700 REE DRIVER +CCREE ARM TRUSTZONE CRYPTOCELL REE DRIVER M: Gilad Ben-Yossef <gi...@benyossef.com> L: linux-crypto@vger.kernel.org -L: driverdev-de...@linuxdriverproject.org S: Supported -F: drivers/staging/ccree/ +F: drivers/crypto/ccree/ W: https://developer.arm.com/products/system-ip/trustzone-cryptocell/cryptocell-700-family CEC FRAMEWORK -- 2.7.4
[PATCH v2 6/7] crypto: ccree: add FIPS support
Add FIPS mode support to CryptoCell driver
Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com>
---
drivers/crypto/ccree/Makefile| 1 +
drivers/crypto/ccree/cc_driver.c | 29 +-
drivers/crypto/ccree/cc_driver.h | 1 +
drivers/crypto/ccree/cc_fips.c | 111 +++
drivers/crypto/ccree/cc_fips.h | 37 +
5 files changed, 177 insertions(+), 2 deletions(-)
create mode 100644 drivers/crypto/ccree/cc_fips.c
create mode 100644 drivers/crypto/ccree/cc_fips.h
diff --git a/drivers/crypto/ccree/Makefile b/drivers/crypto/ccree/Makefile
index 7cb3082..bdc2797 100644
--- a/drivers/crypto/ccree/Makefile
+++ b/drivers/crypto/ccree/Makefile
@@ -2,5 +2,6 @@
obj-$(CONFIG_CRYPTO_DEV_CCREE) := ccree.o
ccree-y := cc_driver.o cc_buffer_mgr.o cc_request_mgr.o cc_cipher.o cc_hash.o
cc_aead.o cc_ivgen.o cc_sram_mgr.o
+ccree-$(CONFIG_CRYPTO_FIPS) += cc_fips.o
ccree-$(CONFIG_DEBUG_FS) += cc_debugfs.o
ccree-$(CONFIG_PM) += cc_pm.o
diff --git a/drivers/crypto/ccree/cc_driver.c b/drivers/crypto/ccree/cc_driver.c
index 8a530a4..827e329 100644
--- a/drivers/crypto/ccree/cc_driver.c
+++ b/drivers/crypto/ccree/cc_driver.c
@@ -25,6 +25,7 @@
#include "cc_ivgen.h"
#include "cc_sram_mgr.h"
#include "cc_pm.h"
+#include "cc_fips.h"
bool cc_dump_desc;
module_param_named(dump_desc, cc_dump_desc, bool, 0600);
@@ -78,7 +79,17 @@ static irqreturn_t cc_isr(int irq, void *dev_id)
irr &= ~CC_COMP_IRQ_MASK;
complete_request(drvdata);
}
-
+#ifdef CONFIG_CRYPTO_FIPS
+ /* TEE FIPS interrupt */
+ if (irr & CC_GPR0_IRQ_MASK) {
+ /* Mask interrupt - will be unmasked in Deferred service
+* handler
+*/
+ cc_iowrite(drvdata, CC_REG(HOST_IMR), imr | CC_GPR0_IRQ_MASK);
+ irr &= ~CC_GPR0_IRQ_MASK;
+ fips_handler(drvdata);
+ }
+#endif
/* AXI error interrupt */
if (irr & CC_AXI_ERR_IRQ_MASK) {
u32 axi_err;
@@ -243,10 +254,15 @@ static int init_cc_resources(struct platform_device
*plat_dev)
goto post_regs_err;
}
+ rc = cc_fips_init(new_drvdata);
+ if (rc) {
+ dev_err(dev, "CC_FIPS_INIT failed 0x%x\n", rc);
+ goto post_debugfs_err;
+ }
rc = cc_sram_mgr_init(new_drvdata);
if (rc) {
dev_err(dev, "cc_sram_mgr_init failed\n");
- goto post_debugfs_err;
+ goto post_fips_init_err;
}
new_drvdata->mlli_sram_addr =
@@ -301,6 +317,12 @@ static int init_cc_resources(struct platform_device
*plat_dev)
goto post_hash_err;
}
+ /* If we got here and FIPS mode is enabled
+* it means all FIPS test passed, so let TEE
+* know we're good.
+*/
+ cc_set_ree_fips_status(new_drvdata, true);
+
return 0;
post_hash_err:
@@ -317,6 +339,8 @@ static int init_cc_resources(struct platform_device
*plat_dev)
cc_req_mgr_fini(new_drvdata);
post_sram_mgr_err:
cc_sram_mgr_fini(new_drvdata);
+post_fips_init_err:
+ cc_fips_fini(new_drvdata);
post_debugfs_err:
cc_debugfs_fini(new_drvdata);
post_regs_err:
@@ -345,6 +369,7 @@ static void cleanup_cc_resources(struct platform_device
*plat_dev)
cc_buffer_mgr_fini(drvdata);
cc_req_mgr_fini(drvdata);
cc_sram_mgr_fini(drvdata);
+ cc_fips_fini(drvdata);
cc_debugfs_fini(drvdata);
fini_cc_regs(drvdata);
cc_clk_off(drvdata);
diff --git a/drivers/crypto/ccree/cc_driver.h b/drivers/crypto/ccree/cc_driver.h
index 0109c64..9cc488f 100644
--- a/drivers/crypto/ccree/cc_driver.h
+++ b/drivers/crypto/ccree/cc_driver.h
@@ -116,6 +116,7 @@ struct cc_drvdata {
void *hash_handle;
void *aead_handle;
void *request_mgr_handle;
+ void *fips_handle;
void *ivgen_handle;
void *sram_mgr_handle;
void *debugfs;
diff --git a/drivers/crypto/ccree/cc_fips.c b/drivers/crypto/ccree/cc_fips.c
new file mode 100644
index 000..de08af9
--- /dev/null
+++ b/drivers/crypto/ccree/cc_fips.c
@@ -0,0 +1,111 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (C) 2012-2018 ARM Limited or its affiliates. */
+
+#include
+#include
+
+#include "cc_driver.h"
+#include "cc_fips.h"
+
+static void fips_dsr(unsigned long devarg);
+
+struct cc_fips_handle {
+ struct tasklet_struct tasklet;
+};
+
+/* The function called once at driver entry point to check
+ * whether TEE FIPS error occurred.
+ */
+static bool cc_get_tee_fips_status(struct cc_drvdata *drvdata)
+{
+ u32 reg;
+
+ reg = cc_ioread(drvdata, CC_REG(GPR_HOST));
+ return (reg == (CC_FIPS_SYNC_TEE_STATUS | CC_FIPS_SYNC_MODULE_OK));
+}
+
+/*
+ * This function should push the FIPS REE library status towards the TE
Re: [PATCH][next] staging: ccree: fix memory leaks in cc_ivgen_init
On Fri, Jan 12, 2018 at 6:10 PM, Colin King <colin.k...@canonical.com> wrote:
> From: Colin Ian King <colin.k...@canonical.com>
>
> The current error exit path in function cc_ivgen_init via label
> 'out' free's resources from the drvdata->ivgen_handle context.
> However, drvdata->ivgen_handle has not been assigned to the
> context ivgen_ctx at this point, so the resources are not freed.
> Fix this by setting drvdata->ivgen_handle to ivgen_ctx as early
> as possible so that the clean up error exit return path can free
> the resources.
>
> Detected by CoveritScan, CID#1463795 ("Resource leak")
>
> Signed-off-by: Colin Ian King <colin.k...@canonical.com>
> ---
> drivers/staging/ccree/cc_ivgen.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/ccree/cc_ivgen.c
> b/drivers/staging/ccree/cc_ivgen.c
> index 25a3131a93ce..c47f419b277b 100644
> --- a/drivers/staging/ccree/cc_ivgen.c
> +++ b/drivers/staging/ccree/cc_ivgen.c
> @@ -178,6 +178,8 @@ int cc_ivgen_init(struct cc_drvdata *drvdata)
> if (!ivgen_ctx)
> return -ENOMEM;
>
> + drvdata->ivgen_handle = ivgen_ctx;
> +
> /* Allocate pool's header for initial enc. key/IV */
> ivgen_ctx->pool_meta = dma_alloc_coherent(device, CC_IVPOOL_META_SIZE,
> _ctx->pool_meta_dma,
> @@ -196,8 +198,6 @@ int cc_ivgen_init(struct cc_drvdata *drvdata)
> goto out;
> }
>
> - drvdata->ivgen_handle = ivgen_ctx;
> -
> return cc_init_iv_sram(drvdata);
>
> out:
> --
> 2.15.1
>
Good catch!
Acked-by: Gilad Ben-Yossef <gi...@benyossef.com>
Thanks,
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
-- Jean-Baptiste Queru
Re: [PATCH 3/7] crypto: ccree: add ablkcipher support
Hi Corentin,
On Thu, Jan 11, 2018 at 12:01 PM, Corentin Labbe
<clabbe.montj...@gmail.com> wrote:
> On Thu, Jan 11, 2018 at 09:17:10AM +0000, Gilad Ben-Yossef wrote:
>> Add CryptoCell ablkcipher support
>>
>
> Hello
>
> I have some minor comments:
>
> ablkcipher is deprecated, so you need to use skcipher instead.
Fixed in v2.
>
>> Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com>
>> ---
>> drivers/crypto/ccree/Makefile|2 +-
>> drivers/crypto/ccree/cc_buffer_mgr.c | 125
>> drivers/crypto/ccree/cc_buffer_mgr.h | 10 +
>> drivers/crypto/ccree/cc_cipher.c | 1167
>> ++
>> drivers/crypto/ccree/cc_cipher.h | 74 +++
>> drivers/crypto/ccree/cc_driver.c | 11 +
>> drivers/crypto/ccree/cc_driver.h |2 +
>> 7 files changed, 1390 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/crypto/ccree/cc_cipher.c
>> create mode 100644 drivers/crypto/ccree/cc_cipher.h
>>
> [...]
>> +
>> +struct tdes_keys {
>> + u8 key1[DES_KEY_SIZE];
>> + u8 key2[DES_KEY_SIZE];
>> + u8 key3[DES_KEY_SIZE];
>> +};
>> +
>> +static const u8 zero_buff[] = { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
>> + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
>> + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
>> + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0};
>> +
>
> This constant is used nowhere.
Fixed in v2.
>
>> +/* The function verifies that tdes keys are not weak.*/
>> +static int cc_verify_3des_keys(const u8 *key, unsigned int keylen)
>> +{
>> + struct tdes_keys *tdes_key = (struct tdes_keys *)key;
>> +
>> + /* verify key1 != key2 and key3 != key2*/
>> + if ((memcmp((u8 *)tdes_key->key1, (u8 *)tdes_key->key2,
>> + sizeof(tdes_key->key1)) == 0) ||
>> + (memcmp((u8 *)tdes_key->key3, (u8 *)tdes_key->key2,
>> + sizeof(tdes_key->key3)) == 0)) {
>> + return -ENOEXEC;
>> + }
>> +
>> + return 0;
>> +}
>
> All driver testing 3des key also use des_ekey()
Well, the weak key test which is part of des_ekey() are not needed
AFAIK for 3des
as per RFC2451 and the HW does 3des key expansion so that function is not useful
here.
>
> [...]
>> +static void cc_cipher_complete(struct device *dev, void *cc_req, int err)
>> +{
>> + struct ablkcipher_request *areq = (struct ablkcipher_request *)cc_req;
>> + struct scatterlist *dst = areq->dst;
>> + struct scatterlist *src = areq->src;
>> + struct blkcipher_req_ctx *req_ctx = ablkcipher_request_ctx(areq);
>> + struct crypto_ablkcipher *tfm = crypto_ablkcipher_reqtfm(areq);
>> + unsigned int ivsize = crypto_ablkcipher_ivsize(tfm);
>> + struct ablkcipher_request *req = (struct ablkcipher_request *)areq;
>> +
>> + cc_unmap_blkcipher_request(dev, req_ctx, ivsize, src, dst);
>> + kfree(req_ctx->iv);
>
> kzfree for all stuff with IV/key
Fixed in v2.
>
> [...]
>> +
>> +#ifdef CRYPTO_TFM_REQ_HW_KEY
>> +
>> +static inline bool cc_is_hw_key(struct crypto_tfm *tfm)
>> +{
>> + return (crypto_tfm_get_flags(tfm) & CRYPTO_TFM_REQ_HW_KEY);
>> +}
>> +
>> +#else
>> +
>> +struct arm_hw_key_info {
>> + int hw_key1;
>> + int hw_key2;
>> +};
>> +
>> +static inline bool cc_is_hw_key(struct crypto_tfm *tfm)
>> +{
>> + return false;
>> +}
>> +
>> +#endif /* CRYPTO_TFM_REQ_HW_KEY */
>
> I see nowhere any use/documentation of CRYPTO_TFM_REQ_HW_KEY, so a cleaning
> could be done
You are right. It's a badly implemented stub function. I'll drop the
ifdef as it is useless right now.
Many thanks for the review!
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
-- Jean-Baptiste Queru
Re: [PATCH 3/7] crypto: ccree: add ablkcipher support
On Thu, Jan 11, 2018 at 12:03 PM, Stephan Mueller <smuel...@chronox.de> wrote:
> Am Donnerstag, 11. Januar 2018, 10:17:10 CET schrieb Gilad Ben-Yossef:
>
> Hi Gilad,
>
>> + // verify weak keys
>> + if (ctx_p->flow_mode == S_DIN_to_DES) {
>> + if (!des_ekey(tmp, key) &&
>> + (crypto_tfm_get_flags(tfm) & CRYPTO_TFM_REQ_WEAK_KEY)) {
>> + tfm->crt_flags |= CRYPTO_TFM_RES_WEAK_KEY;
>> + dev_dbg(dev, "weak DES key");
>> + return -EINVAL;
>> + }
>> + }
>> + if (ctx_p->cipher_mode == DRV_CIPHER_XTS &&
>> + xts_check_key(tfm, key, keylen)) {
>> + dev_dbg(dev, "weak XTS key");
>> + return -EINVAL;
>> + }
>> + if (ctx_p->flow_mode == S_DIN_to_DES &&
>> + keylen == DES3_EDE_KEY_SIZE &&
>> + cc_verify_3des_keys(key, keylen)) {
>> + dev_dbg(dev, "weak 3DES key");
>> + return -EINVAL;
>> + }
>
> For the DES key, wouldn't it make sense to use __des3_ede_setkey?
>
> Note, I would plan to release a patch for review to change that function to
> disallow key1 == key2 or key1 == key3 or key2 == key3 in FIPS mode.
I took your advise and did just that in v2.
Thanks for the review!
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
-- Jean-Baptiste Queru
Re: Getting the ccree driver out of staging
On Thu, Jan 11, 2018 at 10:42 AM, Dan Carpenter
<dan.carpen...@oracle.com> wrote:
> Here are my remaining Smatch warnings:
>
> drivers/staging/ccree/cc_driver.c:219 init_cc_resources()
> error: '%pa' can only be followed by one of [dp]
>
> drivers/staging/ccree/cc_driver.c
>217
>218 if (rc) {
>219 dev_err(dev, "Failed in dma_set_mask, mask=%par\n",
> ^
> This 'r' is is treated as a 'p'. Not sure what was intended.
>
>220 _mask);
>221 return rc;
>222 }
>223
>
>
> drivers/staging/ccree/cc_buffer_mgr.c:1067 cc_aead_chain_data()
> warn: inconsistent indenting
>
> drivers/staging/ccree/cc_buffer_mgr.c
> 1064 if (src_mapped_nents > LLI_MAX_NUM_OF_DATA_ENTRIES) {
> 1065 dev_err(dev, "Too many fragments. current %d max
> %d\n",
> 1066 src_mapped_nents,
> LLI_MAX_NUM_OF_DATA_ENTRIES);
> 1067 return -ENOMEM;
> ^^
> 1068 }
>
> drivers/staging/ccree/cc_cipher.c:373 cc_cipher_setkey()
> warn: inconsistent indenting
>
> drivers/staging/ccree/cc_cipher.c
>369 dma_sync_single_for_device(dev, ctx_p->user.key_dma_addr,
>370 max_key_buf_size, DMA_TO_DEVICE);
>371 ctx_p->keylen = keylen;
>372
>373 dev_dbg(dev, "return safely");
> ^
> One extra space.
>
>374 return 0;
>375 }
>
Will fix in v2.
Thanks!
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
-- Jean-Baptiste Queru
Re: [RFT PATCH] crypto: arm64 - implement SM3 secure hash using special instructions
On Tue, Jan 16, 2018 at 10:29 AM, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: > Implement the Chinese SM3 secure hash algorithm using the new > special instructions that have been introduced as an optional > extension in ARMv8.2. > > Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> > --- Looks good to me. Reviewed-by: Gilad Ben-Yossef <gi...@benyossef.com> -- Gilad Ben-Yossef Chief Coffee Drinker "If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru
Re: [PATCH -next] staging: ccree: remove redundant dev_err call in init_cc_resources()
On Thu, Jan 11, 2018 at 1:14 PM, Wei Yongjun <weiyongj...@huawei.com> wrote:
> There is a error message within devm_ioremap_resource
> already, so remove the dev_err call to avoid redundant
> error message.
>
> Signed-off-by: Wei Yongjun <weiyongj...@huawei.com>
> ---
> drivers/staging/ccree/cc_driver.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/staging/ccree/cc_driver.c
> b/drivers/staging/ccree/cc_driver.c
> index 6682d9d..c27d5a8 100644
> --- a/drivers/staging/ccree/cc_driver.c
> +++ b/drivers/staging/ccree/cc_driver.c
> @@ -174,10 +174,8 @@ static int init_cc_resources(struct platform_device
> *plat_dev)
> req_mem_cc_regs = platform_get_resource(plat_dev, IORESOURCE_MEM, 0);
> /* Map registers space */
> new_drvdata->cc_base = devm_ioremap_resource(dev, req_mem_cc_regs);
> - if (IS_ERR(new_drvdata->cc_base)) {
> - dev_err(dev, "Failed to ioremap registers");
> + if (IS_ERR(new_drvdata->cc_base))
> return PTR_ERR(new_drvdata->cc_base);
> - }
>
> dev_dbg(dev, "Got MEM resource (%s): %pR\n", req_mem_cc_regs->name,
> req_mem_cc_regs);
>
Yeah, that makes sense.
Acked-by: Gilad Ben-Yossef <gi...@benyossef.com>
Thanks,
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
-- Jean-Baptiste Queru
Re: [PATCH 1/7] staging: ccree: remove ccree from staging tree
On Sat, Jan 13, 2018 at 3:21 PM, Greg Kroah-Hartman <gre...@linuxfoundation.org> wrote: > On Thu, Jan 11, 2018 at 09:17:08AM +0000, Gilad Ben-Yossef wrote: >> Remove the ccree driver from the staging tree in preparation to >> introducing it in the crypto tree. >> >> Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com> > > Heh, no, just make a patch series that adds the driver to the correct > location in the crypto tree. > > If that gets accepted, we can then delete the staging driver with a > separate patch, after the fact. No need for it to be in this patch > series. Yes, I should have been more communicative as to why I am doing this, sorry. The problem is that if you apply the patch adding the driver to drivers/crypto/ the kernel no longer links due to symbol name collisions. If we really must avoid doing an "atomic" replacement I guess I can change the Kconfig name to ...CCREE_OLD or something although I would prefer not doing that so that people using the driver in staging/ don't need to change their kernel build configs when they are upgrading versions. Does that makes sense? Thanks, Gilad -- Gilad Ben-Yossef Chief Coffee Drinker "If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru
[PATCH 1/7] staging: ccree: remove ccree from staging tree
Remove the ccree driver from the staging tree in preparation to introducing it in the crypto tree. Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com> --- drivers/staging/Kconfig|2 - drivers/staging/Makefile |1 - .../devicetree/bindings/crypto/arm-cryptocell.txt | 27 - drivers/staging/ccree/Kconfig | 25 - drivers/staging/ccree/Makefile |3 - drivers/staging/ccree/TODO | 30 - drivers/staging/ccree/cc_crypto_ctx.h | 200 -- drivers/staging/ccree/cc_hw_queue_defs.h | 594 - drivers/staging/ccree/cc_lli_defs.h| 72 - drivers/staging/ccree/dx_crys_kernel.h | 180 -- drivers/staging/ccree/dx_host.h| 155 -- drivers/staging/ccree/dx_reg_common.h | 26 - drivers/staging/ccree/hash_defs.h | 36 - drivers/staging/ccree/ssi_aead.c | 2794 drivers/staging/ccree/ssi_aead.h | 117 - drivers/staging/ccree/ssi_buffer_mgr.c | 1776 - drivers/staging/ccree/ssi_buffer_mgr.h | 91 - drivers/staging/ccree/ssi_cipher.c | 1357 -- drivers/staging/ccree/ssi_cipher.h | 84 - drivers/staging/ccree/ssi_config.h | 36 - drivers/staging/ccree/ssi_driver.c | 538 drivers/staging/ccree/ssi_driver.h | 206 -- drivers/staging/ccree/ssi_fips.c | 126 - drivers/staging/ccree/ssi_fips.h | 49 - drivers/staging/ccree/ssi_hash.c | 2549 -- drivers/staging/ccree/ssi_hash.h | 103 - drivers/staging/ccree/ssi_ivgen.c | 299 --- drivers/staging/ccree/ssi_ivgen.h | 71 - drivers/staging/ccree/ssi_pm.c | 145 - drivers/staging/ccree/ssi_pm.h | 43 - drivers/staging/ccree/ssi_request_mgr.c| 610 - drivers/staging/ccree/ssi_request_mgr.h| 60 - drivers/staging/ccree/ssi_sram_mgr.c | 123 - drivers/staging/ccree/ssi_sram_mgr.h | 79 - drivers/staging/ccree/ssi_sysfs.c | 172 -- drivers/staging/ccree/ssi_sysfs.h | 55 - 36 files changed, 12834 deletions(-) delete mode 100644 drivers/staging/ccree/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt delete mode 100644 drivers/staging/ccree/Kconfig delete mode 100644 drivers/staging/ccree/Makefile delete mode 100644 drivers/staging/ccree/TODO delete mode 100644 drivers/staging/ccree/cc_crypto_ctx.h delete mode 100644 drivers/staging/ccree/cc_hw_queue_defs.h delete mode 100644 drivers/staging/ccree/cc_lli_defs.h delete mode 100644 drivers/staging/ccree/dx_crys_kernel.h delete mode 100644 drivers/staging/ccree/dx_host.h delete mode 100644 drivers/staging/ccree/dx_reg_common.h delete mode 100644 drivers/staging/ccree/hash_defs.h delete mode 100644 drivers/staging/ccree/ssi_aead.c delete mode 100644 drivers/staging/ccree/ssi_aead.h delete mode 100644 drivers/staging/ccree/ssi_buffer_mgr.c delete mode 100644 drivers/staging/ccree/ssi_buffer_mgr.h delete mode 100644 drivers/staging/ccree/ssi_cipher.c delete mode 100644 drivers/staging/ccree/ssi_cipher.h delete mode 100644 drivers/staging/ccree/ssi_config.h delete mode 100644 drivers/staging/ccree/ssi_driver.c delete mode 100644 drivers/staging/ccree/ssi_driver.h delete mode 100644 drivers/staging/ccree/ssi_fips.c delete mode 100644 drivers/staging/ccree/ssi_fips.h delete mode 100644 drivers/staging/ccree/ssi_hash.c delete mode 100644 drivers/staging/ccree/ssi_hash.h delete mode 100644 drivers/staging/ccree/ssi_ivgen.c delete mode 100644 drivers/staging/ccree/ssi_ivgen.h delete mode 100644 drivers/staging/ccree/ssi_pm.c delete mode 100644 drivers/staging/ccree/ssi_pm.h delete mode 100644 drivers/staging/ccree/ssi_request_mgr.c delete mode 100644 drivers/staging/ccree/ssi_request_mgr.h delete mode 100644 drivers/staging/ccree/ssi_sram_mgr.c delete mode 100644 drivers/staging/ccree/ssi_sram_mgr.h delete mode 100644 drivers/staging/ccree/ssi_sysfs.c delete mode 100644 drivers/staging/ccree/ssi_sysfs.h diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig index 5546839..72946bf 100644 --- a/drivers/staging/Kconfig +++ b/drivers/staging/Kconfig @@ -110,8 +110,6 @@ source "drivers/staging/greybus/Kconfig" source "drivers/staging/vc04_services/Kconfig" -source "drivers/staging/ccree/Kconfig" - source "drivers/staging/typec/Kconfig" source "drivers/staging/vboxvideo/Kconfig" diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile index 6e53602..7612bee 100644 --- a/drivers/staging/Makefile +++ b/drivers/staging/Makefile @@ -4
[PATCH 3/7] crypto: ccree: add ablkcipher support
Add CryptoCell ablkcipher support
Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com>
---
drivers/crypto/ccree/Makefile|2 +-
drivers/crypto/ccree/cc_buffer_mgr.c | 125
drivers/crypto/ccree/cc_buffer_mgr.h | 10 +
drivers/crypto/ccree/cc_cipher.c | 1167 ++
drivers/crypto/ccree/cc_cipher.h | 74 +++
drivers/crypto/ccree/cc_driver.c | 11 +
drivers/crypto/ccree/cc_driver.h |2 +
7 files changed, 1390 insertions(+), 1 deletion(-)
create mode 100644 drivers/crypto/ccree/cc_cipher.c
create mode 100644 drivers/crypto/ccree/cc_cipher.h
diff --git a/drivers/crypto/ccree/Makefile b/drivers/crypto/ccree/Makefile
index 6b204ab..a7fecad 100644
--- a/drivers/crypto/ccree/Makefile
+++ b/drivers/crypto/ccree/Makefile
@@ -1,6 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_CRYPTO_DEV_CCREE) := ccree.o
-ccree-y := cc_driver.o cc_buffer_mgr.o cc_request_mgr.o cc_ivgen.o
cc_sram_mgr.o
+ccree-y := cc_driver.o cc_buffer_mgr.o cc_request_mgr.o cc_cipher.o cc_ivgen.o
cc_sram_mgr.o
ccree-$(CONFIG_DEBUG_FS) += cc_debugfs.o
ccree-$(CONFIG_PM) += cc_pm.o
diff --git a/drivers/crypto/ccree/cc_buffer_mgr.c
b/drivers/crypto/ccree/cc_buffer_mgr.c
index 4c67579..510993e 100644
--- a/drivers/crypto/ccree/cc_buffer_mgr.c
+++ b/drivers/crypto/ccree/cc_buffer_mgr.c
@@ -8,6 +8,7 @@
#include "cc_buffer_mgr.h"
#include "cc_lli_defs.h"
+#include "cc_cipher.h"
enum dma_buffer_type {
DMA_NULL_TYPE = -1,
@@ -347,6 +348,130 @@ static int cc_map_sg(struct device *dev, struct
scatterlist *sg,
return 0;
}
+void cc_unmap_blkcipher_request(struct device *dev, void *ctx,
+ unsigned int ivsize, struct scatterlist *src,
+ struct scatterlist *dst)
+{
+ struct blkcipher_req_ctx *req_ctx = (struct blkcipher_req_ctx *)ctx;
+
+ if (req_ctx->gen_ctx.iv_dma_addr) {
+ dev_dbg(dev, "Unmapped iv: iv_dma_addr=%pad iv_size=%u\n",
+ _ctx->gen_ctx.iv_dma_addr, ivsize);
+ dma_unmap_single(dev, req_ctx->gen_ctx.iv_dma_addr,
+ivsize,
+req_ctx->is_giv ? DMA_BIDIRECTIONAL :
+DMA_TO_DEVICE);
+ }
+ /* Release pool */
+ if (req_ctx->dma_buf_type == CC_DMA_BUF_MLLI &&
+ req_ctx->mlli_params.mlli_virt_addr) {
+ dma_pool_free(req_ctx->mlli_params.curr_pool,
+ req_ctx->mlli_params.mlli_virt_addr,
+ req_ctx->mlli_params.mlli_dma_addr);
+ }
+
+ dma_unmap_sg(dev, src, req_ctx->in_nents, DMA_BIDIRECTIONAL);
+ dev_dbg(dev, "Unmapped req->src=%pK\n", sg_virt(src));
+
+ if (src != dst) {
+ dma_unmap_sg(dev, dst, req_ctx->out_nents, DMA_BIDIRECTIONAL);
+ dev_dbg(dev, "Unmapped req->dst=%pK\n", sg_virt(dst));
+ }
+}
+
+int cc_map_blkcipher_request(struct cc_drvdata *drvdata, void *ctx,
+unsigned int ivsize, unsigned int nbytes,
+void *info, struct scatterlist *src,
+struct scatterlist *dst, gfp_t flags)
+{
+ struct blkcipher_req_ctx *req_ctx = (struct blkcipher_req_ctx *)ctx;
+ struct mlli_params *mlli_params = _ctx->mlli_params;
+ struct buff_mgr_handle *buff_mgr = drvdata->buff_mgr_handle;
+ struct device *dev = drvdata_to_dev(drvdata);
+ struct buffer_array sg_data;
+ u32 dummy = 0;
+ int rc = 0;
+ u32 mapped_nents = 0;
+
+ req_ctx->dma_buf_type = CC_DMA_BUF_DLLI;
+ mlli_params->curr_pool = NULL;
+ sg_data.num_of_buffers = 0;
+
+ /* Map IV buffer */
+ if (ivsize) {
+ dump_byte_array("iv", (u8 *)info, ivsize);
+ req_ctx->gen_ctx.iv_dma_addr =
+ dma_map_single(dev, (void *)info,
+ ivsize,
+ req_ctx->is_giv ? DMA_BIDIRECTIONAL :
+ DMA_TO_DEVICE);
+ if (dma_mapping_error(dev, req_ctx->gen_ctx.iv_dma_addr)) {
+ dev_err(dev, "Mapping iv %u B at va=%pK for DMA
failed\n",
+ ivsize, info);
+ return -ENOMEM;
+ }
+ dev_dbg(dev, "Mapped iv %u B at va=%pK to dma=%pad\n",
+ ivsize, info, _ctx->gen_ctx.iv_dma_addr);
+ } else {
+ req_ctx->gen_ctx.iv_dma_addr = 0;
+ }
+
+ /* Map the src SGL */
+ rc = cc_map_sg(dev, src, nbytes, DMA_BIDIRECTIONAL, _ctx->in_nents,
+ LLI_MAX_NUM_OF_DATA_ENTRIES, , _nents);
+ if (rc) {
+
[PATCH 2/7] crypto: ccree: introduce CryptoCell driver
Introduce basic low level Arm TrustZone CryptoCell HW support. This first patch doesn't actually register any Crypto API transformations, these will follow up in the next patch. This first revision supports the CC 712 REE component. Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com> --- drivers/crypto/Kconfig | 27 ++ drivers/crypto/Makefile | 1 + drivers/crypto/ccree/Makefile | 6 + drivers/crypto/ccree/cc_buffer_mgr.c| 387 + drivers/crypto/ccree/cc_buffer_mgr.h| 60 +++ drivers/crypto/ccree/cc_crypto_ctx.h| 170 drivers/crypto/ccree/cc_debugfs.c | 101 + drivers/crypto/ccree/cc_debugfs.h | 32 ++ drivers/crypto/ccree/cc_driver.c| 418 +++ drivers/crypto/ccree/cc_driver.h| 186 + drivers/crypto/ccree/cc_host_regs.h | 142 +++ drivers/crypto/ccree/cc_hw_queue_defs.h | 590 ++ drivers/crypto/ccree/cc_ivgen.c | 280 + drivers/crypto/ccree/cc_ivgen.h | 55 +++ drivers/crypto/ccree/cc_kernel_regs.h | 167 drivers/crypto/ccree/cc_lli_defs.h | 59 +++ drivers/crypto/ccree/cc_pm.c| 119 ++ drivers/crypto/ccree/cc_pm.h| 57 +++ drivers/crypto/ccree/cc_request_mgr.c | 714 drivers/crypto/ccree/cc_request_mgr.h | 51 +++ drivers/crypto/ccree/cc_sram_mgr.c | 107 + drivers/crypto/ccree/cc_sram_mgr.h | 65 +++ 22 files changed, 3794 insertions(+) create mode 100644 drivers/crypto/ccree/Makefile create mode 100644 drivers/crypto/ccree/cc_buffer_mgr.c create mode 100644 drivers/crypto/ccree/cc_buffer_mgr.h create mode 100644 drivers/crypto/ccree/cc_crypto_ctx.h create mode 100644 drivers/crypto/ccree/cc_debugfs.c create mode 100644 drivers/crypto/ccree/cc_debugfs.h create mode 100644 drivers/crypto/ccree/cc_driver.c create mode 100644 drivers/crypto/ccree/cc_driver.h create mode 100644 drivers/crypto/ccree/cc_host_regs.h create mode 100644 drivers/crypto/ccree/cc_hw_queue_defs.h create mode 100644 drivers/crypto/ccree/cc_ivgen.c create mode 100644 drivers/crypto/ccree/cc_ivgen.h create mode 100644 drivers/crypto/ccree/cc_kernel_regs.h create mode 100644 drivers/crypto/ccree/cc_lli_defs.h create mode 100644 drivers/crypto/ccree/cc_pm.c create mode 100644 drivers/crypto/ccree/cc_pm.h create mode 100644 drivers/crypto/ccree/cc_request_mgr.c create mode 100644 drivers/crypto/ccree/cc_request_mgr.h create mode 100644 drivers/crypto/ccree/cc_sram_mgr.c create mode 100644 drivers/crypto/ccree/cc_sram_mgr.h diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig index 47ec920..ed912bf 100644 --- a/drivers/crypto/Kconfig +++ b/drivers/crypto/Kconfig @@ -731,4 +731,31 @@ config CRYPTO_DEV_ARTPEC6 To compile this driver as a module, choose M here. +config CRYPTO_DEV_CCREE + tristate "Support for ARM TrustZone CryptoCell family of security processors" + depends on CRYPTO && CRYPTO_HW && OF && HAS_DMA + default n + select CRYPTO_HASH + select CRYPTO_BLKCIPHER + select CRYPTO_DES + select CRYPTO_AEAD + select CRYPTO_AUTHENC + select CRYPTO_SHA1 + select CRYPTO_MD5 + select CRYPTO_SHA256 + select CRYPTO_SHA512 + select CRYPTO_HMAC + select CRYPTO_AES + select CRYPTO_CBC + select CRYPTO_ECB + select CRYPTO_CTR + select CRYPTO_XTS + help + Say 'Y' to enable a driver for the Arm TrustZone CryptoCell + family of processors. Currently only the CryptoCell 712 REE + is supported. + Choose this if you wish to use hardware acceleration of + cryptographic operations on the system REE. + If unsure say Y. + endif # CRYPTO_HW diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile index 2513d13..ee5ec5c9 100644 --- a/drivers/crypto/Makefile +++ b/drivers/crypto/Makefile @@ -6,6 +6,7 @@ obj-$(CONFIG_CRYPTO_DEV_ATMEL_ECC) += atmel-ecc.o obj-$(CONFIG_CRYPTO_DEV_BFIN_CRC) += bfin_crc.o obj-$(CONFIG_CRYPTO_DEV_CAVIUM_ZIP) += cavium/ obj-$(CONFIG_CRYPTO_DEV_CCP) += ccp/ +obj-$(CONFIG_CRYPTO_DEV_CCREE) += ccree/ obj-$(CONFIG_CRYPTO_DEV_CHELSIO) += chelsio/ obj-$(CONFIG_CRYPTO_DEV_CPT) += cavium/cpt/ obj-$(CONFIG_CRYPTO_DEV_NITROX) += cavium/nitrox/ diff --git a/drivers/crypto/ccree/Makefile b/drivers/crypto/ccree/Makefile new file mode 100644 index 000..6b204ab --- /dev/null +++ b/drivers/crypto/ccree/Makefile @@ -0,0 +1,6 @@ +# SPDX-License-Identifier: GPL-2.0 + +obj-$(CONFIG_CRYPTO_DEV_CCREE) := ccree.o +ccree-y := cc_driver.o cc_buffer_mgr.o cc_request_mgr.o cc_ivgen.o cc_sram_mgr.o +ccree-$(CONFIG_DEBUG_FS) += cc_debugfs.o +ccree-$(CONFIG_PM) += cc_pm.o diff --git a/drivers/crypto/ccree/cc_buffer_mgr.c b/drivers/crypto/ccree/cc_buffer_mgr.c new file mode 100644 index 000..4c67579
[PATCH 6/7] crypto: ccree: add FIPS support
Add FIPS mode support to CryptoCell driver
Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com>
---
drivers/crypto/ccree/Makefile| 1 +
drivers/crypto/ccree/cc_driver.c | 29 +-
drivers/crypto/ccree/cc_driver.h | 1 +
drivers/crypto/ccree/cc_fips.c | 112 +++
drivers/crypto/ccree/cc_fips.h | 37 +
5 files changed, 178 insertions(+), 2 deletions(-)
create mode 100644 drivers/crypto/ccree/cc_fips.c
create mode 100644 drivers/crypto/ccree/cc_fips.h
diff --git a/drivers/crypto/ccree/Makefile b/drivers/crypto/ccree/Makefile
index 7cb3082..bdc2797 100644
--- a/drivers/crypto/ccree/Makefile
+++ b/drivers/crypto/ccree/Makefile
@@ -2,5 +2,6 @@
obj-$(CONFIG_CRYPTO_DEV_CCREE) := ccree.o
ccree-y := cc_driver.o cc_buffer_mgr.o cc_request_mgr.o cc_cipher.o cc_hash.o
cc_aead.o cc_ivgen.o cc_sram_mgr.o
+ccree-$(CONFIG_CRYPTO_FIPS) += cc_fips.o
ccree-$(CONFIG_DEBUG_FS) += cc_debugfs.o
ccree-$(CONFIG_PM) += cc_pm.o
diff --git a/drivers/crypto/ccree/cc_driver.c b/drivers/crypto/ccree/cc_driver.c
index 31140e3..b71dc70 100644
--- a/drivers/crypto/ccree/cc_driver.c
+++ b/drivers/crypto/ccree/cc_driver.c
@@ -25,6 +25,7 @@
#include "cc_ivgen.h"
#include "cc_sram_mgr.h"
#include "cc_pm.h"
+#include "cc_fips.h"
bool cc_dump_desc;
module_param_named(dump_desc, cc_dump_desc, bool, 0600);
@@ -78,7 +79,17 @@ static irqreturn_t cc_isr(int irq, void *dev_id)
irr &= ~CC_COMP_IRQ_MASK;
complete_request(drvdata);
}
-
+#ifdef CONFIG_CRYPTO_FIPS
+ /* TEE FIPS interrupt */
+ if (irr & CC_GPR0_IRQ_MASK) {
+ /* Mask interrupt - will be unmasked in Deferred service
+* handler
+*/
+ cc_iowrite(drvdata, CC_REG(HOST_IMR), imr | CC_GPR0_IRQ_MASK);
+ irr &= ~CC_GPR0_IRQ_MASK;
+ fips_handler(drvdata);
+ }
+#endif
/* AXI error interrupt */
if (irr & CC_AXI_ERR_IRQ_MASK) {
u32 axi_err;
@@ -244,10 +255,15 @@ static int init_cc_resources(struct platform_device
*plat_dev)
goto post_regs_err;
}
+ rc = cc_fips_init(new_drvdata);
+ if (rc) {
+ dev_err(dev, "CC_FIPS_INIT failed 0x%x\n", rc);
+ goto post_debugfs_err;
+ }
rc = cc_sram_mgr_init(new_drvdata);
if (rc) {
dev_err(dev, "cc_sram_mgr_init failed\n");
- goto post_debugfs_err;
+ goto post_fips_init_err;
}
new_drvdata->mlli_sram_addr =
@@ -302,6 +318,12 @@ static int init_cc_resources(struct platform_device
*plat_dev)
goto post_hash_err;
}
+ /* If we got here and FIPS mode is enabled
+* it means all FIPS test passed, so let TEE
+* know we're good.
+*/
+ cc_set_ree_fips_status(new_drvdata, true);
+
return 0;
post_hash_err:
@@ -318,6 +340,8 @@ static int init_cc_resources(struct platform_device
*plat_dev)
cc_req_mgr_fini(new_drvdata);
post_sram_mgr_err:
cc_sram_mgr_fini(new_drvdata);
+post_fips_init_err:
+ cc_fips_fini(new_drvdata);
post_debugfs_err:
cc_debugfs_fini(new_drvdata);
post_regs_err:
@@ -346,6 +370,7 @@ static void cleanup_cc_resources(struct platform_device
*plat_dev)
cc_buffer_mgr_fini(drvdata);
cc_req_mgr_fini(drvdata);
cc_sram_mgr_fini(drvdata);
+ cc_fips_fini(drvdata);
cc_debugfs_fini(drvdata);
fini_cc_regs(drvdata);
cc_clk_off(drvdata);
diff --git a/drivers/crypto/ccree/cc_driver.h b/drivers/crypto/ccree/cc_driver.h
index ab9a66f..12699f1 100644
--- a/drivers/crypto/ccree/cc_driver.h
+++ b/drivers/crypto/ccree/cc_driver.h
@@ -115,6 +115,7 @@ struct cc_drvdata {
void *aead_handle;
void *blkcipher_handle;
void *request_mgr_handle;
+ void *fips_handle;
void *ivgen_handle;
void *sram_mgr_handle;
void *debugfs;
diff --git a/drivers/crypto/ccree/cc_fips.c b/drivers/crypto/ccree/cc_fips.c
new file mode 100644
index 000..b25c34e
--- /dev/null
+++ b/drivers/crypto/ccree/cc_fips.c
@@ -0,0 +1,112 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (C) 2012-2018 ARM Limited or its affiliates. */
+
+#include
+#include
+
+#include "cc_driver.h"
+#include "cc_fips.h"
+
+static void fips_dsr(unsigned long devarg);
+
+struct cc_fips_handle {
+ struct tasklet_struct tasklet;
+};
+
+/* The function called once at driver entry point to check
+ * whether TEE FIPS error occurred.
+ */
+static bool cc_get_tee_fips_status(struct cc_drvdata *drvdata)
+{
+ u32 reg;
+
+ reg = cc_ioread(drvdata, CC_REG(GPR_HOST));
+ return (reg == (CC_FIPS_SYNC_TEE_STATUS | CC_FIPS_SYNC_MODULE_OK));
+}
+
+/*
+ * This function should push the FIPS REE library status towards
[PATCH 5/7] crypto: ccree: add AEAD support
Add CryptoCell AEAD support
Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com>
---
drivers/crypto/ccree/Makefile|2 +-
drivers/crypto/ccree/cc_aead.c | 2702 ++
drivers/crypto/ccree/cc_aead.h | 109 ++
drivers/crypto/ccree/cc_buffer_mgr.c | 882 +++
drivers/crypto/ccree/cc_buffer_mgr.h |4 +
drivers/crypto/ccree/cc_driver.c | 10 +
drivers/crypto/ccree/cc_driver.h |4 +
7 files changed, 3712 insertions(+), 1 deletion(-)
create mode 100644 drivers/crypto/ccree/cc_aead.c
create mode 100644 drivers/crypto/ccree/cc_aead.h
diff --git a/drivers/crypto/ccree/Makefile b/drivers/crypto/ccree/Makefile
index 1109480..7cb3082 100644
--- a/drivers/crypto/ccree/Makefile
+++ b/drivers/crypto/ccree/Makefile
@@ -1,6 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_CRYPTO_DEV_CCREE) := ccree.o
-ccree-y := cc_driver.o cc_buffer_mgr.o cc_request_mgr.o cc_cipher.o cc_hash.o
cc_ivgen.o cc_sram_mgr.o
+ccree-y := cc_driver.o cc_buffer_mgr.o cc_request_mgr.o cc_cipher.o cc_hash.o
cc_aead.o cc_ivgen.o cc_sram_mgr.o
ccree-$(CONFIG_DEBUG_FS) += cc_debugfs.o
ccree-$(CONFIG_PM) += cc_pm.o
diff --git a/drivers/crypto/ccree/cc_aead.c b/drivers/crypto/ccree/cc_aead.c
new file mode 100644
index 000..265adff
--- /dev/null
+++ b/drivers/crypto/ccree/cc_aead.c
@@ -0,0 +1,2702 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (C) 2012-2018 ARM Limited or its affiliates. */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "cc_driver.h"
+#include "cc_buffer_mgr.h"
+#include "cc_aead.h"
+#include "cc_request_mgr.h"
+#include "cc_hash.h"
+#include "cc_sram_mgr.h"
+
+#define template_aead template_u.aead
+
+#define MAX_AEAD_SETKEY_SEQ 12
+#define MAX_AEAD_PROCESS_SEQ 23
+
+#define MAX_HMAC_DIGEST_SIZE (SHA256_DIGEST_SIZE)
+#define MAX_HMAC_BLOCK_SIZE (SHA256_BLOCK_SIZE)
+
+#define AES_CCM_RFC4309_NONCE_SIZE 3
+#define MAX_NONCE_SIZE CTR_RFC3686_NONCE_SIZE
+
+/* Value of each ICV_CMP byte (of 8) in case of success */
+#define ICV_VERIF_OK 0x01
+
+struct cc_aead_handle {
+ cc_sram_addr_t sram_workspace_addr;
+ struct list_head aead_list;
+};
+
+struct cc_hmac_s {
+ u8 *padded_authkey;
+ u8 *ipad_opad; /* IPAD, OPAD*/
+ dma_addr_t padded_authkey_dma_addr;
+ dma_addr_t ipad_opad_dma_addr;
+};
+
+struct cc_xcbc_s {
+ u8 *xcbc_keys; /* K1,K2,K3 */
+ dma_addr_t xcbc_keys_dma_addr;
+};
+
+struct cc_aead_ctx {
+ struct cc_drvdata *drvdata;
+ u8 ctr_nonce[MAX_NONCE_SIZE]; /* used for ctr3686 iv and aes ccm */
+ u8 *enckey;
+ dma_addr_t enckey_dma_addr;
+ union {
+ struct cc_hmac_s hmac;
+ struct cc_xcbc_s xcbc;
+ } auth_state;
+ unsigned int enc_keylen;
+ unsigned int auth_keylen;
+ unsigned int authsize; /* Actual (reduced?) size of the MAC/ICv */
+ enum drv_cipher_mode cipher_mode;
+ enum cc_flow_mode flow_mode;
+ enum drv_hash_mode auth_mode;
+};
+
+static inline bool valid_assoclen(struct aead_request *req)
+{
+ return ((req->assoclen == 16) || (req->assoclen == 20));
+}
+
+static void cc_aead_exit(struct crypto_aead *tfm)
+{
+ struct cc_aead_ctx *ctx = crypto_aead_ctx(tfm);
+ struct device *dev = drvdata_to_dev(ctx->drvdata);
+
+ dev_dbg(dev, "Clearing context @%p for %s\n", crypto_aead_ctx(tfm),
+ crypto_tfm_alg_name(>base));
+
+ /* Unmap enckey buffer */
+ if (ctx->enckey) {
+ dma_free_coherent(dev, AES_MAX_KEY_SIZE, ctx->enckey,
+ ctx->enckey_dma_addr);
+ dev_dbg(dev, "Freed enckey DMA buffer enckey_dma_addr=%pad\n",
+ >enckey_dma_addr);
+ ctx->enckey_dma_addr = 0;
+ ctx->enckey = NULL;
+ }
+
+ if (ctx->auth_mode == DRV_HASH_XCBC_MAC) { /* XCBC authetication */
+ struct cc_xcbc_s *xcbc = >auth_state.xcbc;
+
+ if (xcbc->xcbc_keys) {
+ dma_free_coherent(dev, CC_AES_128_BIT_KEY_SIZE * 3,
+ xcbc->xcbc_keys,
+ xcbc->xcbc_keys_dma_addr);
+ }
+ dev_dbg(dev, "Freed xcbc_keys DMA buffer
xcbc_keys_dma_addr=%pad\n",
+ >xcbc_keys_dma_addr);
+ xcbc->xcbc_keys_dma_addr = 0;
+ xcbc->xcbc_keys = NULL;
+ } else if (ctx->auth_mode != DRV_HASH_NULL) { /* HMAC auth. */
+ struct cc_hmac_s *hmac = >auth_state.hmac;
+
+ if (hmac->ipad_opad) {
+ dma_free_coherent(dev, 2 * MAX_HMAC_DIGEST_SIZE,
+ hmac->ipad_opad
[PATCH 4/7] crypto: ccree: add ahash support
Add CryptoCell async. hash and HMAC support.
Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com>
---
drivers/crypto/ccree/Makefile|2 +-
drivers/crypto/ccree/cc_buffer_mgr.c | 257
drivers/crypto/ccree/cc_driver.c | 13 +
drivers/crypto/ccree/cc_driver.h |1 +
drivers/crypto/ccree/cc_hash.c | 2297 ++
drivers/crypto/ccree/cc_hash.h | 114 ++
drivers/crypto/ccree/cc_pm.c |4 +
7 files changed, 2687 insertions(+), 1 deletion(-)
create mode 100644 drivers/crypto/ccree/cc_hash.c
create mode 100644 drivers/crypto/ccree/cc_hash.h
diff --git a/drivers/crypto/ccree/Makefile b/drivers/crypto/ccree/Makefile
index a7fecad..1109480 100644
--- a/drivers/crypto/ccree/Makefile
+++ b/drivers/crypto/ccree/Makefile
@@ -1,6 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_CRYPTO_DEV_CCREE) := ccree.o
-ccree-y := cc_driver.o cc_buffer_mgr.o cc_request_mgr.o cc_cipher.o cc_ivgen.o
cc_sram_mgr.o
+ccree-y := cc_driver.o cc_buffer_mgr.o cc_request_mgr.o cc_cipher.o cc_hash.o
cc_ivgen.o cc_sram_mgr.o
ccree-$(CONFIG_DEBUG_FS) += cc_debugfs.o
ccree-$(CONFIG_PM) += cc_pm.o
diff --git a/drivers/crypto/ccree/cc_buffer_mgr.c
b/drivers/crypto/ccree/cc_buffer_mgr.c
index 510993e..1ff379b 100644
--- a/drivers/crypto/ccree/cc_buffer_mgr.c
+++ b/drivers/crypto/ccree/cc_buffer_mgr.c
@@ -9,6 +9,7 @@
#include "cc_buffer_mgr.h"
#include "cc_lli_defs.h"
#include "cc_cipher.h"
+#include "cc_hash.h"
enum dma_buffer_type {
DMA_NULL_TYPE = -1,
@@ -348,6 +349,30 @@ static int cc_map_sg(struct device *dev, struct
scatterlist *sg,
return 0;
}
+static int cc_set_hash_buf(struct device *dev, struct ahash_req_ctx *areq_ctx,
+ u8 *curr_buff, u32 curr_buff_cnt,
+ struct buffer_array *sg_data)
+{
+ dev_dbg(dev, " handle curr buff %x set to DLLI\n", curr_buff_cnt);
+ /* create sg for the current buffer */
+ sg_init_one(areq_ctx->buff_sg, curr_buff, curr_buff_cnt);
+ if (dma_map_sg(dev, areq_ctx->buff_sg, 1, DMA_TO_DEVICE) != 1) {
+ dev_err(dev, "dma_map_sg() src buffer failed\n");
+ return -ENOMEM;
+ }
+ dev_dbg(dev, "Mapped curr_buff: dma_address=%pad page=%p addr=%pK
offset=%u length=%u\n",
+ _dma_address(areq_ctx->buff_sg), sg_page(areq_ctx->buff_sg),
+ sg_virt(areq_ctx->buff_sg), areq_ctx->buff_sg->offset,
+ areq_ctx->buff_sg->length);
+ areq_ctx->data_dma_buf_type = CC_DMA_BUF_DLLI;
+ areq_ctx->curr_sg = areq_ctx->buff_sg;
+ areq_ctx->in_nents = 0;
+ /* prepare for case of MLLI */
+ cc_add_sg_entry(dev, sg_data, 1, areq_ctx->buff_sg, curr_buff_cnt, 0,
+ false, NULL);
+ return 0;
+}
+
void cc_unmap_blkcipher_request(struct device *dev, void *ctx,
unsigned int ivsize, struct scatterlist *src,
struct scatterlist *dst)
@@ -472,6 +497,238 @@ int cc_map_blkcipher_request(struct cc_drvdata *drvdata,
void *ctx,
return rc;
}
+int cc_map_hash_request_final(struct cc_drvdata *drvdata, void *ctx,
+ struct scatterlist *src, unsigned int nbytes,
+ bool do_update, gfp_t flags)
+{
+ struct ahash_req_ctx *areq_ctx = (struct ahash_req_ctx *)ctx;
+ struct device *dev = drvdata_to_dev(drvdata);
+ u8 *curr_buff = cc_hash_buf(areq_ctx);
+ u32 *curr_buff_cnt = cc_hash_buf_cnt(areq_ctx);
+ struct mlli_params *mlli_params = _ctx->mlli_params;
+ struct buffer_array sg_data;
+ struct buff_mgr_handle *buff_mgr = drvdata->buff_mgr_handle;
+ u32 dummy = 0;
+ u32 mapped_nents = 0;
+
+ dev_dbg(dev, "final params : curr_buff=%pK curr_buff_cnt=0x%X nbytes =
0x%X src=%pK curr_index=%u\n",
+ curr_buff, *curr_buff_cnt, nbytes, src, areq_ctx->buff_index);
+ /* Init the type of the dma buffer */
+ areq_ctx->data_dma_buf_type = CC_DMA_BUF_NULL;
+ mlli_params->curr_pool = NULL;
+ sg_data.num_of_buffers = 0;
+ areq_ctx->in_nents = 0;
+
+ if (nbytes == 0 && *curr_buff_cnt == 0) {
+ /* nothing to do */
+ return 0;
+ }
+
+ /*TODO: copy data in case that buffer is enough for operation */
+ /* map the previous buffer */
+ if (*curr_buff_cnt) {
+ if (cc_set_hash_buf(dev, areq_ctx, curr_buff, *curr_buff_cnt,
+ _data)) {
+ return -ENOMEM;
+ }
+ }
+
+ if (src && nbytes > 0 && do_update) {
+ if (cc_map_sg(dev, src, nbytes, DMA_TO_DEVICE,
+ _ctx->in_nents,
[PATCH 7/7] MAINTAINERS: update ccree entry
Update Arm TrustZone CryptoCell driver entry move into drivers/crypto/ Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com> --- MAINTAINERS | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 1082846..560e068 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3273,12 +3273,11 @@ F: drivers/net/ieee802154/cc2520.c F: include/linux/spi/cc2520.h F: Documentation/devicetree/bindings/net/ieee802154/cc2520.txt -CCREE ARM TRUSTZONE CRYPTOCELL 700 REE DRIVER +CCREE ARM TRUSTZONE CRYPTOCELL REE DRIVER M: Gilad Ben-Yossef <gi...@benyossef.com> L: linux-crypto@vger.kernel.org -L: driverdev-de...@linuxdriverproject.org S: Supported -F: drivers/staging/ccree/ +F: drivers/crypto/ccree/ W: https://developer.arm.com/products/system-ip/trustzone-cryptocell/cryptocell-700-family CEC FRAMEWORK -- 2.7.4
[PATCH 0/7] Introduce Arm TrustZone CryptoCell
Arm TrustZone CryptoCell is a security hardware IP that
includes support for hardware based hash, digest, cipher
and AEAD operations. This driver provides support for
these as part of the Linux Crypto sub-system.
The driver spent some time now in the staging tree being
cleaned up and is now submitted for review for the
purpose of moving into the crypto tree. The first patch
therefore delete it's copy in the staging directory
otherwise there is a build failure due to collisions
with it's other copy there.
Please note that the driver include some stubs for yet
unexposed functionality (ivgen and secure HW keys).
Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com>
Gilad Ben-Yossef (7):
staging: ccree: remove ccree from staging tree
crypto: ccree: introduce CryptoCell driver
crypto: ccree: add ablkcipher support
crypto: ccree: add ahash support
crypto: ccree: add AEAD support
crypto: ccree: add FIPS support
MAINTAINERS: update ccree entry
MAINTAINERS|5 +-
drivers/crypto/Kconfig | 27 +
drivers/crypto/Makefile|1 +
drivers/crypto/ccree/Makefile |7 +
.../ccree/ssi_aead.c => crypto/ccree/cc_aead.c}| 1120 ++--
.../ccree/ssi_aead.h => crypto/ccree/cc_aead.h}| 56 +-
.../ccree/cc_buffer_mgr.c} | 1085 ++--
drivers/crypto/ccree/cc_buffer_mgr.h | 74 +
.../ssi_cipher.c => crypto/ccree/cc_cipher.c} | 716 +++-
drivers/crypto/ccree/cc_cipher.h | 74 +
drivers/{staging => crypto}/ccree/cc_crypto_ctx.h | 38 +-
drivers/crypto/ccree/cc_debugfs.c | 101 ++
drivers/crypto/ccree/cc_debugfs.h | 32 +
drivers/crypto/ccree/cc_driver.c | 477 +
drivers/crypto/ccree/cc_driver.h | 194 +++
.../ccree/ssi_fips.c => crypto/ccree/cc_fips.c}| 44 +-
drivers/crypto/ccree/cc_fips.h | 37 +
.../ccree/ssi_hash.c => crypto/ccree/cc_hash.c}| 1818 +---
drivers/crypto/ccree/cc_hash.h | 114 ++
drivers/crypto/ccree/cc_host_regs.h| 142 ++
.../{staging => crypto}/ccree/cc_hw_queue_defs.h | 40 +-
.../ccree/ssi_ivgen.c => crypto/ccree/cc_ivgen.c} | 141 +-
drivers/crypto/ccree/cc_ivgen.h| 55 +
drivers/crypto/ccree/cc_kernel_regs.h | 167 ++
drivers/{staging => crypto}/ccree/cc_lli_defs.h| 19 +-
drivers/crypto/ccree/cc_pm.c | 123 ++
drivers/crypto/ccree/cc_pm.h | 57 +
drivers/crypto/ccree/cc_request_mgr.c | 714
drivers/crypto/ccree/cc_request_mgr.h | 51 +
.../ssi_sram_mgr.c => crypto/ccree/cc_sram_mgr.c} | 70 +-
drivers/crypto/ccree/cc_sram_mgr.h | 65 +
drivers/staging/Kconfig|2 -
drivers/staging/Makefile |1 -
.../devicetree/bindings/crypto/arm-cryptocell.txt | 27 -
drivers/staging/ccree/Kconfig | 25 -
drivers/staging/ccree/Makefile |3 -
drivers/staging/ccree/TODO | 30 -
drivers/staging/ccree/dx_crys_kernel.h | 180 --
drivers/staging/ccree/dx_host.h| 155 --
drivers/staging/ccree/dx_reg_common.h | 26 -
drivers/staging/ccree/hash_defs.h | 36 -
drivers/staging/ccree/ssi_buffer_mgr.h | 91 -
drivers/staging/ccree/ssi_cipher.h | 84 -
drivers/staging/ccree/ssi_config.h | 36 -
drivers/staging/ccree/ssi_driver.c | 538 --
drivers/staging/ccree/ssi_driver.h | 206 ---
drivers/staging/ccree/ssi_fips.h | 49 -
drivers/staging/ccree/ssi_hash.h | 103 --
drivers/staging/ccree/ssi_ivgen.h | 71 -
drivers/staging/ccree/ssi_pm.c | 145 --
drivers/staging/ccree/ssi_pm.h | 43 -
drivers/staging/ccree/ssi_request_mgr.c| 610 ---
drivers/staging/ccree/ssi_request_mgr.h| 60 -
drivers/staging/ccree/ssi_sram_mgr.h | 79 -
drivers/staging/ccree/ssi_sysfs.c | 172 --
drivers/staging/ccree/ssi_sysfs.h | 55 -
56 files changed, 4706 insertions(+), 5785 deletions(-)
create mode 100644 drivers/crypto/ccree/Makefile
rename drivers/{staging/ccree/ssi_aead.c => crypto/ccree/cc_aead.c} (70%)
rename drivers/{staging/ccree/ssi_aead.h => crypto/ccree/cc_aead.h} (64%)
rename drivers/{staging/ccree/ssi_buffer_mgr.c =>
crypto/ccree/cc_buffer_mgr.c} (56%)
create mode 100644 drivers/crypto/ccree/cc_buffer_mgr.h
rename drivers/{staging/ccree/ssi_cipher.c => crypto/ccree/cc_cipher.c
Re: Getting the ccree driver out of staging
On Wed, Jan 10, 2018 at 6:39 PM, Greg Kroah-Hartman <gre...@linuxfoundation.org> wrote: > On Wed, Jan 10, 2018 at 08:54:55AM +0200, Gilad Ben-Yossef wrote: >> Hi folks, >> >> With the enormous help of people in the to and CCed lists I've gotten >> the ccree driver to a point I believe it is ready to graduate out of >> the staging tree: >> >> - The code base has been reduced by something by 30% and is *much* >> more readable and manageable. >> - The very few checkpatch warnings are all false positives (one due to >> dt bindings going through the crypto tree, the others due to harmless >> macro argument reuse) >> and the few sparse output are equally benign. >> - The driver follows the crypto API expected behavior as much as I can tell. >> - Fixed all the bugs I could fine as a result of tcrypt tests. >> - It works :-) >> >> There are obviously more things todo, but I believe they are out of >> scope for staging. >> >> So, if you see something that still needs work, kindly let me know. >> Alternatively, will you accept a patch moving it to drivers/crypto/? > > It might make more sense to just send a "new" patch adding the driver to > drivers/crypto/ and if that is accepted, we can drop it from staging. > That way it's easier for the crypto developers to review it. > > But it's up to them, whatever they want is fine with me. Thanks, Greg. Herbert, it's up to you - shall I send a new patch set or do you want to just move what's in the staging tree? Thanks, Gilad -- Gilad Ben-Yossef Chief Coffee Drinker "If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru
Getting the ccree driver out of staging
Hi folks, With the enormous help of people in the to and CCed lists I've gotten the ccree driver to a point I believe it is ready to graduate out of the staging tree: - The code base has been reduced by something by 30% and is *much* more readable and manageable. - The very few checkpatch warnings are all false positives (one due to dt bindings going through the crypto tree, the others due to harmless macro argument reuse) and the few sparse output are equally benign. - The driver follows the crypto API expected behavior as much as I can tell. - Fixed all the bugs I could fine as a result of tcrypt tests. - It works :-) There are obviously more things todo, but I believe they are out of scope for staging. So, if you see something that still needs work, kindly let me know. Alternatively, will you accept a patch moving it to drivers/crypto/? Many thanks, Gilad -- Gilad Ben-Yossef Chief Coffee Drinker "If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru
[PATCH 2/5] staging: ccree: remove unneeded includes
Remove include files not needed for compilation. Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com> --- drivers/staging/ccree/cc_aead.c| 7 --- drivers/staging/ccree/cc_buffer_mgr.c | 6 -- drivers/staging/ccree/cc_cipher.c | 4 drivers/staging/ccree/cc_driver.c | 31 --- drivers/staging/ccree/cc_hash.c| 2 -- drivers/staging/ccree/cc_ivgen.c | 1 - drivers/staging/ccree/cc_pm.c | 2 -- drivers/staging/ccree/cc_request_mgr.c | 5 - 8 files changed, 58 deletions(-) diff --git a/drivers/staging/ccree/cc_aead.c b/drivers/staging/ccree/cc_aead.c index da74423..265adff 100644 --- a/drivers/staging/ccree/cc_aead.c +++ b/drivers/staging/ccree/cc_aead.c @@ -3,18 +3,11 @@ #include #include -#include #include -#include -#include #include -#include -#include #include -#include #include #include -#include #include "cc_driver.h" #include "cc_buffer_mgr.h" #include "cc_aead.h" diff --git a/drivers/staging/ccree/cc_buffer_mgr.c b/drivers/staging/ccree/cc_buffer_mgr.c index 01c786c..14b2eab 100644 --- a/drivers/staging/ccree/cc_buffer_mgr.c +++ b/drivers/staging/ccree/cc_buffer_mgr.c @@ -1,17 +1,11 @@ // SPDX-License-Identifier: GPL-2.0 /* Copyright (C) 2012-2018 ARM Limited or its affiliates. */ -#include -#include -#include #include -#include #include #include #include #include -#include -#include #include "cc_buffer_mgr.h" #include "cc_lli_defs.h" diff --git a/drivers/staging/ccree/cc_cipher.c b/drivers/staging/ccree/cc_cipher.c index eca0578..8afdbc1 100644 --- a/drivers/staging/ccree/cc_cipher.c +++ b/drivers/staging/ccree/cc_cipher.c @@ -3,12 +3,8 @@ #include #include -#include -#include #include #include -#include -#include #include #include #include diff --git a/drivers/staging/ccree/cc_driver.c b/drivers/staging/ccree/cc_driver.c index 98d491e..b49bc25 100644 --- a/drivers/staging/ccree/cc_driver.c +++ b/drivers/staging/ccree/cc_driver.c @@ -5,43 +5,12 @@ #include #include -#include -#include -#include -#include -#include -#include -#include - -#include #include #include -#include -#include #include -#include -#include -#include -#include -#include -#include -#include #include -#include -#include -#include -#include -#include #include #include -#include - -/* cache.h required for L1_CACHE_ALIGN() and cache_line_size() */ -#include -#include -#include -#include -#include #include #include #include diff --git a/drivers/staging/ccree/cc_hash.c b/drivers/staging/ccree/cc_hash.c index 7c1645d..86f9ec7 100644 --- a/drivers/staging/ccree/cc_hash.c +++ b/drivers/staging/ccree/cc_hash.c @@ -3,10 +3,8 @@ #include #include -#include #include #include -#include #include #include diff --git a/drivers/staging/ccree/cc_ivgen.c b/drivers/staging/ccree/cc_ivgen.c index 43f70d4..25a3131 100644 --- a/drivers/staging/ccree/cc_ivgen.c +++ b/drivers/staging/ccree/cc_ivgen.c @@ -1,7 +1,6 @@ // SPDX-License-Identifier: GPL-2.0 /* Copyright (C) 2012-2018 ARM Limited or its affiliates. */ -#include #include #include "cc_driver.h" #include "cc_ivgen.h" diff --git a/drivers/staging/ccree/cc_pm.c b/drivers/staging/ccree/cc_pm.c index 1f5da86..c7d6b86 100644 --- a/drivers/staging/ccree/cc_pm.c +++ b/drivers/staging/ccree/cc_pm.c @@ -2,9 +2,7 @@ /* Copyright (C) 2012-2018 ARM Limited or its affiliates. */ #include -#include #include -#include #include #include "cc_driver.h" #include "cc_buffer_mgr.h" diff --git a/drivers/staging/ccree/cc_request_mgr.c b/drivers/staging/ccree/cc_request_mgr.c index cbcfcc3..8372410 100644 --- a/drivers/staging/ccree/cc_request_mgr.c +++ b/drivers/staging/ccree/cc_request_mgr.c @@ -2,11 +2,6 @@ /* Copyright (C) 2012-2018 ARM Limited or its affiliates. */ #include -#include -#include -#include -#include -#include #include "cc_driver.h" #include "cc_buffer_mgr.h" #include "cc_request_mgr.h" -- 2.7.4
[PATCH 1/5] staging: ccree: use a consistent file naming convention
The ccree driver source files were using an inconsistent
naming convention stemming from what the company was called
when they were added.
Move to a single consistent naming convention for better
code readability.
Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com>
---
drivers/staging/ccree/Makefile | 6 +++---
drivers/staging/ccree/{ssi_aead.c => cc_aead.c} | 12 ++--
drivers/staging/ccree/{ssi_aead.h => cc_aead.h} | 2 +-
.../ccree/{ssi_buffer_mgr.c => cc_buffer_mgr.c} | 8
.../ccree/{ssi_buffer_mgr.h => cc_buffer_mgr.h} | 4 ++--
drivers/staging/ccree/{ssi_cipher.c => cc_cipher.c} | 8
drivers/staging/ccree/{ssi_cipher.h => cc_cipher.h} | 6 +++---
drivers/staging/ccree/cc_debugfs.c | 2 +-
drivers/staging/ccree/{ssi_driver.c => cc_driver.c} | 20 ++--
drivers/staging/ccree/{ssi_driver.h => cc_driver.h} | 6 +++---
drivers/staging/ccree/{ssi_fips.c => cc_fips.c} | 4 ++--
drivers/staging/ccree/{ssi_fips.h => cc_fips.h} | 0
drivers/staging/ccree/{ssi_hash.c => cc_hash.c} | 10 +-
drivers/staging/ccree/{ssi_hash.h => cc_hash.h} | 4 ++--
drivers/staging/ccree/{dx_host.h => cc_host_regs.h} | 0
drivers/staging/ccree/cc_hw_queue_defs.h | 2 +-
drivers/staging/ccree/{ssi_ivgen.c => cc_ivgen.c}| 10 +-
drivers/staging/ccree/{ssi_ivgen.h => cc_ivgen.h}| 0
.../ccree/{dx_crys_kernel.h => cc_kernel_regs.h} | 0
drivers/staging/ccree/{ssi_pm.c => cc_pm.c} | 14 +++---
drivers/staging/ccree/{ssi_pm.h => cc_pm.h} | 4 ++--
.../ccree/{ssi_request_mgr.c => cc_request_mgr.c}| 10 +-
.../ccree/{ssi_request_mgr.h => cc_request_mgr.h}| 2 +-
.../staging/ccree/{ssi_sram_mgr.c => cc_sram_mgr.c} | 4 ++--
.../staging/ccree/{ssi_sram_mgr.h => cc_sram_mgr.h} | 0
25 files changed, 69 insertions(+), 69 deletions(-)
rename drivers/staging/ccree/{ssi_aead.c => cc_aead.c} (99%)
rename drivers/staging/ccree/{ssi_aead.h => cc_aead.h} (99%)
rename drivers/staging/ccree/{ssi_buffer_mgr.c => cc_buffer_mgr.c} (99%)
rename drivers/staging/ccree/{ssi_buffer_mgr.h => cc_buffer_mgr.h} (97%)
rename drivers/staging/ccree/{ssi_cipher.c => cc_cipher.c} (99%)
rename drivers/staging/ccree/{ssi_cipher.h => cc_cipher.h} (95%)
rename drivers/staging/ccree/{ssi_driver.c => cc_driver.c} (98%)
rename drivers/staging/ccree/{ssi_driver.h => cc_driver.h} (98%)
rename drivers/staging/ccree/{ssi_fips.c => cc_fips.c} (98%)
rename drivers/staging/ccree/{ssi_fips.h => cc_fips.h} (100%)
rename drivers/staging/ccree/{ssi_hash.c => cc_hash.c} (99%)
rename drivers/staging/ccree/{ssi_hash.h => cc_hash.h} (98%)
rename drivers/staging/ccree/{dx_host.h => cc_host_regs.h} (100%)
rename drivers/staging/ccree/{ssi_ivgen.c => cc_ivgen.c} (98%)
rename drivers/staging/ccree/{ssi_ivgen.h => cc_ivgen.h} (100%)
rename drivers/staging/ccree/{dx_crys_kernel.h => cc_kernel_regs.h} (100%)
rename drivers/staging/ccree/{ssi_pm.c => cc_pm.c} (93%)
rename drivers/staging/ccree/{ssi_pm.h => cc_pm.h} (95%)
rename drivers/staging/ccree/{ssi_request_mgr.c => cc_request_mgr.c} (99%)
rename drivers/staging/ccree/{ssi_request_mgr.h => cc_request_mgr.h} (98%)
rename drivers/staging/ccree/{ssi_sram_mgr.c => cc_sram_mgr.c} (98%)
rename drivers/staging/ccree/{ssi_sram_mgr.h => cc_sram_mgr.h} (100%)
diff --git a/drivers/staging/ccree/Makefile b/drivers/staging/ccree/Makefile
index c107e25..bdc2797 100644
--- a/drivers/staging/ccree/Makefile
+++ b/drivers/staging/ccree/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_CRYPTO_DEV_CCREE) := ccree.o
-ccree-y := ssi_driver.o ssi_buffer_mgr.o ssi_request_mgr.o ssi_cipher.o
ssi_hash.o ssi_aead.o ssi_ivgen.o ssi_sram_mgr.o
-ccree-$(CONFIG_CRYPTO_FIPS) += ssi_fips.o
+ccree-y := cc_driver.o cc_buffer_mgr.o cc_request_mgr.o cc_cipher.o cc_hash.o
cc_aead.o cc_ivgen.o cc_sram_mgr.o
+ccree-$(CONFIG_CRYPTO_FIPS) += cc_fips.o
ccree-$(CONFIG_DEBUG_FS) += cc_debugfs.o
-ccree-$(CONFIG_PM) += ssi_pm.o
+ccree-$(CONFIG_PM) += cc_pm.o
diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/cc_aead.c
similarity index 99%
rename from drivers/staging/ccree/ssi_aead.c
rename to drivers/staging/ccree/cc_aead.c
index 6f41a00..da74423 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/cc_aead.c
@@ -15,12 +15,12 @@
#include
#include
#include
-#include "ssi_driver.h"
-#include "ssi_buffer_mgr.h"
-#include "ssi_aead.h"
-#include "ssi_request_mgr.h"
-#include "ssi_hash.h"
-#include "ssi_sram_mgr.h"
+#include "cc_driver.h"
+#include "cc_buffer_mgr.h"
+#include "cc_aead.h"
+#include "cc_request_mgr.h"
+#include "c
[PATCH 3/5] staging: ccree: add missing include
Add the missing include of include file with function declarations.
Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com>
---
drivers/staging/ccree/cc_debugfs.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/ccree/cc_debugfs.c
b/drivers/staging/ccree/cc_debugfs.c
index f927a73..08f8db4 100644
--- a/drivers/staging/ccree/cc_debugfs.c
+++ b/drivers/staging/ccree/cc_debugfs.c
@@ -6,6 +6,7 @@
#include
#include "cc_driver.h"
#include "cc_crypto_ctx.h"
+#include "cc_debugfs.h"
struct cc_debugfs_ctx {
struct dentry *dir;
--
2.7.4
[PATCH 4/5] staging: ccree: make stub function static inline
The debugfs interface defines stub function if debugfs is not
enabled, which were missing the 'static inline' qualifiers causing
sparse warnings.
Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com>
---
drivers/staging/ccree/cc_debugfs.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/ccree/cc_debugfs.h
b/drivers/staging/ccree/cc_debugfs.h
index 354ec17..5b5320e 100644
--- a/drivers/staging/ccree/cc_debugfs.h
+++ b/drivers/staging/ccree/cc_debugfs.h
@@ -13,19 +13,19 @@ void cc_debugfs_fini(struct cc_drvdata *drvdata);
#else
-int cc_debugfs_global_init(void)
+static inline int cc_debugfs_global_init(void)
{
return 0;
}
-void cc_debugfs_global_fini(void) {}
+static inline void cc_debugfs_global_fini(void) {}
-int cc_debugfs_init(struct cc_drvdata *drvdata)
+static inline int cc_debugfs_init(struct cc_drvdata *drvdata)
{
return 0;
}
-void cc_debugfs_fini(struct cc_drvdata *drvdata) {}
+static inline void cc_debugfs_fini(struct cc_drvdata *drvdata) {}
#endif
--
2.7.4
[PATCH 5/5] staging: ccree: dma mask is type u64
The dma mask var was defined as dma_addr_t but should be
u64. This showed as a sparse warning when building for 32 bit.
Fix it by changing type to u64 and drop the cast.
Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com>
---
drivers/staging/ccree/cc_driver.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/ccree/cc_driver.c
b/drivers/staging/ccree/cc_driver.c
index b49bc25..6682d9d 100644
--- a/drivers/staging/ccree/cc_driver.c
+++ b/drivers/staging/ccree/cc_driver.c
@@ -156,7 +156,7 @@ static int init_cc_resources(struct platform_device
*plat_dev)
struct device *dev = _dev->dev;
struct device_node *np = dev->of_node;
u32 signature_val;
- dma_addr_t dma_mask;
+ u64 dma_mask;
int rc = 0;
new_drvdata = devm_kzalloc(dev, sizeof(*new_drvdata), GFP_KERNEL);
@@ -205,7 +205,7 @@ static int init_cc_resources(struct platform_device
*plat_dev)
if (!plat_dev->dev.dma_mask)
plat_dev->dev.dma_mask = _dev->dev.coherent_dma_mask;
- dma_mask = (dma_addr_t)(DMA_BIT_MASK(DMA_BIT_MASK_LEN));
+ dma_mask = DMA_BIT_MASK(DMA_BIT_MASK_LEN);
while (dma_mask > 0x7fffUL) {
if (dma_supported(_dev->dev, dma_mask)) {
rc = dma_set_coherent_mask(_dev->dev, dma_mask);
--
2.7.4
[PATCH 0/5] more cleanups
File name consistency renames, include files diet and address
some sparse warnings.
Gilad Ben-Yossef (5):
staging: ccree: use a consistent file naming convention
staging: ccree: remove unneeded includes
staging: ccree: add missing include
staging: ccree: make stub function static inline
staging: ccree: dma mask is type u64
drivers/staging/ccree/Makefile | 6 +--
drivers/staging/ccree/{ssi_aead.c => cc_aead.c}| 19 +++-
drivers/staging/ccree/{ssi_aead.h => cc_aead.h}| 2 +-
.../ccree/{ssi_buffer_mgr.c => cc_buffer_mgr.c}| 14 ++
.../ccree/{ssi_buffer_mgr.h => cc_buffer_mgr.h}| 4 +-
.../staging/ccree/{ssi_cipher.c => cc_cipher.c}| 12 ++---
.../staging/ccree/{ssi_cipher.h => cc_cipher.h}| 6 +--
drivers/staging/ccree/cc_debugfs.c | 3 +-
drivers/staging/ccree/cc_debugfs.h | 8 ++--
.../staging/ccree/{ssi_driver.c => cc_driver.c}| 55 +-
.../staging/ccree/{ssi_driver.h => cc_driver.h}| 6 +--
drivers/staging/ccree/{ssi_fips.c => cc_fips.c}| 4 +-
drivers/staging/ccree/{ssi_fips.h => cc_fips.h}| 0
drivers/staging/ccree/{ssi_hash.c => cc_hash.c}| 12 ++---
drivers/staging/ccree/{ssi_hash.h => cc_hash.h}| 4 +-
.../staging/ccree/{dx_host.h => cc_host_regs.h}| 0
drivers/staging/ccree/cc_hw_queue_defs.h | 2 +-
drivers/staging/ccree/{ssi_ivgen.c => cc_ivgen.c} | 11 ++---
drivers/staging/ccree/{ssi_ivgen.h => cc_ivgen.h} | 0
.../ccree/{dx_crys_kernel.h => cc_kernel_regs.h} | 0
drivers/staging/ccree/{ssi_pm.c => cc_pm.c}| 16 +++
drivers/staging/ccree/{ssi_pm.h => cc_pm.h}| 4 +-
.../ccree/{ssi_request_mgr.c => cc_request_mgr.c} | 15 ++
.../ccree/{ssi_request_mgr.h => cc_request_mgr.h} | 2 +-
.../ccree/{ssi_sram_mgr.c => cc_sram_mgr.c}| 4 +-
.../ccree/{ssi_sram_mgr.h => cc_sram_mgr.h}| 0
26 files changed, 76 insertions(+), 133 deletions(-)
rename drivers/staging/ccree/{ssi_aead.c => cc_aead.c} (99%)
rename drivers/staging/ccree/{ssi_aead.h => cc_aead.h} (99%)
rename drivers/staging/ccree/{ssi_buffer_mgr.c => cc_buffer_mgr.c} (99%)
rename drivers/staging/ccree/{ssi_buffer_mgr.h => cc_buffer_mgr.h} (97%)
rename drivers/staging/ccree/{ssi_cipher.c => cc_cipher.c} (99%)
rename drivers/staging/ccree/{ssi_cipher.h => cc_cipher.h} (95%)
rename drivers/staging/ccree/{ssi_driver.c => cc_driver.c} (90%)
rename drivers/staging/ccree/{ssi_driver.h => cc_driver.h} (98%)
rename drivers/staging/ccree/{ssi_fips.c => cc_fips.c} (98%)
rename drivers/staging/ccree/{ssi_fips.h => cc_fips.h} (100%)
rename drivers/staging/ccree/{ssi_hash.c => cc_hash.c} (99%)
rename drivers/staging/ccree/{ssi_hash.h => cc_hash.h} (98%)
rename drivers/staging/ccree/{dx_host.h => cc_host_regs.h} (100%)
rename drivers/staging/ccree/{ssi_ivgen.c => cc_ivgen.c} (97%)
rename drivers/staging/ccree/{ssi_ivgen.h => cc_ivgen.h} (100%)
rename drivers/staging/ccree/{dx_crys_kernel.h => cc_kernel_regs.h} (100%)
rename drivers/staging/ccree/{ssi_pm.c => cc_pm.c} (91%)
rename drivers/staging/ccree/{ssi_pm.h => cc_pm.h} (95%)
rename drivers/staging/ccree/{ssi_request_mgr.c => cc_request_mgr.c} (98%)
rename drivers/staging/ccree/{ssi_request_mgr.h => cc_request_mgr.h} (98%)
rename drivers/staging/ccree/{ssi_sram_mgr.c => cc_sram_mgr.c} (98%)
rename drivers/staging/ccree/{ssi_sram_mgr.h => cc_sram_mgr.h} (100%)
--
2.7.4
Re: [PATCH v3 24/27] staging: ccree: use a consistent file naming convention
On Mon, Jan 8, 2018 at 5:28 PM, Greg Kroah-Hartman <gre...@linuxfoundation.org> wrote: > On Sun, Jan 07, 2018 at 12:14:35PM +0000, Gilad Ben-Yossef wrote: >> The ccree driver source files were using an inconsistent >> naming convention stemming from what the company was called >> when they were added. >> >> Move to a single consistent naming convention for better >> code readability. >> >> Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com> >> --- >> drivers/staging/ccree/Makefile |6 +- >> drivers/staging/ccree/cc_aead.c | 2709 >> ++ >> drivers/staging/ccree/cc_aead.h | 109 ++ >> drivers/staging/ccree/cc_buffer_mgr.c| 1657 ++ >> drivers/staging/ccree/cc_buffer_mgr.h| 74 + >> drivers/staging/ccree/cc_cipher.c| 1171 + >> drivers/staging/ccree/cc_cipher.h| 74 + >> drivers/staging/ccree/cc_debugfs.c |2 +- >> drivers/staging/ccree/cc_driver.c| 508 ++ >> drivers/staging/ccree/cc_driver.h| 194 +++ >> drivers/staging/ccree/cc_fips.c | 112 ++ >> drivers/staging/ccree/cc_fips.h | 37 + >> drivers/staging/ccree/cc_hash.c | 2299 + >> drivers/staging/ccree/cc_hash.h | 114 ++ >> drivers/staging/ccree/cc_host_regs.h | 142 ++ >> drivers/staging/ccree/cc_hw_queue_defs.h |2 +- >> drivers/staging/ccree/cc_ivgen.c | 281 >> drivers/staging/ccree/cc_ivgen.h | 55 + >> drivers/staging/ccree/cc_kernel_regs.h | 167 ++ >> drivers/staging/ccree/cc_pm.c| 125 ++ >> drivers/staging/ccree/cc_pm.h| 57 + >> drivers/staging/ccree/cc_request_mgr.c | 719 >> drivers/staging/ccree/cc_request_mgr.h | 51 + >> drivers/staging/ccree/cc_sram_mgr.c | 107 ++ >> drivers/staging/ccree/cc_sram_mgr.h | 65 + >> drivers/staging/ccree/dx_crys_kernel.h | 167 -- >> drivers/staging/ccree/dx_host.h | 142 -- >> drivers/staging/ccree/ssi_aead.c | 2709 >> -- >> drivers/staging/ccree/ssi_aead.h | 109 -- >> drivers/staging/ccree/ssi_buffer_mgr.c | 1657 -- >> drivers/staging/ccree/ssi_buffer_mgr.h | 74 - >> drivers/staging/ccree/ssi_cipher.c | 1171 - >> drivers/staging/ccree/ssi_cipher.h | 74 - >> drivers/staging/ccree/ssi_driver.c | 508 -- >> drivers/staging/ccree/ssi_driver.h | 194 --- >> drivers/staging/ccree/ssi_fips.c | 112 -- >> drivers/staging/ccree/ssi_fips.h | 37 - >> drivers/staging/ccree/ssi_hash.c | 2299 - >> drivers/staging/ccree/ssi_hash.h | 114 -- >> drivers/staging/ccree/ssi_ivgen.c| 281 >> drivers/staging/ccree/ssi_ivgen.h| 55 - >> drivers/staging/ccree/ssi_pm.c | 125 -- >> drivers/staging/ccree/ssi_pm.h | 57 - >> drivers/staging/ccree/ssi_request_mgr.c | 719 >> drivers/staging/ccree/ssi_request_mgr.h | 51 - >> drivers/staging/ccree/ssi_sram_mgr.c | 107 -- >> drivers/staging/ccree/ssi_sram_mgr.h | 65 - >> 47 files changed, 10832 insertions(+), 10832 deletions(-) >> create mode 100644 drivers/staging/ccree/cc_aead.c >> create mode 100644 drivers/staging/ccree/cc_aead.h >> create mode 100644 drivers/staging/ccree/cc_buffer_mgr.c >> create mode 100644 drivers/staging/ccree/cc_buffer_mgr.h >> create mode 100644 drivers/staging/ccree/cc_cipher.c >> create mode 100644 drivers/staging/ccree/cc_cipher.h >> create mode 100644 drivers/staging/ccree/cc_driver.c >> create mode 100644 drivers/staging/ccree/cc_driver.h >> create mode 100644 drivers/staging/ccree/cc_fips.c >> create mode 100644 drivers/staging/ccree/cc_fips.h >> create mode 100644 drivers/staging/ccree/cc_hash.c >> create mode 100644 drivers/staging/ccree/cc_hash.h >> create mode 100644 drivers/staging/ccree/cc_host_regs.h >> create mode 100644 drivers/staging/ccree/cc_ivgen.c >> create mode 100644 drivers/staging/ccree/cc_ivgen.h >> create mode 100644 drivers/staging/ccree/cc_kernel_regs.h >> create mode 100644 drivers/staging/ccree/cc_pm.c >> create mode 100644 drivers/staging/ccree/cc_pm.h >> create mode 100644 drivers/staging/ccree/cc_request_mgr.c >> create mode 100644 drivers/staging/ccree/cc_request_mgr.h >> create mode 100644 drivers/staging/ccree/cc_sram_mgr.c >> create mo
Re: [PATCH] checkpatch: add *_ON_STACK to $declaration_macros
On Wed, Dec 20, 2017 at 11:41 AM, Joe Perches <j...@perches.com> wrote:
> On Tue, 2017-06-27 at 10:55 +0300, Gilad Ben-Yossef wrote:
>> Add the crypto API *_ON_STACK to $declaration_macros.
>>
>> Resolves the following false warning:
>>
>> WARNING: Missing a blank line after declarations
>> + int err;
>> + SHASH_DESC_ON_STACK(desc, ctx_p->shash_tfm);
> []
>> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> []
>> @@ -733,6 +733,7 @@ our $FuncArg =
>> qr{$Typecast{0,1}($LvalOrFunc|$Constant|$String)};
>> our $declaration_macros = qr{(?x:
>>
>> (?:$Storage\s+)?(?:[A-Z_][A-Z0-9]*_){0,2}(?:DEFINE|DECLARE)(?:_[A-Z0-9]+){1,6}\s*\(|
>> (?:$Storage\s+)?LIST_HEAD\s*\(|
>> + (?:$Storage\s+)?[A-Z_]*_ON_STACK\(|
>
> A few things:
>
> The crypto _ON_STACK declarations cannot have a $Storage type.
>
> There should be a \s* between the ON_STACK and the open parenthesis
>
> There are other _ON_STACK types than the crypto uses
>
> $ grep -rP --include=*.[ch] -oh "\b[A-Z_]+_ON_STACK\b" * | \
> sort | uniq -c | sort -rn
> 68 SKCIPHER_REQUEST_ON_STACK
> 45 SHASH_DESC_ON_STACK
> 10 AHASH_REQUEST_ON_STACK
> 4 PC_LOC_ON_STACK
> 4 DECLARE_DPM_WATCHDOG_ON_STACK
> 3 HISI_SAS_DECLARE_RST_WORK_ON_STACK
> 3 CONFIG_ARCH_TASK_STRUCT_ON_STACK
> 1 PT_SIZE_ON_STACK
> 1 ALLOC_PT_GPREGS_ON_STACK
>
> So perhaps:
>
> (?:SKCIPHER_REQUEST|SHASH_DESC|AHASH_REQUEST)_ON_STACK\s*\(
>
Yes, it's better.
I'll send a v2.
Thanks,
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
-- Jean-Baptiste Queru
[PATCH v3 06/27] staging: ccree: copy larval digest from RAM
The ccree driver was using a DMA operation to copy larval digest
from the ccree SRAM to RAM. Replace it with a simple memcpy.
Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com>
---
drivers/staging/ccree/ssi_driver.c | 2 +
drivers/staging/ccree/ssi_hash.c | 121 -
drivers/staging/ccree/ssi_hash.h | 2 +
3 files changed, 68 insertions(+), 57 deletions(-)
diff --git a/drivers/staging/ccree/ssi_driver.c
b/drivers/staging/ccree/ssi_driver.c
index 3eabefb..b5df9b4 100644
--- a/drivers/staging/ccree/ssi_driver.c
+++ b/drivers/staging/ccree/ssi_driver.c
@@ -484,6 +484,8 @@ static int __init ccree_init(void)
{
int ret;
+ cc_hash_global_init();
+
ret = cc_debugfs_global_init();
if (ret)
return ret;
diff --git a/drivers/staging/ccree/ssi_hash.c b/drivers/staging/ccree/ssi_hash.c
index 7a8a036..b51a1d4 100644
--- a/drivers/staging/ccree/ssi_hash.c
+++ b/drivers/staging/ccree/ssi_hash.c
@@ -41,10 +41,10 @@ static const u32 sha256_init[] = {
#if (CC_DEV_SHA_MAX > 256)
static const u32 digest_len_sha512_init[] = {
0x0080, 0x, 0x, 0x };
-static const u64 sha384_init[] = {
+static u64 sha384_init[] = {
SHA384_H7, SHA384_H6, SHA384_H5, SHA384_H4,
SHA384_H3, SHA384_H2, SHA384_H1, SHA384_H0 };
-static const u64 sha512_init[] = {
+static u64 sha512_init[] = {
SHA512_H7, SHA512_H6, SHA512_H5, SHA512_H4,
SHA512_H3, SHA512_H2, SHA512_H1, SHA512_H0 };
#endif
@@ -55,6 +55,8 @@ static void cc_setup_xcbc(struct ahash_request *areq, struct
cc_hw_desc desc[],
static void cc_setup_cmac(struct ahash_request *areq, struct cc_hw_desc desc[],
unsigned int *seq_size);
+static const void *cc_larval_digest(struct device *dev, u32 mode);
+
struct cc_hash_alg {
struct list_head entry;
int hash_mode;
@@ -126,10 +128,6 @@ static int cc_map_req(struct device *dev, struct
ahash_req_ctx *state,
struct cc_hash_ctx *ctx, gfp_t flags)
{
bool is_hmac = ctx->is_hmac;
- cc_sram_addr_t larval_digest_addr =
- cc_larval_digest_addr(ctx->drvdata, ctx->hash_mode);
- struct cc_crypto_req cc_req = {};
- struct cc_hw_desc desc;
int rc = -ENOMEM;
state->buff0 = kzalloc(CC_MAX_HASH_BLCK_SIZE, flags);
@@ -203,9 +201,6 @@ static int cc_map_req(struct device *dev, struct
ahash_req_ctx *state,
HASH_LEN_SIZE);
#endif
}
- dma_sync_single_for_device(dev, state->digest_buff_dma_addr,
- ctx->inter_digestsize,
- DMA_BIDIRECTIONAL);
if (ctx->hash_mode != DRV_HASH_NULL) {
dma_sync_single_for_cpu(dev,
@@ -216,22 +211,15 @@ static int cc_map_req(struct device *dev, struct
ahash_req_ctx *state,
ctx->opad_tmp_keys_buff, ctx->inter_digestsize);
}
} else { /*hash*/
- /* Copy the initial digests if hash flow. The SRAM contains the
-* initial digests in the expected order for all SHA*
-*/
- hw_desc_init();
- set_din_sram(, larval_digest_addr, ctx->inter_digestsize);
- set_dout_dlli(, state->digest_buff_dma_addr,
- ctx->inter_digestsize, NS_BIT, 0);
- set_flow_mode(, BYPASS);
+ /* Copy the initial digests if hash flow. */
+ const void *larval = cc_larval_digest(dev, ctx->hash_mode);
- rc = send_request(ctx->drvdata, _req, , 1, 0);
- if (rc) {
- dev_err(dev, "send_request() failed (rc=%d)\n", rc);
- goto fail4;
- }
+ memcpy(state->digest_buff, larval, ctx->inter_digestsize);
}
+ dma_sync_single_for_device(dev, state->digest_buff_dma_addr,
+ ctx->inter_digestsize, DMA_BIDIRECTIONAL);
+
if (ctx->hw_mode != DRV_CIPHER_XCBC_MAC) {
state->digest_bytes_len_dma_addr =
dma_map_single(dev, (void *)state->digest_bytes_len,
@@ -2003,11 +1991,7 @@ int cc_init_hash_sram(struct cc_drvdata *drvdata)
cc_sram_addr_t sram_buff_ofs = hash_handle->digest_len_sram_addr;
unsigned int larval_seq_len = 0;
struct cc_hw_desc larval_seq[CC_DIGEST_SIZE_MAX / sizeof(u32)];
- struct device *dev = drvdata_to_dev(drvdata);
int rc = 0;
-#if (CC_DEV_SHA_MAX > 256)
- int i;
-#endif
/* Copy-to-sram digest-len */
cc_set_sram_desc(digest_len_init, sram_buff_ofs,
@@ -2074,49 +2058,49 @@ int cc_init_hash_sram(struct cc_drvdata *drvdata)
larval_seq_len = 0;
#if (CC_DE
[PATCH v3 07/27] staging: ccree: tag debugfs init/exit func properly
The debugfs global init and exit functions were missing
__init and __exit tags, potentially wasting memory.
Fix it by properly tagging them.
Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com>
---
drivers/staging/ccree/cc_debugfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/ccree/cc_debugfs.c
b/drivers/staging/ccree/cc_debugfs.c
index ab2c986..72eb2b3 100644
--- a/drivers/staging/ccree/cc_debugfs.c
+++ b/drivers/staging/ccree/cc_debugfs.c
@@ -38,14 +38,14 @@ static struct debugfs_reg32 debug_regs[] = {
CC_DEBUG_REG(AXIM_MON_COMP),
};
-int cc_debugfs_global_init(void)
+int __init cc_debugfs_global_init(void)
{
cc_debugfs_dir = debugfs_create_dir("ccree", NULL);
return !cc_debugfs_dir;
}
-void cc_debugfs_global_fini(void)
+void __exit cc_debugfs_global_fini(void)
{
debugfs_remove(cc_debugfs_dir);
}
--
2.7.4
[PATCH v3 04/27] staging: ccree: remove GFP_DMA flag from mem allocs
Remove bogus GFP_DMA flag from memory allocations. ccree driver
does not operate over an ISA or similar limited bus.
Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com>
---
drivers/staging/ccree/ssi_cipher.c | 2 +-
drivers/staging/ccree/ssi_hash.c | 15 ++-
2 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/ccree/ssi_cipher.c
b/drivers/staging/ccree/ssi_cipher.c
index 6178d38..496eb19 100644
--- a/drivers/staging/ccree/ssi_cipher.c
+++ b/drivers/staging/ccree/ssi_cipher.c
@@ -166,7 +166,7 @@ static int cc_cipher_init(struct crypto_tfm *tfm)
ctx_p->drvdata = cc_alg->drvdata;
/* Allocate key buffer, cache line aligned */
- ctx_p->user.key = kmalloc(max_key_buf_size, GFP_KERNEL | GFP_DMA);
+ ctx_p->user.key = kmalloc(max_key_buf_size, GFP_KERNEL);
if (!ctx_p->user.key)
return -ENOMEM;
diff --git a/drivers/staging/ccree/ssi_hash.c b/drivers/staging/ccree/ssi_hash.c
index 3c28904..f178ffa 100644
--- a/drivers/staging/ccree/ssi_hash.c
+++ b/drivers/staging/ccree/ssi_hash.c
@@ -132,29 +132,27 @@ static int cc_map_req(struct device *dev, struct
ahash_req_ctx *state,
struct cc_hw_desc desc;
int rc = -ENOMEM;
- state->buff0 = kzalloc(CC_MAX_HASH_BLCK_SIZE, GFP_KERNEL | GFP_DMA);
+ state->buff0 = kzalloc(CC_MAX_HASH_BLCK_SIZE, GFP_KERNEL);
if (!state->buff0)
goto fail0;
- state->buff1 = kzalloc(CC_MAX_HASH_BLCK_SIZE, GFP_KERNEL | GFP_DMA);
+ state->buff1 = kzalloc(CC_MAX_HASH_BLCK_SIZE, GFP_KERNEL);
if (!state->buff1)
goto fail_buff0;
state->digest_result_buff = kzalloc(CC_MAX_HASH_DIGEST_SIZE,
- GFP_KERNEL | GFP_DMA);
+ GFP_KERNEL);
if (!state->digest_result_buff)
goto fail_buff1;
- state->digest_buff = kzalloc(ctx->inter_digestsize,
-GFP_KERNEL | GFP_DMA);
+ state->digest_buff = kzalloc(ctx->inter_digestsize, GFP_KERNEL);
if (!state->digest_buff)
goto fail_digest_result_buff;
dev_dbg(dev, "Allocated digest-buffer in context
ctx->digest_buff=@%p\n",
state->digest_buff);
if (ctx->hw_mode != DRV_CIPHER_XCBC_MAC) {
- state->digest_bytes_len = kzalloc(HASH_LEN_SIZE,
- GFP_KERNEL | GFP_DMA);
+ state->digest_bytes_len = kzalloc(HASH_LEN_SIZE, GFP_KERNEL);
if (!state->digest_bytes_len)
goto fail1;
@@ -164,8 +162,7 @@ static int cc_map_req(struct device *dev, struct
ahash_req_ctx *state,
state->digest_bytes_len = NULL;
}
- state->opad_digest_buff = kzalloc(ctx->inter_digestsize,
- GFP_KERNEL | GFP_DMA);
+ state->opad_digest_buff = kzalloc(ctx->inter_digestsize, GFP_KERNEL);
if (!state->opad_digest_buff)
goto fail2;
--
2.7.4
[PATCH v3 01/27] staging: ccree: SPDXify driver
Replace verbatim GPL v2 copy with SPDX tag. Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com> --- drivers/staging/ccree/Kconfig| 2 ++ drivers/staging/ccree/Makefile | 2 ++ drivers/staging/ccree/cc_crypto_ctx.h| 17 ++--- drivers/staging/ccree/cc_debugfs.c | 17 ++--- drivers/staging/ccree/cc_debugfs.h | 17 ++--- drivers/staging/ccree/cc_hw_queue_defs.h | 17 ++--- drivers/staging/ccree/cc_lli_defs.h | 17 ++--- drivers/staging/ccree/dx_crys_kernel.h | 17 ++--- drivers/staging/ccree/dx_host.h | 17 ++--- drivers/staging/ccree/dx_reg_common.h| 17 ++--- drivers/staging/ccree/hash_defs.h| 17 ++--- drivers/staging/ccree/ssi_aead.c | 17 ++--- drivers/staging/ccree/ssi_aead.h | 17 ++--- drivers/staging/ccree/ssi_buffer_mgr.c | 17 ++--- drivers/staging/ccree/ssi_buffer_mgr.h | 17 ++--- drivers/staging/ccree/ssi_cipher.c | 17 ++--- drivers/staging/ccree/ssi_cipher.h | 17 ++--- drivers/staging/ccree/ssi_driver.c | 17 ++--- drivers/staging/ccree/ssi_driver.h | 17 ++--- drivers/staging/ccree/ssi_fips.c | 17 ++--- drivers/staging/ccree/ssi_fips.h | 17 ++--- drivers/staging/ccree/ssi_hash.c | 17 ++--- drivers/staging/ccree/ssi_hash.h | 17 ++--- drivers/staging/ccree/ssi_ivgen.c| 17 ++--- drivers/staging/ccree/ssi_ivgen.h| 17 ++--- drivers/staging/ccree/ssi_pm.c | 17 ++--- drivers/staging/ccree/ssi_pm.h | 17 ++--- drivers/staging/ccree/ssi_request_mgr.c | 17 ++--- drivers/staging/ccree/ssi_request_mgr.h | 17 ++--- drivers/staging/ccree/ssi_sram_mgr.c | 17 ++--- drivers/staging/ccree/ssi_sram_mgr.h | 17 ++--- 31 files changed, 62 insertions(+), 435 deletions(-) diff --git a/drivers/staging/ccree/Kconfig b/drivers/staging/ccree/Kconfig index 0b3092b..c94dfe8 100644 --- a/drivers/staging/ccree/Kconfig +++ b/drivers/staging/ccree/Kconfig @@ -1,3 +1,5 @@ +# SPDX-License-Identifier: GPL-2.0 + config CRYPTO_DEV_CCREE tristate "Support for ARM TrustZone CryptoCell C7XX family of Crypto accelerators" depends on CRYPTO && CRYPTO_HW && OF && HAS_DMA diff --git a/drivers/staging/ccree/Makefile b/drivers/staging/ccree/Makefile index ab9f073..bb47144 100644 --- a/drivers/staging/ccree/Makefile +++ b/drivers/staging/ccree/Makefile @@ -1,3 +1,5 @@ +# SPDX-License-Identifier: GPL-2.0 + obj-$(CONFIG_CRYPTO_DEV_CCREE) := ccree.o ccree-y := ssi_driver.o ssi_buffer_mgr.o ssi_request_mgr.o ssi_cipher.o ssi_hash.o ssi_aead.o ssi_ivgen.o ssi_sram_mgr.o ssi_pm.o ccree-$(CONFIG_CRYPTO_FIPS) += ssi_fips.o diff --git a/drivers/staging/ccree/cc_crypto_ctx.h b/drivers/staging/ccree/cc_crypto_ctx.h index 0e34d9a..02e14f3 100644 --- a/drivers/staging/ccree/cc_crypto_ctx.h +++ b/drivers/staging/ccree/cc_crypto_ctx.h @@ -1,18 +1,5 @@ -/* - * Copyright (C) 2012-2017 ARM Limited or its affiliates. - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, see <http://www.gnu.org/licenses/>. - */ +/* SPDX-License-Identifier: GPL-2.0 */ +/* Copyright (C) 2012-2018 ARM Limited or its affiliates. */ #ifndef _CC_CRYPTO_CTX_H_ #define _CC_CRYPTO_CTX_H_ diff --git a/drivers/staging/ccree/cc_debugfs.c b/drivers/staging/ccree/cc_debugfs.c index 662fa07..ab2c986 100644 --- a/drivers/staging/ccree/cc_debugfs.c +++ b/drivers/staging/ccree/cc_debugfs.c @@ -1,18 +1,5 @@ -/* - * Copyright (C) 2012-2017 ARM Limited or its affiliates. - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, see <http://www.gnu.org/licenses/>. - */ +// SPDX-License
[PATCH v3 02/27] staging: ccree: fold hash defs into queue defs
Fold the two remaining enum in hash defs into the queue defs
that are using them and delete the hash defs include file.
Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com>
---
drivers/staging/ccree/cc_hw_queue_defs.h | 13 +
drivers/staging/ccree/hash_defs.h| 23 ---
drivers/staging/ccree/ssi_driver.h | 1 -
3 files changed, 13 insertions(+), 24 deletions(-)
delete mode 100644 drivers/staging/ccree/hash_defs.h
diff --git a/drivers/staging/ccree/cc_hw_queue_defs.h
b/drivers/staging/ccree/cc_hw_queue_defs.h
index 52d32d1..bfc18b3 100644
--- a/drivers/staging/ccree/cc_hw_queue_defs.h
+++ b/drivers/staging/ccree/cc_hw_queue_defs.h
@@ -186,6 +186,19 @@ enum cc_hw_des_key_size {
END_OF_DES_KEYS = S32_MAX,
};
+enum cc_hash_conf_pad {
+ HASH_PADDING_DISABLED = 0,
+ HASH_PADDING_ENABLED = 1,
+ HASH_DIGEST_RESULT_LITTLE_ENDIAN = 2,
+ HASH_CONFIG1_PADDING_RESERVE32 = S32_MAX,
+};
+
+enum cc_hash_cipher_pad {
+ DO_NOT_PAD = 0,
+ DO_PAD = 1,
+ HASH_CIPHER_DO_PADDING_RESERVE32 = S32_MAX,
+};
+
/*/
/* Descriptor packing macros */
/*/
diff --git a/drivers/staging/ccree/hash_defs.h
b/drivers/staging/ccree/hash_defs.h
deleted file mode 100644
index 92d5c10..000
--- a/drivers/staging/ccree/hash_defs.h
+++ /dev/null
@@ -1,23 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-/* Copyright (C) 2012-2018 ARM Limited or its affiliates. */
-
-#ifndef _HASH_DEFS_H_
-#define _HASH_DEFS_H_
-
-#include "cc_crypto_ctx.h"
-
-enum cc_hash_conf_pad {
- HASH_PADDING_DISABLED = 0,
- HASH_PADDING_ENABLED = 1,
- HASH_DIGEST_RESULT_LITTLE_ENDIAN = 2,
- HASH_CONFIG1_PADDING_RESERVE32 = S32_MAX,
-};
-
-enum cc_hash_cipher_pad {
- DO_NOT_PAD = 0,
- DO_PAD = 1,
- HASH_CIPHER_DO_PADDING_RESERVE32 = S32_MAX,
-};
-
-#endif /*_HASH_DEFS_H_*/
-
diff --git a/drivers/staging/ccree/ssi_driver.h
b/drivers/staging/ccree/ssi_driver.h
index 7383a83..df805db 100644
--- a/drivers/staging/ccree/ssi_driver.h
+++ b/drivers/staging/ccree/ssi_driver.h
@@ -30,7 +30,6 @@
#include "dx_reg_common.h"
#define CC_SUPPORT_SHA CC_DEV_SHA_MAX
#include "cc_crypto_ctx.h"
-#include "hash_defs.h"
#include "cc_hw_queue_defs.h"
#include "ssi_sram_mgr.h"
--
2.7.4
