Re: [PATCH v5 2/2] hwrng: bcm2835: add reset support
On Thu, 2021-03-04 at 08:33 +0100, Álvaro Fernández Rojas wrote: > BCM6368 devices need to reset the in order to generate true random numbers. > This is what BCM6368 produces without a reset: > root@OpenWrt:/# cat /dev/hwrng | rngtest -c 1000 > rngtest 6.10 > Copyright (c) 2004 by Henrique de Moraes Holschuh > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > rngtest: starting FIPS tests... > rngtest: bits received from input: 2032 > rngtest: FIPS 140-2 successes: 0 > rngtest: FIPS 140-2 failures: 1000 > rngtest: FIPS 140-2(2001-10-10) Monobit: 2 > rngtest: FIPS 140-2(2001-10-10) Poker: 1000 > rngtest: FIPS 140-2(2001-10-10) Runs: 1000 > rngtest: FIPS 140-2(2001-10-10) Long run: 30 > rngtest: FIPS 140-2(2001-10-10) Continuous run: 0 > rngtest: input channel speed: (min=37.253; avg=320.827; max=635.783)Mibits/s > rngtest: FIPS tests speed: (min=12.141; avg=15.034; max=16.428)Mibits/s > rngtest: Program run time: 1336176 microseconds > cat: write error: Broken pipe > > Signed-off-by: Álvaro Fernández Rojas > --- > v5: remove reset_control_rearm(). Reviewed-by: Philipp Zabel regards Philipp
Re: [PATCH 05/10] crypto: keembay: ocs-hcu: Fix incorrectly named functions/structs
Hi Lee, Thanks for the patch. On Wed, 2021-03-03 at 14:34 +, Lee Jones wrote: > Fixes the following W=1 kernel build warning(s): > > drivers/crypto/keembay/ocs-hcu.c:107: warning: expecting prototype for > struct ocs_hcu_dma_list. Prototype was for struct ocs_hcu_dma_entry instead > drivers/crypto/keembay/ocs-hcu.c:127: warning: expecting prototype for > struct ocs_dma_list. Prototype was for struct ocs_hcu_dma_list instead I don't see the fix for this in the diff. Am I missing something? > drivers/crypto/keembay/ocs-hcu.c:610: warning: expecting prototype for > ocs_hcu_digest(). Prototype was for ocs_hcu_hash_update() instead > drivers/crypto/keembay/ocs-hcu.c:648: warning: expecting prototype for > ocs_hcu_hash_final(). Prototype was for ocs_hcu_hash_finup() instead > > Cc: Daniele Alessandrelli > Cc: Declan Murphy > Cc: Herbert Xu > Cc: "David S. Miller" > Cc: linux-crypto@vger.kernel.org > Signed-off-by: Lee Jones > --- > drivers/crypto/keembay/ocs-hcu.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/crypto/keembay/ocs-hcu.c > b/drivers/crypto/keembay/ocs-hcu.c > index 81eecacf603ad..d522757855fb0 100644 > --- a/drivers/crypto/keembay/ocs-hcu.c > +++ b/drivers/crypto/keembay/ocs-hcu.c > @@ -93,7 +93,7 @@ > #define OCS_HCU_WAIT_BUSY_TIMEOUT_US 100 > > /** > - * struct ocs_hcu_dma_list - An entry in an OCS DMA linked list. > + * struct ocs_hcu_dma_entry - An entry in an OCS DMA linked list. > * @src_addr: Source address of the data. > * @src_len: Length of data to be fetched. > * @nxt_desc: Next descriptor to fetch. > @@ -597,7 +597,7 @@ int ocs_hcu_hash_init(struct ocs_hcu_hash_ctx *ctx, enum > ocs_hcu_algo algo) > } > > /** > - * ocs_hcu_digest() - Perform a hashing iteration. > + * ocs_hcu_hash_update() - Perform a hashing iteration. > * @hcu_dev: The OCS HCU device to use. > * @ctx: The OCS HCU hashing context. > * @dma_list:The OCS DMA list mapping the input data to process. > @@ -632,7 +632,7 @@ int ocs_hcu_hash_update(struct ocs_hcu_dev *hcu_dev, > } > > /** > - * ocs_hcu_hash_final() - Update and finalize hash computation. > + * ocs_hcu_hash_finup() - Update and finalize hash computation. > * @hcu_dev: The OCS HCU device to use. > * @ctx: The OCS HCU hashing context. > * @dma_list:The OCS DMA list mapping the input data to process.
Re: [PATCH v3 1/2] dt-bindings: rng: bcm2835: document reset support
Hi Alvaro, On Tue, 2021-02-23 at 18:00 +0100, Álvaro Fernández Rojas wrote: > Some devices may need to perform a reset before using the RNG, such as the > BCM6368. > > Signed-off-by: Álvaro Fernández Rojas > --- > v3: make resets required if brcm,bcm6368-rng. > v2: document reset support. > > .../devicetree/bindings/rng/brcm,bcm2835.yaml | 17 + > 1 file changed, 17 insertions(+) > > diff --git a/Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml > b/Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml > index c147900f9041..11c23e1f6988 100644 > --- a/Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml > +++ b/Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml > @@ -37,6 +37,21 @@ required: > > > additionalProperties: false I can't claim I fully understand all the meta stuff in shemas, so I generally just follow the patterns already available out there. That said, shoudln't this be at the end, just before the examples? Maybe the cause of that odd warning you got there? > +if: > + properties: > +compatible: > + enum: > +- brcm,bcm6368-rng > +then: > + properties: > +resets: > + maxItems: 1 > + required: > +- resets I belive you can't really make a property required when the bindings for 'brcm,bcm6368-rng' were already defined. This will break the schema for those otherwise correct devicetrees. > +else: > + properties: > +resets: false > + > examples: > - | > rng@7e104000 { > @@ -58,4 +73,6 @@ examples: > > > clocks = <&periph_clk 18>; > clock-names = "ipsec"; > + > +resets = <&periph_rst 4>; > }; Regards, Nicolas signature.asc Description: This is a digitally signed message part
Re: [PATCH v5 1/2] dt-bindings: rng: bcm2835: document reset support
Sorry Alvaro I missed you sent a v5 already. See my comments in v3. Regards, Nicolas On Thu, 2021-03-04 at 08:33 +0100, Álvaro Fernández Rojas wrote: > Some devices may need to perform a reset before using the RNG, such as the > BCM6368. > > Signed-off-by: Álvaro Fernández Rojas > --- > v5: no changes. > v4: pass dt_binding_check. > v3: make resets required if brcm,bcm6368-rng. > v2: document reset support. > > .../devicetree/bindings/rng/brcm,bcm2835.yaml | 17 + > 1 file changed, 17 insertions(+) > > diff --git a/Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml > b/Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml > index c147900f9041..11c23e1f6988 100644 > --- a/Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml > +++ b/Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml > @@ -37,6 +37,21 @@ required: > > > additionalProperties: false > > > +if: > + properties: > +compatible: > + enum: > +- brcm,bcm6368-rng > +then: > + properties: > +resets: > + maxItems: 1 > + required: > +- resets > +else: > + properties: > +resets: false > + > examples: > - | > rng@7e104000 { > @@ -58,4 +73,6 @@ examples: > > > clocks = <&periph_clk 18>; > clock-names = "ipsec"; > + > +resets = <&periph_rst 4>; > }; signature.asc Description: This is a digitally signed message part
Re: [PATCH v3 1/2] dt-bindings: rng: bcm2835: document reset support
> El 4 mar 2021, a las 13:07, Nicolas Saenz Julienne > escribió: > > Hi Alvaro, > > On Tue, 2021-02-23 at 18:00 +0100, Álvaro Fernández Rojas wrote: >> Some devices may need to perform a reset before using the RNG, such as the >> BCM6368. >> >> Signed-off-by: Álvaro Fernández Rojas >> --- >> v3: make resets required if brcm,bcm6368-rng. >> v2: document reset support. >> >> .../devicetree/bindings/rng/brcm,bcm2835.yaml | 17 + >> 1 file changed, 17 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml >> b/Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml >> index c147900f9041..11c23e1f6988 100644 >> --- a/Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml >> +++ b/Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml >> @@ -37,6 +37,21 @@ required: >> >> >> additionalProperties: false > > I can't claim I fully understand all the meta stuff in shemas, so I generally > just follow the patterns already available out there. Well, that makes two of us :). > That said, shoudln't this be at the end, just before the examples? I don’t know but I can move it there ¯\_(ツ)_/¯ > Maybe the cause of that odd warning > you got there? Which odd warning? I don’t get any warnings when running (or at least warnings related to rig, because I get warnings related to other yamls): make dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml > >> +if: >> + properties: >> +compatible: >> + enum: >> +- brcm,bcm6368-rng >> +then: >> + properties: >> +resets: >> + maxItems: 1 >> + required: >> +- resets > > I belive you can't really make a property required when the bindings for > 'brcm,bcm6368-rng' were already defined. This will break the schema for those > otherwise correct devicetrees. Why not? Wouldn’t just be required for brcm,bcm6368-rng? Anyway, I can omit this, since it would be the same for clocks and those aren’t required either. > >> +else: >> + properties: >> +resets: false >> + >> examples: >>- | >> rng@7e104000 { >> @@ -58,4 +73,6 @@ examples: >> >> >> clocks = <&periph_clk 18>; >> clock-names = "ipsec"; >> + >> +resets = <&periph_rst 4>; >> }; > > Regards, > Nicolas Best regards, Álvaro.
Re: [PATCH v3 1/2] dt-bindings: rng: bcm2835: document reset support
On Thu, 2021-03-04 at 13:18 +0100, Álvaro Fernández Rojas wrote: > > > El 4 mar 2021, a las 13:07, Nicolas Saenz Julienne > > escribió: > > > > Hi Alvaro, > > > > On Tue, 2021-02-23 at 18:00 +0100, Álvaro Fernández Rojas wrote: > > > Some devices may need to perform a reset before using the RNG, such as the > > > BCM6368. > > > > > > Signed-off-by: Álvaro Fernández Rojas > > > --- > > > v3: make resets required if brcm,bcm6368-rng. > > > v2: document reset support. > > > > > > .../devicetree/bindings/rng/brcm,bcm2835.yaml | 17 + > > > 1 file changed, 17 insertions(+) > > > > > > diff --git a/Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml > > > b/Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml > > > index c147900f9041..11c23e1f6988 100644 > > > --- a/Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml > > > +++ b/Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml > > > @@ -37,6 +37,21 @@ required: > > > > > > > > > > > > additionalProperties: false > > > > I can't claim I fully understand all the meta stuff in shemas, so I > > generally > > just follow the patterns already available out there. > > Well, that makes two of us :). > > > That said, shoudln't this be at the end, just before the examples? > > I don’t know but I can move it there ¯\_(ツ)_/¯ Yes please do. See commit 7f464532b05 ("dt-bindings: Add missing 'additionalProperties: false'") which expands on why it is needed, and why it should be at the end. > > Maybe the cause of that odd warning > > you got there? > > Which odd warning? The one pointed out by Rob Herring's script, which I can reproduce too BTW. On the other hand I can't really tell what's wrong right away. > I don’t get any warnings when running (or at least warnings related to rig, > because I get warnings related to other yamls): > make dt_binding_check > DT_SCHEMA_FILES=Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml > > > > > > +if: > > > + properties: > > > +compatible: > > > + enum: > > > +- brcm,bcm6368-rng > > > +then: > > > + properties: > > > +resets: > > > + maxItems: 1 > > > + required: > > > +- resets > > > > I belive you can't really make a property required when the bindings for > > 'brcm,bcm6368-rng' were already defined. This will break the schema for > > those > > otherwise correct devicetrees. > > Why not? > Wouldn’t just be required for brcm,bcm6368-rng? Well, do all 'brcm,bcm6368-rng' users absolutely need the reset controller? If so, the original binding is wrong, which should be mentioned and a 'Fixes:' tag should be added to the commit message. Otherwise, the requirement is optional. Regards, Nicolas signature.asc Description: This is a digitally signed message part
Re: [PATCH] crypto: qat - fix use of 'dma_map_single'
Hi Hui, url: https://github.com/0day-ci/linux/commits/Hui-Tang/crypto-qat-fix-use-of-dma_map_single/20210301-114717 base: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master config: i386-randconfig-m021-20210304 (attached as .config) compiler: gcc-9 (Debian 9.3.0-22) 9.3.0 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot Reported-by: Dan Carpenter smatch warnings: drivers/crypto/qat/qat_common/qat_algs.c:809 qat_alg_sgl_to_bufl() error: uninitialized symbol 'blp'. vim +/blp +809 drivers/crypto/qat/qat_common/qat_algs.c d370cec3219490 Tadeusz Struk 2014-06-05 711 static int qat_alg_sgl_to_bufl(struct qat_crypto_instance *inst, d370cec3219490 Tadeusz Struk 2014-06-05 712 struct scatterlist *sgl, e19ab1211d2848 Herbert Xu 2015-07-30 713 struct scatterlist *sglout, d370cec3219490 Tadeusz Struk 2014-06-05 714 struct qat_crypto_request *qat_req) d370cec3219490 Tadeusz Struk 2014-06-05 715 { d370cec3219490 Tadeusz Struk 2014-06-05 716 struct device *dev = &GET_DEV(inst->accel_dev); e19ab1211d2848 Herbert Xu 2015-07-30 717 int i, sg_nctr = 0; e19ab1211d2848 Herbert Xu 2015-07-30 718 int n = sg_nents(sgl); d370cec3219490 Tadeusz Struk 2014-06-05 719 struct qat_alg_buf_list *bufl; d370cec3219490 Tadeusz Struk 2014-06-05 720 struct qat_alg_buf_list *buflout = NULL; d370cec3219490 Tadeusz Struk 2014-06-05 721 dma_addr_t blp; ^^ d370cec3219490 Tadeusz Struk 2014-06-05 722 dma_addr_t bloutp = 0; d370cec3219490 Tadeusz Struk 2014-06-05 723 struct scatterlist *sg; 1793d1aba19415 Gustavo A. R. Silva 2019-06-06 724 size_t sz_out, sz = struct_size(bufl, bufers, n + 1); d370cec3219490 Tadeusz Struk 2014-06-05 725 d370cec3219490 Tadeusz Struk 2014-06-05 726 if (unlikely(!n)) d370cec3219490 Tadeusz Struk 2014-06-05 727 return -EINVAL; d370cec3219490 Tadeusz Struk 2014-06-05 728 82f82504b8f5f1 Tadeusz Struk 2014-12-08 729 bufl = kzalloc_node(sz, GFP_ATOMIC, 09adc8789c4e89 Tadeusz Struk 2014-10-13 730 dev_to_node(&GET_DEV(inst->accel_dev))); d370cec3219490 Tadeusz Struk 2014-06-05 731 if (unlikely(!bufl)) d370cec3219490 Tadeusz Struk 2014-06-05 732 return -ENOMEM; d370cec3219490 Tadeusz Struk 2014-06-05 733 d370cec3219490 Tadeusz Struk 2014-06-05 734 for_each_sg(sgl, sg, n, i) { e19ab1211d2848 Herbert Xu 2015-07-30 735 int y = sg_nctr; 82f82504b8f5f1 Tadeusz Struk 2014-12-08 736 82f82504b8f5f1 Tadeusz Struk 2014-12-08 737 if (!sg->length) 82f82504b8f5f1 Tadeusz Struk 2014-12-08 738 continue; d65071ecde1ed1 Tadeusz Struk 2014-06-24 739 d370cec3219490 Tadeusz Struk 2014-06-05 740 bufl->bufers[y].addr = dma_map_single(dev, sg_virt(sg), d370cec3219490 Tadeusz Struk 2014-06-05 741 sg->length, d370cec3219490 Tadeusz Struk 2014-06-05 742 DMA_BIDIRECTIONAL); d370cec3219490 Tadeusz Struk 2014-06-05 743 bufl->bufers[y].len = sg->length; d370cec3219490 Tadeusz Struk 2014-06-05 744 if (unlikely(dma_mapping_error(dev, bufl->bufers[y].addr))) 72eed063767e13 Arnd Bergmann 2017-06-22 745 goto err_in; "blp" uninitialized at this goto. 82f82504b8f5f1 Tadeusz Struk 2014-12-08 746 sg_nctr++; d370cec3219490 Tadeusz Struk 2014-06-05 747 } e19ab1211d2848 Herbert Xu 2015-07-30 748 bufl->num_bufs = sg_nctr; 54bc41cf4d0517 Hui Tang2021-03-01 749 blp = dma_map_single(dev, bufl, sz, DMA_TO_DEVICE); ^^ Initialized here. 54bc41cf4d0517 Hui Tang2021-03-01 750 if (unlikely(dma_mapping_error(dev, blp))) 54bc41cf4d0517 Hui Tang2021-03-01 751 goto err_in; d370cec3219490 Tadeusz Struk 2014-06-05 752 qat_req->buf.bl = bufl; d370cec3219490 Tadeusz Struk 2014-06-05 753 qat_req->buf.blp = blp; d370cec3219490 Tadeusz Struk 2014-06-05 754 qat_req->buf.sz = sz; d370cec3219490 Tadeusz Struk 2014-06-05 755 /* Handle out of place operation */ d370cec3219490 Tadeusz Struk 2014-06-05 756 if (sgl != sglout) { d370cec3219490 Tadeusz Struk 2014-06-05 757 struct qat_alg_buf *bufers; d370cec3219490 Tadeusz Struk 2014
Re: [PATCH v9 6/9] crypto: Add NIST P384 curve parameters
On 3/4/21 12:28 AM, Herbert Xu wrote: On Thu, Feb 25, 2021 at 11:07:59AM -0500, Stefan Berger wrote: From: Saulo Alessandre * crypto/ecc_curve_defs.h - add nist_p384 params * include/crypto/ecdh.h - add ECC_CURVE_NIST_P384 Signed-off-by: Saulo Alessandre Tested-by: Stefan Berger --- crypto/ecc_curve_defs.h | 32 include/crypto/ecdh.h | 1 + 2 files changed, 33 insertions(+) Can you reorder the patches so that the crypto patches come first and then I can apply them? Yes, sounds good. Are you going to take the other patches as well, except for maybe 9/9, which depends on Nayan's patch series. Mimi suggested to me to ask you whether you could create a topic branch where we can apply other patches to, such as Nayna's? The NIST P384 patch temporarily introduces this warning, which goes away when the immediately following patch (current 7/9) is applied. Is this an issue or should I squash Saulo's patches or put the top hunk from 7/9 into 6/9? In file included from crypto/ecc.c:38: crypto/ecc_curve_defs.h:76:25: warning: ?nist_p384? defined but not used [-Wunused-variable] 76 | static struct ecc_curve nist_p384 = { | ^ Stefan Thanks,
Re: [PATCH v3 1/2] dt-bindings: rng: bcm2835: document reset support
Hi Nicolas, > El 4 mar 2021, a las 14:30, Nicolas Saenz Julienne > escribió: > > On Thu, 2021-03-04 at 13:18 +0100, Álvaro Fernández Rojas wrote: >> >>> El 4 mar 2021, a las 13:07, Nicolas Saenz Julienne >>> escribió: >>> >>> Hi Alvaro, >>> >>> On Tue, 2021-02-23 at 18:00 +0100, Álvaro Fernández Rojas wrote: Some devices may need to perform a reset before using the RNG, such as the BCM6368. Signed-off-by: Álvaro Fernández Rojas --- v3: make resets required if brcm,bcm6368-rng. v2: document reset support. .../devicetree/bindings/rng/brcm,bcm2835.yaml | 17 + 1 file changed, 17 insertions(+) diff --git a/Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml b/Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml index c147900f9041..11c23e1f6988 100644 --- a/Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml +++ b/Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml @@ -37,6 +37,21 @@ required: additionalProperties: false >>> >>> I can't claim I fully understand all the meta stuff in shemas, so I >>> generally >>> just follow the patterns already available out there. >> >> Well, that makes two of us :). >> >>> That said, shoudln't this be at the end, just before the examples? >> >> I don’t know but I can move it there ¯\_(ツ)_/¯ > > Yes please do. See commit 7f464532b05 ("dt-bindings: Add missing > 'additionalProperties: false'") which expands on why it is needed, and why it > should be at the end. > >>> Maybe the cause of that odd warning >>> you got there? >> >> Which odd warning? > > The one pointed out by Rob Herring's script, which I can reproduce too BTW. On > the other hand I can't really tell what's wrong right away. Well, I can’t reproduce that locally and I don’t know what’s wrong either, I think that the best option is to remove the full if block. > >> I don’t get any warnings when running (or at least warnings related to rig, >> because I get warnings related to other yamls): >> make dt_binding_check >> DT_SCHEMA_FILES=Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml >> >>> +if: + properties: +compatible: + enum: +- brcm,bcm6368-rng +then: + properties: +resets: + maxItems: 1 + required: +- resets >>> >>> I belive you can't really make a property required when the bindings for >>> 'brcm,bcm6368-rng' were already defined. This will break the schema for >>> those >>> otherwise correct devicetrees. >> >> Why not? >> Wouldn’t just be required for brcm,bcm6368-rng? > > Well, do all 'brcm,bcm6368-rng' users absolutely need the reset controller? If > so, the original binding is wrong, which should be mentioned and a 'Fixes:' > tag > should be added to the commit message. Otherwise, the requirement is optional. I’m not sure about this... > > Regards, > Nicolas Best regards, Álvaro.
Re: [PATCH] hwrng: bcm2835: set quality to 1000
On Wed, 2021-03-03 at 10:29 +0100, Álvaro Fernández Rojas wrote: > Hi Herbert, > > > El 3 mar 2021, a las 10:20, Herbert Xu > > escribió: > > > > On Sat, Feb 20, 2021 at 08:12:45PM +0100, Álvaro Fernández Rojas wrote: > > > > > > I ran rngtest and this is what I got: > > > > This is meaningless except for sources that have not been whitened. > > > > Your justification needs to be based on what the hardware does or > > is documented to do. > > Ok, so I guess that we’re never setting that value to anything since there’s > no public documentation about that ¯\_(ツ)_/¯. @Florian, is there a way you might be able to get the official value? Regards, Nicolas signature.asc Description: This is a digitally signed message part
Re: CAAM: kernel BUG at drivers/crypto/caam/jr.c:230! (and dma-coherent query)
On 2021-03-03 16:40, Horia Geantă wrote: On 3/3/2021 4:57 PM, Sascha Hauer wrote: On Wed, Mar 03, 2021 at 12:26:32PM +0200, Horia Geantă wrote: Adding some people in the loop, maybe they could help in understanding why lack of "dma-coherent" property for a HW-coherent device could lead to unexpected / strange side effects. On 3/1/2021 5:22 PM, Sascha Hauer wrote: Hi All, I am on a Layerscape LS1046a using Linux-5.11. The CAAM driver sometimes crashes during the run-time self tests with: kernel BUG at drivers/crypto/caam/jr.c:247! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.11.0-20210225-3-00039-g434215968816-dirty #12 Hardware name: TQ TQMLS1046A SoM on Arkona AT1130 (C300) board (DT) pstate: 6005 (nZCv daif -PAN -UAO -TCO BTYPE=--) pc : caam_jr_dequeue+0x98/0x57c lr : caam_jr_dequeue+0x98/0x57c sp : 800010003d50 x29: 800010003d50 x28: 8000118d4000 x27: 8000118d4328 x26: 01f0 x25: 0008022be480 x24: 0008022c6410 x23: 01f1 x22: 8000118d4329 x21: 4d80 x20: 01f1 x19: 0001 x18: 0020 x17: x16: 0015 x15: 800011690230 x14: 2e2e2e2e2e2e2e2e x13: 2e2e2e2e2e2e2020 x12: 3030303030303030 x11: 800011700a38 x10: f000 x9 : 8000100ada30 x8 : 8000116a8a38 x7 : 0001 x6 : x5 : x4 : x3 : x2 : x1 : x0 : 1800 Call trace: caam_jr_dequeue+0x98/0x57c tasklet_action_common.constprop.0+0x164/0x18c tasklet_action+0x44/0x54 __do_softirq+0x160/0x454 __irq_exit_rcu+0x164/0x16c irq_exit+0x1c/0x30 __handle_domain_irq+0xc0/0x13c gic_handle_irq+0x5c/0xf0 el1_irq+0xb4/0x180 arch_cpu_idle+0x18/0x30 default_idle_call+0x3c/0x1c0 do_idle+0x23c/0x274 cpu_startup_entry+0x34/0x70 rest_init+0xdc/0xec arch_call_rest_init+0x1c/0x28 start_kernel+0x4ac/0x4e4 Code: 91392021 912c2000 d377d8c6 97f24d96 (d421) The driver iterates over the descriptors in the output ring and matches them with the ones it has previously queued. If it doesn't find a matching descriptor it complains with the BUG_ON() seen above. What I see sometimes is that the address in the output ring is 0x0, the job status in this case is 0x4006 (meaning DECO Invalid KEY command). It seems that the CAAM doesn't write the descriptor address to the output ring at least in some error cases. When we don't have the descriptor address of the failed descriptor we have no way to find it in the list of queued descriptors, thus we also can't find the callback for that descriptor. This looks very unfortunate, anyone else seen this or has an idea what to do about it? I haven't investigated yet which job actually fails and why. Of course that would be my ultimate goal to find that out. This looks very similar to an earlier report from Greg. He confirmed that adding "dma-coherent" property to the "crypto" DT node fixes the issue: https://lore.kernel.org/linux-crypto/74f664f5-5433-d322-4789-3c78bdb81...@kernel.org Patch rebased on v5.11 is at the bottom. Does it work for you too? Indeed this seems to solve it for me as well, you can add my Tested-by: Sascha Hauer Thanks! I'll append the tag to the formally submitted patch. However, there seem to be two problems: First that "DECO Invalid KEY command" actually occurs and second that the deqeueue code currently can't handle a NULL pointer in the output ring. Currently the dequeue code BUGs not only for "NULL pointer", but for any IOVA in the output ring that is not matched with an entry in the "shadow" (SW) ring. Here the BUG_ON() should be replaced with WARN_ON since not finding a match means driver can't go to the "SW context" and eventually call complete() to wake up the crypto API user. In many cases the user relies on crypto_wait_req(), which does not time out and is not killable. Do you think that the occurence of a NULL pointer is also a coherency issue? I strongly believe there's a single problem because the issue goes away when the patch is applied, even though I haven't figured out what is the exact place / data structure that gets corrupted. One theory is that corruption occurs in the input ring: -CPU sets up correctly the input ring entry -device doesn't see the "fresh" data, reading 0x0 for the descriptor address -device reads the descriptor commands from address 0x0 and issues "DECO invalid KEY command" (note that KEY command opcode is b'0, so reading all zeros from address 0x0 would lead to this error) But then the input & output rings are allocated using dma_alloc_coherent(), so I'll need to check if lack of "dma-coherent" DT property has the same effect on consistent DMA mappings as on streaming DMA mappings. It certainly can, at least on arm64 where coherent buffers are remapped in vmalloc rather than changing the linea
Re: [PATCH 0/7] Add support for AEAD algorithms in Qualcomm Crypto Engine driver
On Thu, 4 Mar 2021 at 00:30, Herbert Xu wrote: > > On Thu, Feb 25, 2021 at 01:27:09PM -0500, Thara Gopinath wrote: > > Enable support for AEAD algorithms in Qualcomm CE driver. The first three > > patches in this series are cleanups and add a few missing pieces required > > to add support for AEAD algorithms. Patch 4 introduces supported AEAD > > transformations on Qualcomm CE. Patches 5 and 6 implements the h/w > > infrastructure needed to enable and run the AEAD transformations on > > Qualcomm CE. Patch 7 adds support to queue fallback algorithms in case of > > unsupported special inputs. > > > > This series is dependant on https://lkml.org/lkml/2021/2/11/1052. > > Did this patch series pass the fuzz tests? Hi Herbert, Yes it did. The last patch adds fallback for unsupported cases and this will make it pass the fuzz tests. > > Thanks, > -- > Email: Herbert Xu > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- Warm Regards Thara
Re: [PATCH v3 1/2] dt-bindings: rng: bcm2835: document reset support
On Thu, Mar 4, 2021 at 6:07 AM Nicolas Saenz Julienne wrote: > > Hi Alvaro, > > On Tue, 2021-02-23 at 18:00 +0100, Álvaro Fernández Rojas wrote: > > Some devices may need to perform a reset before using the RNG, such as the > > BCM6368. > > > > Signed-off-by: Álvaro Fernández Rojas > > --- > > v3: make resets required if brcm,bcm6368-rng. > > v2: document reset support. > > > > .../devicetree/bindings/rng/brcm,bcm2835.yaml | 17 + > > 1 file changed, 17 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml > > b/Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml > > index c147900f9041..11c23e1f6988 100644 > > --- a/Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml > > +++ b/Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml > > @@ -37,6 +37,21 @@ required: > > > > > > additionalProperties: false > > I can't claim I fully understand all the meta stuff in shemas, so I generally > just follow the patterns already available out there. That said, shoudln't > this > be at the end, just before the examples? Maybe the cause of that odd warning > you got there? Yes, 'resets' needs to be defined under 'properties' as additionalProperties can't 'see' into if/then schemas. The top level needs to define everything and then if/then schema just add additional constraints. > > > +if: > > + properties: > > +compatible: > > + enum: > > +- brcm,bcm6368-rng > > +then: > > + properties: > > +resets: > > + maxItems: 1 > > + required: > > +- resets > > I belive you can't really make a property required when the bindings for > 'brcm,bcm6368-rng' were already defined. This will break the schema for those > otherwise correct devicetrees. Right, unless not having the property meant the device never would have worked. Rob
Re: [PATCH v5 1/2] dt-bindings: rng: bcm2835: document reset support
On Thu, 04 Mar 2021 08:33:07 +0100, Ãlvaro Fernández Rojas wrote: > Some devices may need to perform a reset before using the RNG, such as the > BCM6368. > > Signed-off-by: Ãlvaro Fernández Rojas > --- > v5: no changes. > v4: pass dt_binding_check. > v3: make resets required if brcm,bcm6368-rng. > v2: document reset support. > > .../devicetree/bindings/rng/brcm,bcm2835.yaml | 17 + > 1 file changed, 17 insertions(+) > My bot found errors running 'make dt_binding_check' on your patch: yamllint warnings/errors: dtschema/dtc warnings/errors: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/rng/brcm,bcm2835.example.dt.yaml: rng@10004180: 'resets' does not match any of the regexes: 'pinctrl-[0-9]+' From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml See https://patchwork.ozlabs.org/patch/1447144 This check can fail if there are any dependencies. The base for a patch series is generally the most recent rc1. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit.
Re: [PATCH] hwrng: bcm2835: set quality to 1000
On 3/4/21 7:11 AM, Nicolas Saenz Julienne wrote: > On Wed, 2021-03-03 at 10:29 +0100, Álvaro Fernández Rojas wrote: >> Hi Herbert, >> >>> El 3 mar 2021, a las 10:20, Herbert Xu >>> escribió: >>> >>> On Sat, Feb 20, 2021 at 08:12:45PM +0100, Álvaro Fernández Rojas wrote: I ran rngtest and this is what I got: >>> >>> This is meaningless except for sources that have not been whitened. >>> >>> Your justification needs to be based on what the hardware does or >>> is documented to do. >> >> Ok, so I guess that we’re never setting that value to anything since there’s >> no public documentation about that ¯\_(ツ)_/¯. > > @Florian, is there a way you might be able to get the official value? I will be looking into the documentation this weekend and let you know whether we can change the driver's quality accordingly. -- Florian
Re: [PATCH v9 6/9] crypto: Add NIST P384 curve parameters
On Thu, Mar 04, 2021 at 08:59:36AM -0500, Stefan Berger wrote: > > Are you going to take the other patches as well, except for maybe 9/9, which > depends on Nayan's patch series. Mimi suggested to me to ask you whether you > could create a topic branch where we can apply other patches to, such as > Nayna's? Yes I can do a topic branch. Please let me know which patches I should take when you resubmit. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: ccp - Don't initialize SEV support without the SEV feature
On 3/3/21 4:31 PM, Tom Lendacky wrote: > From: Tom Lendacky > > If SEV has been disabled (e.g. through BIOS), the driver probe will still > issue SEV firmware commands. The SEV INIT firmware command will return an > error in this situation, but the error code is a general error code that > doesn't highlight the exact reason. > > Add a check for X86_FEATURE_SEV in sev_dev_init() and emit a meaningful > message and skip attempting to initialize the SEV firmware if the feature > is not enabled. Since building the SEV code is dependent on X86_64, adding > the check won't cause any build problems. > > Cc: John Allen > Cc: Brijesh Singh > Signed-off-by: Tom Lendacky Reviewed-By: Brijesh Singh > --- > drivers/crypto/ccp/sev-dev.c | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c > index 476113e12489..b9fc8d7aca73 100644 > --- a/drivers/crypto/ccp/sev-dev.c > +++ b/drivers/crypto/ccp/sev-dev.c > @@ -21,6 +21,7 @@ > #include > #include > #include > +#include > > #include > > @@ -971,6 +972,11 @@ int sev_dev_init(struct psp_device *psp) > struct sev_device *sev; > int ret = -ENOMEM; > > + if (!boot_cpu_has(X86_FEATURE_SEV)) { > + dev_info_once(dev, "SEV: memory encryption not enabled by > BIOS\n"); > + return 0; > + } > + > sev = devm_kzalloc(dev, sizeof(*sev), GFP_KERNEL); > if (!sev) > goto e_err;
[PATCH v10 0/9] Add support for x509 certs with NIST P384/256/192 keys
From: Stefan Berger This series of patches adds support for x509 certificates signed by a CA that uses NIST P384, P256 or P192 keys for signing. It also adds support for certificates where the public key is one of this type of a key. The math for ECDSA signature verification is also added as well as the math for fast mmod operation for NIST P384. Since self-signed certificates are verified upon loading, the following script can be used for testing of NIST P256 keys: k=$(keyctl newring test @u) while :; do for hash in sha1 sha224 sha256 sha384 sha512; do openssl req \ -x509 \ -${hash} \ -newkey ec \ -pkeyopt ec_paramgen_curve:prime256v1 \ -keyout key.pem \ -days 365 \ -subj '/CN=test' \ -nodes \ -outform der \ -out cert.der keyctl padd asymmetric testkey $k < cert.der if [ $? -ne 0 ]; then echo "ERROR" exit 1 fi done done Ecdsa support also works with restricted keyrings where an RSA key is used to sign a NIST P384/256/192 key. Scripts for testing are here: https://github.com/stefanberger/eckey-testing The ECDSA signature verification will be used by IMA Appraisal where ECDSA file signatures stored in RPM packages will use substantially less space than if RSA signatures were to be used. Further, a patch is added that allows kernel modules to be signed with a NIST p384 key. Stefan and Saulo v9->v10: - rearranged order of patches to have crypto patches first - moved hunk from patch 3 to patch 2 to avoid compilation warning due to unused symbol v8->v9: - Appended Saulo's patches - Appended patch to support kernel modules signed with NIST p384 key. This patch requires Nayna's series here: https://lkml.org/lkml/2021/2/18/856 v7->v8: - patch 3/4: Do not determine key algo using parse_OID in public_key.c but do this when parsing the certificate. This addresses an issue with certain build configurations where OID_REGISTRY is not available as 'Reported-by: kernel test robot '. v6->v7: - Moved some OID defintions to patch 1 for bisectability - Applied R-b's v5->v6: - moved ecdsa code into its own module ecdsa_generic built from ecdsa.c - added script-generated test vectors for NIST P256 & P192 and all hashes - parsing of OID that contain header with new parse_oid() v4->v5: - registering crypto support under names ecdsa-nist-p256/p192 following Hubert Xu's suggestion in other thread - appended IMA ECDSA support patch v3->v4: - split off of ecdsa crypto part; registering akcipher as "ecdsa" and deriving used curve from digits in parsed key v2->v3: - patch 2 now includes linux/scatterlist.h v1->v2: - using faster vli_sub rather than newly added vli_mod_fast to 'reduce' result - rearranged switch statements to follow after RSA - 3rd patch from 1st posting is now 1st patch Saulo Alessandre (4): crypto: Add NIST P384 curve parameters crypto: Add math to support fast NIST P384 ecdsa: Register NIST P384 and extend test suite x509: Add OID for NIST P384 and extend parser for it Stefan Berger (5): crypto: Add support for ECDSA signature verification x509: Detect sm2 keys by their parameters OID x509: Add support for parsing x509 certs with ECDSA keys ima: Support EC keys for signature verification certs: Add support for using elliptic curve keys for signing modules certs/Kconfig | 22 ++ certs/Makefile| 14 + crypto/Kconfig| 10 + crypto/Makefile | 6 + crypto/asymmetric_keys/pkcs7_parser.c | 4 + crypto/asymmetric_keys/public_key.c | 4 +- crypto/asymmetric_keys/x509_cert_parser.c | 49 ++- crypto/asymmetric_keys/x509_public_key.c | 4 +- crypto/ecc.c | 281 +- crypto/ecc.h | 31 +- crypto/ecc_curve_defs.h | 32 ++ crypto/ecdsa.c| 400 crypto/ecdsasignature.asn1| 4 + crypto/testmgr.c | 18 + crypto/testmgr.h | 424 ++ include/crypto/ecdh.h | 1 + include/keys/asymmetric-type.h| 6 + include/linux/oid_registry.h | 10 +- lib/oid_registry.c| 13 + security/integrity/digsig_asymmetric.c| 30 +- 20 files changed, 1256 insertions(+), 107 deletions(-) create mode 100644 crypto/ecdsa.c create mode 100644 crypto/ecdsasignature.asn1 -- 2.29.2
[PATCH v10 5/9] x509: Detect sm2 keys by their parameters OID
From: Stefan Berger Detect whether a key is an sm2 type of key by its OID in the parameters array rather than assuming that everything under OID_id_ecPublicKey is sm2, which is not the case. Cc: David Howells Cc: keyri...@vger.kernel.org Signed-off-by: Stefan Berger Reviewed-by: Tianjia Zhang --- crypto/asymmetric_keys/x509_cert_parser.c | 12 +++- include/linux/oid_registry.h | 1 + lib/oid_registry.c| 13 + 3 files changed, 25 insertions(+), 1 deletion(-) diff --git a/crypto/asymmetric_keys/x509_cert_parser.c b/crypto/asymmetric_keys/x509_cert_parser.c index 52c9b455fc7d..1621ceaf5c95 100644 --- a/crypto/asymmetric_keys/x509_cert_parser.c +++ b/crypto/asymmetric_keys/x509_cert_parser.c @@ -459,6 +459,7 @@ int x509_extract_key_data(void *context, size_t hdrlen, const void *value, size_t vlen) { struct x509_parse_context *ctx = context; + enum OID oid; ctx->key_algo = ctx->last_oid; switch (ctx->last_oid) { @@ -470,7 +471,16 @@ int x509_extract_key_data(void *context, size_t hdrlen, ctx->cert->pub->pkey_algo = "ecrdsa"; break; case OID_id_ecPublicKey: - ctx->cert->pub->pkey_algo = "sm2"; + if (parse_OID(ctx->params, ctx->params_size, &oid) != 0) + return -EBADMSG; + + switch (oid) { + case OID_sm2: + ctx->cert->pub->pkey_algo = "sm2"; + break; + default: + return -ENOPKG; + } break; default: return -ENOPKG; diff --git a/include/linux/oid_registry.h b/include/linux/oid_registry.h index b504e2f36b25..f32d91895e4d 100644 --- a/include/linux/oid_registry.h +++ b/include/linux/oid_registry.h @@ -121,6 +121,7 @@ enum OID { }; extern enum OID look_up_OID(const void *data, size_t datasize); +extern int parse_OID(const void *data, size_t datasize, enum OID *oid); extern int sprint_oid(const void *, size_t, char *, size_t); extern int sprint_OID(enum OID, char *, size_t); diff --git a/lib/oid_registry.c b/lib/oid_registry.c index f7ad43f28579..508e0b34b5f0 100644 --- a/lib/oid_registry.c +++ b/lib/oid_registry.c @@ -11,6 +11,7 @@ #include #include #include +#include #include "oid_registry_data.c" MODULE_DESCRIPTION("OID Registry"); @@ -92,6 +93,18 @@ enum OID look_up_OID(const void *data, size_t datasize) } EXPORT_SYMBOL_GPL(look_up_OID); +int parse_OID(const void *data, size_t datasize, enum OID *oid) +{ + const unsigned char *v = data; + + if (datasize < 2 || v[0] != ASN1_OID || v[1] != datasize - 2) + return -EBADMSG; + + *oid = look_up_OID(data + 2, datasize - 2); + return 0; +} +EXPORT_SYMBOL_GPL(parse_OID); + /* * sprint_OID - Print an Object Identifier into a buffer * @data: The encoded OID to print -- 2.29.2
[PATCH v10 6/9] x509: Add support for parsing x509 certs with ECDSA keys
From: Stefan Berger This patch adds support for parsing of x509 certificates that contain ECDSA keys, such as NIST P256, that have been signed by a CA using any of the current SHA hash algorithms. Cc: David Howells Cc: keyri...@vger.kernel.org Signed-off-by: Stefan Berger --- v7->v8: - do not detect key algo using parse_OID() in public_key.c but set pkey_algo to the key type 'ecdsa-nist-p192/256' when parsing cert --- crypto/asymmetric_keys/public_key.c | 4 ++- crypto/asymmetric_keys/x509_cert_parser.c | 34 ++- crypto/asymmetric_keys/x509_public_key.c | 4 ++- include/linux/oid_registry.h | 2 ++ 4 files changed, 41 insertions(+), 3 deletions(-) diff --git a/crypto/asymmetric_keys/public_key.c b/crypto/asymmetric_keys/public_key.c index 788a4ba1e2e7..4fefb219bfdc 100644 --- a/crypto/asymmetric_keys/public_key.c +++ b/crypto/asymmetric_keys/public_key.c @@ -14,6 +14,7 @@ #include #include #include +#include #include #include #include @@ -85,7 +86,8 @@ int software_key_determine_akcipher(const char *encoding, return n >= CRYPTO_MAX_ALG_NAME ? -EINVAL : 0; } - if (strcmp(encoding, "raw") == 0) { + if (strcmp(encoding, "raw") == 0 || + strcmp(encoding, "x962") == 0) { strcpy(alg_name, pkey->pkey_algo); return 0; } diff --git a/crypto/asymmetric_keys/x509_cert_parser.c b/crypto/asymmetric_keys/x509_cert_parser.c index 1621ceaf5c95..f5d547c6dfb5 100644 --- a/crypto/asymmetric_keys/x509_cert_parser.c +++ b/crypto/asymmetric_keys/x509_cert_parser.c @@ -227,6 +227,26 @@ int x509_note_pkey_algo(void *context, size_t hdrlen, ctx->cert->sig->hash_algo = "sha224"; goto rsa_pkcs1; + case OID_id_ecdsa_with_sha1: + ctx->cert->sig->hash_algo = "sha1"; + goto ecdsa; + + case OID_id_ecdsa_with_sha224: + ctx->cert->sig->hash_algo = "sha224"; + goto ecdsa; + + case OID_id_ecdsa_with_sha256: + ctx->cert->sig->hash_algo = "sha256"; + goto ecdsa; + + case OID_id_ecdsa_with_sha384: + ctx->cert->sig->hash_algo = "sha384"; + goto ecdsa; + + case OID_id_ecdsa_with_sha512: + ctx->cert->sig->hash_algo = "sha512"; + goto ecdsa; + case OID_gost2012Signature256: ctx->cert->sig->hash_algo = "streebog256"; goto ecrdsa; @@ -255,6 +275,11 @@ int x509_note_pkey_algo(void *context, size_t hdrlen, ctx->cert->sig->encoding = "raw"; ctx->algo_oid = ctx->last_oid; return 0; +ecdsa: + ctx->cert->sig->pkey_algo = "ecdsa"; + ctx->cert->sig->encoding = "x962"; + ctx->algo_oid = ctx->last_oid; + return 0; } /* @@ -276,7 +301,8 @@ int x509_note_signature(void *context, size_t hdrlen, if (strcmp(ctx->cert->sig->pkey_algo, "rsa") == 0 || strcmp(ctx->cert->sig->pkey_algo, "ecrdsa") == 0 || - strcmp(ctx->cert->sig->pkey_algo, "sm2") == 0) { + strcmp(ctx->cert->sig->pkey_algo, "sm2") == 0 || + strcmp(ctx->cert->sig->pkey_algo, "ecdsa") == 0) { /* Discard the BIT STRING metadata */ if (vlen < 1 || *(const u8 *)value != 0) return -EBADMSG; @@ -478,6 +504,12 @@ int x509_extract_key_data(void *context, size_t hdrlen, case OID_sm2: ctx->cert->pub->pkey_algo = "sm2"; break; + case OID_id_prime192v1: + ctx->cert->pub->pkey_algo = "ecdsa-nist-p192"; + break; + case OID_id_prime256v1: + ctx->cert->pub->pkey_algo = "ecdsa-nist-p256"; + break; default: return -ENOPKG; } diff --git a/crypto/asymmetric_keys/x509_public_key.c b/crypto/asymmetric_keys/x509_public_key.c index ae450eb8be14..3d45161b271a 100644 --- a/crypto/asymmetric_keys/x509_public_key.c +++ b/crypto/asymmetric_keys/x509_public_key.c @@ -129,7 +129,9 @@ int x509_check_for_self_signed(struct x509_certificate *cert) } ret = -EKEYREJECTED; - if (strcmp(cert->pub->pkey_algo, cert->sig->pkey_algo) != 0) + if (strcmp(cert->pub->pkey_algo, cert->sig->pkey_algo) != 0 && + (strncmp(cert->pub->pkey_algo, "ecdsa-", 6) != 0 || +strcmp(cert->sig->pkey_algo, "ecdsa") != 0)) goto out; ret = public_key_verify_signature(cert->pub, cert->sig); diff --git a/include/linux/oid_registry.h b/include/linux/oid_registry.h index f32d91895e4d..3583908cf1ca 100644 --- a/include/linux/oid_registry.h +++ b/include/linux/oid_registry.h @@ -20,6 +20,8 @@ enum OID { OID_id_dsa_with_sha1, /* 1.2.840.10030.4.3 */ OID_id_dsa, /* 1.2.
[PATCH v10 7/9] ima: Support EC keys for signature verification
From: Stefan Berger Add support for IMA signature verification for EC keys. Since SHA type of hashes can be used by RSA and ECDSA signature schemes we need to look at the key and derive from the key which signature scheme to use. Since this can be applied to all types of keys, we change the selection of the encoding type to be driven by the key's signature scheme rather than by the hash type. Cc: Dmitry Kasatkin Cc: linux-integr...@vger.kernel.org Cc: David Howells Cc: keyri...@vger.kernel.org Signed-off-by: Stefan Berger Reviewed-by: Vitaly Chikunov Reviewed-by: Tianjia Zhang Acked-by: Mimi Zohar --- v7->v8: - use strncmp to check for 'ecdsa-' to match 'ecdsa-nist-p192' and 'ecdsa-nist-p256' key types; previously they were just 'ecdsa' --- include/keys/asymmetric-type.h | 6 ++ security/integrity/digsig_asymmetric.c | 30 -- 2 files changed, 20 insertions(+), 16 deletions(-) diff --git a/include/keys/asymmetric-type.h b/include/keys/asymmetric-type.h index a29d3ff2e7e8..c432fdb8547f 100644 --- a/include/keys/asymmetric-type.h +++ b/include/keys/asymmetric-type.h @@ -72,6 +72,12 @@ const struct asymmetric_key_ids *asymmetric_key_ids(const struct key *key) return key->payload.data[asym_key_ids]; } +static inline +const struct public_key *asymmetric_key_public_key(const struct key *key) +{ + return key->payload.data[asym_crypto]; +} + extern struct key *find_asymmetric_key(struct key *keyring, const struct asymmetric_key_id *id_0, const struct asymmetric_key_id *id_1, diff --git a/security/integrity/digsig_asymmetric.c b/security/integrity/digsig_asymmetric.c index a662024b4c70..23240d793b07 100644 --- a/security/integrity/digsig_asymmetric.c +++ b/security/integrity/digsig_asymmetric.c @@ -84,6 +84,7 @@ int asymmetric_verify(struct key *keyring, const char *sig, { struct public_key_signature pks; struct signature_v2_hdr *hdr = (struct signature_v2_hdr *)sig; + const struct public_key *pk; struct key *key; int ret; @@ -105,23 +106,20 @@ int asymmetric_verify(struct key *keyring, const char *sig, memset(&pks, 0, sizeof(pks)); pks.hash_algo = hash_algo_name[hdr->hash_algo]; - switch (hdr->hash_algo) { - case HASH_ALGO_STREEBOG_256: - case HASH_ALGO_STREEBOG_512: - /* EC-RDSA and Streebog should go together. */ - pks.pkey_algo = "ecrdsa"; - pks.encoding = "raw"; - break; - case HASH_ALGO_SM3_256: - /* SM2 and SM3 should go together. */ - pks.pkey_algo = "sm2"; - pks.encoding = "raw"; - break; - default: - pks.pkey_algo = "rsa"; + + pk = asymmetric_key_public_key(key); + pks.pkey_algo = pk->pkey_algo; + if (!strcmp(pk->pkey_algo, "rsa")) pks.encoding = "pkcs1"; - break; - } + else if (!strncmp(pk->pkey_algo, "ecdsa-", 6)) + /* edcsa-nist-p192 etc. */ + pks.encoding = "x962"; + else if (!strcmp(pk->pkey_algo, "ecrdsa") || + !strcmp(pk->pkey_algo, "sm2")) + pks.encoding = "raw"; + else + return -ENOPKG; + pks.digest = (u8 *)data; pks.digest_size = datalen; pks.s = hdr->sig; -- 2.29.2
[PATCH v10 9/9] certs: Add support for using elliptic curve keys for signing modules
From: Stefan Berger This patch adds support for using elliptic curve keys for signing modules. It uses a NIST P384 (secp384r1) key if the user chooses an elliptic curve key and will have ECDSA support built into the kernel. Note: A developer choosing an ECDSA key for signing modules has to manually delete the signing key (rm certs/signing_key.*) when falling back to building an older version of a kernel that only supports RSA keys since otherwise ECDSA-signed modules will not be usable when that older kernel runs and the ECDSA key was still used for signing modules. Signed-off-by: Stefan Berger Reviewed-by: Mimi Zohar --- v8->v9: - Automatically select CONFIG_ECDSA for built-in ECDSA support - Added help documentation This patch builds on top Nayna's series for 'kernel build support for loading the kernel module signing key'. - https://lkml.org/lkml/2021/2/18/856 --- certs/Kconfig | 22 ++ certs/Makefile| 14 ++ crypto/asymmetric_keys/pkcs7_parser.c | 4 3 files changed, 40 insertions(+) diff --git a/certs/Kconfig b/certs/Kconfig index 48675ad319db..919db43ce80b 100644 --- a/certs/Kconfig +++ b/certs/Kconfig @@ -15,6 +15,28 @@ config MODULE_SIG_KEY then the kernel will automatically generate the private key and certificate as described in Documentation/admin-guide/module-signing.rst +choice + prompt "Type of module signing key to be generated" + default MODULE_SIG_KEY_TYPE_RSA + help +The type of module signing key type to generated. This option +does not apply if a #PKCS11 URI is used. + +config MODULE_SIG_KEY_TYPE_RSA + bool "RSA" + depends on MODULE_SIG || IMA_APPRAISE_MODSIG + help +Use an RSA key for module signing. + +config MODULE_SIG_KEY_TYPE_ECDSA + bool "ECDSA" + select CRYPTO_ECDSA + depends on MODULE_SIG || IMA_APPRAISE_MODSIG + help +Use an elliptic curve key (NIST P384) for module signing. + +endchoice + config SYSTEM_TRUSTED_KEYRING bool "Provide system-wide ring of trusted keys" depends on KEYS diff --git a/certs/Makefile b/certs/Makefile index 3fe6b73786fa..c487d7021c54 100644 --- a/certs/Makefile +++ b/certs/Makefile @@ -69,6 +69,18 @@ else SIGNER = -signkey $(obj)/signing_key.key endif # CONFIG_IMA_APPRAISE_MODSIG +X509TEXT=$(shell openssl x509 -in $(CONFIG_MODULE_SIG_KEY) -text) + +# Support user changing key type +ifdef CONFIG_MODULE_SIG_KEY_TYPE_ECDSA +keytype_openssl = -newkey ec -pkeyopt ec_paramgen_curve:secp384r1 +$(if $(findstring ecdsa-with-,$(X509TEXT)),,$(shell rm -f $(CONFIG_MODULE_SIG_KEY))) +endif + +ifdef CONFIG_MODULE_SIG_KEY_TYPE_RSA +$(if $(findstring rsaEncryption,$(X509TEXT)),,$(shell rm -f $(CONFIG_MODULE_SIG_KEY))) +endif + $(obj)/signing_key.pem: $(obj)/x509.genkey @$(kecho) "###" @$(kecho) "### Now generating an X.509 key pair to be used for signing modules." @@ -86,12 +98,14 @@ ifeq ($(CONFIG_IMA_APPRAISE_MODSIG),y) -batch -x509 -config $(obj)/x509.genkey \ -outform PEM -out $(CA_KEY) \ -keyout $(CA_KEY) -extensions ca_ext \ + $(keytype_openssl) \ $($(quiet)redirect_openssl) endif # CONFIG_IMA_APPRAISE_MODSIG $(Q)openssl req -new -nodes -utf8 \ -batch -config $(obj)/x509.genkey \ -outform PEM -out $(obj)/signing_key.csr \ -keyout $(obj)/signing_key.key -extensions myexts \ + $(keytype_openssl) \ $($(quiet)redirect_openssl) $(Q)openssl x509 -req -days 36500 -in $(obj)/signing_key.csr \ -outform PEM -out $(obj)/signing_key.crt $(SIGNER) \ diff --git a/crypto/asymmetric_keys/pkcs7_parser.c b/crypto/asymmetric_keys/pkcs7_parser.c index 967329e0a07b..2546ec6a0505 100644 --- a/crypto/asymmetric_keys/pkcs7_parser.c +++ b/crypto/asymmetric_keys/pkcs7_parser.c @@ -269,6 +269,10 @@ int pkcs7_sig_note_pkey_algo(void *context, size_t hdrlen, ctx->sinfo->sig->pkey_algo = "rsa"; ctx->sinfo->sig->encoding = "pkcs1"; break; + case OID_id_ecdsa_with_sha256: + ctx->sinfo->sig->pkey_algo = "ecdsa"; + ctx->sinfo->sig->encoding = "x962"; + break; default: printk("Unsupported pkey algo: %u\n", ctx->last_oid); return -ENOPKG; -- 2.29.2
[PATCH v10 2/9] crypto: Add NIST P384 curve parameters
From: Saulo Alessandre * crypto/ecc_curve_defs.h - add nist_p384 params * include/crypto/ecdh.h - add ECC_CURVE_NIST_P384 * crypto/ecc.c - change ecc_get_curve to accept nist_p384 Signed-off-by: Saulo Alessandre Tested-by: Stefan Berger --- crypto/ecc.c| 2 ++ crypto/ecc_curve_defs.h | 32 include/crypto/ecdh.h | 1 + 3 files changed, 35 insertions(+) diff --git a/crypto/ecc.c b/crypto/ecc.c index 25e79fd70566..f6cef5a7942d 100644 --- a/crypto/ecc.c +++ b/crypto/ecc.c @@ -50,6 +50,8 @@ const struct ecc_curve *ecc_get_curve(unsigned int curve_id) return fips_enabled ? NULL : &nist_p192; case ECC_CURVE_NIST_P256: return &nist_p256; + case ECC_CURVE_NIST_P384: + return &nist_p384; default: return NULL; } diff --git a/crypto/ecc_curve_defs.h b/crypto/ecc_curve_defs.h index 69be6c7d228f..b327732f6ef5 100644 --- a/crypto/ecc_curve_defs.h +++ b/crypto/ecc_curve_defs.h @@ -54,4 +54,36 @@ static struct ecc_curve nist_p256 = { .b = nist_p256_b }; +/* NIST P-384 */ +static u64 nist_p384_g_x[] = { 0x3A545E3872760AB7ull, 0x5502F25DBF55296Cull, + 0x59F741E082542A38ull, 0x6E1D3B628BA79B98ull, + 0x8Eb1C71EF320AD74ull, 0xAA87CA22BE8B0537ull }; +static u64 nist_p384_g_y[] = { 0x7A431D7C90EA0E5Full, 0x0A60B1CE1D7E819Dull, + 0xE9DA3113B5F0B8C0ull, 0xF8F41DBD289A147Cull, + 0x5D9E98BF9292DC29ull, 0x3617DE4A96262C6Full }; +static u64 nist_p384_p[] = { 0xull, 0xull, + 0xFFFEull, 0xull, + 0xull, 0xull }; +static u64 nist_p384_n[] = { 0xECEC196ACCC52973ull, 0x581A0DB248B0A77Aull, + 0xC7634D81F4372DDFull, 0xull, + 0xull, 0xull }; +static u64 nist_p384_a[] = { 0xFFFCull, 0xull, + 0xFFFEull, 0xull, + 0xull, 0xull }; +static u64 nist_p384_b[] = { 0x2a85c8edd3ec2aefull, 0xc656398d8a2ed19dull, + 0x0314088f5013875aull, 0x181d9c6efe814112ull, + 0x988e056be3f82d19ull, 0xb3312fa7e23ee7e4ull }; +static struct ecc_curve nist_p384 = { + .name = "nist_384", + .g = { + .x = nist_p384_g_x, + .y = nist_p384_g_y, + .ndigits = 6, + }, + .p = nist_p384_p, + .n = nist_p384_n, + .a = nist_p384_a, + .b = nist_p384_b +}; + #endif diff --git a/include/crypto/ecdh.h b/include/crypto/ecdh.h index a5b805b5526d..e4ba1de961e4 100644 --- a/include/crypto/ecdh.h +++ b/include/crypto/ecdh.h @@ -25,6 +25,7 @@ /* Curves IDs */ #define ECC_CURVE_NIST_P1920x0001 #define ECC_CURVE_NIST_P2560x0002 +#define ECC_CURVE_NIST_P3840x0003 /** * struct ecdh - define an ECDH private key -- 2.29.2
[PATCH v10 1/9] crypto: Add support for ECDSA signature verification
From: Stefan Berger Add support for parsing the parameters of a NIST P256 or NIST P192 key. Enable signature verification using these keys. The new module is enabled with CONFIG_ECDSA: Elliptic Curve Digital Signature Algorithm (NIST P192, P256 etc.) is A NIST cryptographic standard algorithm. Only signature verification is implemented. Cc: Herbert Xu Cc: "David S. Miller" Cc: linux-crypto@vger.kernel.org Signed-off-by: Stefan Berger Acked-by: Jarkko Sakkinen --- v8->v9: - unregister nist_p192 curve if nist_p256 cannot be registered --- crypto/Kconfig | 10 + crypto/Makefile | 6 + crypto/ecc.c | 13 +- crypto/ecc.h | 28 +++ crypto/ecdsa.c | 369 +++ crypto/ecdsasignature.asn1 | 4 + crypto/testmgr.c | 12 ++ crypto/testmgr.h | 267 + include/linux/oid_registry.h | 6 +- 9 files changed, 703 insertions(+), 12 deletions(-) create mode 100644 crypto/ecdsa.c create mode 100644 crypto/ecdsasignature.asn1 diff --git a/crypto/Kconfig b/crypto/Kconfig index a367fcfeb5d4..a31df40591f5 100644 --- a/crypto/Kconfig +++ b/crypto/Kconfig @@ -247,6 +247,16 @@ config CRYPTO_ECDH help Generic implementation of the ECDH algorithm +config CRYPTO_ECDSA + tristate "ECDSA (NIST P192, P256 etc.) algorithm" + select CRYPTO_ECC + select CRYPTO_AKCIPHER + select ASN1 + help + Elliptic Curve Digital Signature Algorithm (NIST P192, P256 etc.) + is A NIST cryptographic standard algorithm. Only signature verification + is implemented. + config CRYPTO_ECRDSA tristate "EC-RDSA (GOST 34.10) algorithm" select CRYPTO_ECC diff --git a/crypto/Makefile b/crypto/Makefile index b279483fba50..982066c6bdfb 100644 --- a/crypto/Makefile +++ b/crypto/Makefile @@ -50,6 +50,12 @@ sm2_generic-y += sm2.o obj-$(CONFIG_CRYPTO_SM2) += sm2_generic.o +$(obj)/ecdsasignature.asn1.o: $(obj)/ecdsasignature.asn1.c $(obj)/ecdsasignature.asn1.h +$(obj)/ecdsa.o: $(obj)/ecdsasignature.asn1.h +ecdsa_generic-y += ecdsa.o +ecdsa_generic-y += ecdsasignature.asn1.o +obj-$(CONFIG_CRYPTO_ECDSA) += ecdsa_generic.o + crypto_acompress-y := acompress.o crypto_acompress-y += scompress.o obj-$(CONFIG_CRYPTO_ACOMP2) += crypto_acompress.o diff --git a/crypto/ecc.c b/crypto/ecc.c index c80aa25994a0..25e79fd70566 100644 --- a/crypto/ecc.c +++ b/crypto/ecc.c @@ -42,7 +42,7 @@ typedef struct { u64 m_high; } uint128_t; -static inline const struct ecc_curve *ecc_get_curve(unsigned int curve_id) +const struct ecc_curve *ecc_get_curve(unsigned int curve_id) { switch (curve_id) { /* In FIPS mode only allow P256 and higher */ @@ -54,6 +54,7 @@ static inline const struct ecc_curve *ecc_get_curve(unsigned int curve_id) return NULL; } } +EXPORT_SYMBOL(ecc_get_curve); static u64 *ecc_alloc_digits_space(unsigned int ndigits) { @@ -1281,16 +1282,6 @@ void ecc_point_mult_shamir(const struct ecc_point *result, } EXPORT_SYMBOL(ecc_point_mult_shamir); -static inline void ecc_swap_digits(const u64 *in, u64 *out, - unsigned int ndigits) -{ - const __be64 *src = (__force __be64 *)in; - int i; - - for (i = 0; i < ndigits; i++) - out[i] = be64_to_cpu(src[ndigits - 1 - i]); -} - static int __ecc_is_key_valid(const struct ecc_curve *curve, const u64 *private_key, unsigned int ndigits) { diff --git a/crypto/ecc.h b/crypto/ecc.h index d4e546b9ad79..2ea86dfb5cf7 100644 --- a/crypto/ecc.h +++ b/crypto/ecc.h @@ -33,6 +33,8 @@ #define ECC_DIGITS_TO_BYTES_SHIFT 3 +#define ECC_MAX_BYTES (ECC_MAX_DIGITS << ECC_DIGITS_TO_BYTES_SHIFT) + /** * struct ecc_point - elliptic curve point in affine coordinates * @@ -70,6 +72,32 @@ struct ecc_curve { u64 *b; }; +/** + * ecc_swap_digits() - Copy ndigits from big endian array to native array + * + * @in: input array + * @out: output array + * @ndigits: number of digits to copy + */ +static inline void ecc_swap_digits(const u64 *in, u64 *out, + unsigned int ndigits) +{ + const __be64 *src = (__force __be64 *)in; + int i; + + for (i = 0; i < ndigits; i++) + out[i] = be64_to_cpu(src[ndigits - 1 - i]); +} + +/** + * ecc_get_curve() - Get a curve given its curve_id + * + * @curve_id: Id of the curve + * + * Returns pointer to the curve data, NULL if curve is not available + */ +const struct ecc_curve *ecc_get_curve(unsigned int curve_id); + /** * ecc_is_key_valid() - Validate a given ECDH private key * diff --git a/crypto/ecdsa.c b/crypto/ecdsa.c new file mode 100644 index ..04fbb3d2abc5 --- /dev/null +++ b/crypto/ecdsa.c @@ -0,0 +1,369 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (c) 2021 IBM Corporation + * + * Red
[PATCH v10 3/9] crypto: Add math to support fast NIST P384
From: Saulo Alessandre * crypto/ecc.c - add vli_mmod_fast_384 - change some routines to pass ecc_curve forward until vli_mmod_fast * crypto/ecc.h - add ECC_CURVE_NIST_P384_DIGITS - change ECC_MAX_DIGITS to P384 size Signed-off-by: Saulo Alessandre Tested-by: Stefan Berger --- crypto/ecc.c | 266 +-- crypto/ecc.h | 3 +- 2 files changed, 194 insertions(+), 75 deletions(-) diff --git a/crypto/ecc.c b/crypto/ecc.c index f6cef5a7942d..c125576cda6b 100644 --- a/crypto/ecc.c +++ b/crypto/ecc.c @@ -778,18 +778,133 @@ static void vli_mmod_fast_256(u64 *result, const u64 *product, } } +#define SL32OR32(x32, y32) (((u64)x32 << 32) | y32) +#define AND64H(x64) (x64 & 0xffFFffFFull) +#define AND64L(x64) (x64 & 0xffFFffFFull) + +/* Computes result = product % curve_prime + * from "Mathematical routines for the NIST prime elliptic curves" + */ +static void vli_mmod_fast_384(u64 *result, const u64 *product, + const u64 *curve_prime, u64 *tmp) +{ + int carry; + const unsigned int ndigits = 6; + + /* t */ + vli_set(result, product, ndigits); + + /* s1 */ + tmp[0] = 0; // 0 || 0 + tmp[1] = 0; // 0 || 0 + tmp[2] = SL32OR32(product[11], (product[10]>>32)); //a22||a21 + tmp[3] = product[11]>>32; // 0 ||a23 + tmp[4] = 0; // 0 || 0 + tmp[5] = 0; // 0 || 0 + carry = vli_lshift(tmp, tmp, 1, ndigits); + carry += vli_add(result, result, tmp, ndigits); + + /* s2 */ + tmp[0] = product[6];//a13||a12 + tmp[1] = product[7];//a15||a14 + tmp[2] = product[8];//a17||a16 + tmp[3] = product[9];//a19||a18 + tmp[4] = product[10]; //a21||a20 + tmp[5] = product[11]; //a23||a22 + carry += vli_add(result, result, tmp, ndigits); + + /* s3 */ + tmp[0] = SL32OR32(product[11], (product[10]>>32)); //a22||a21 + tmp[1] = SL32OR32(product[6], (product[11]>>32)); //a12||a23 + tmp[2] = SL32OR32(product[7], (product[6])>>32);//a14||a13 + tmp[3] = SL32OR32(product[8], (product[7]>>32));//a16||a15 + tmp[4] = SL32OR32(product[9], (product[8]>>32));//a18||a17 + tmp[5] = SL32OR32(product[10], (product[9]>>32)); //a20||a19 + carry += vli_add(result, result, tmp, ndigits); + + /* s4 */ + tmp[0] = AND64H(product[11]); //a23|| 0 + tmp[1] = (product[10]<<32); //a20|| 0 + tmp[2] = product[6];//a13||a12 + tmp[3] = product[7];//a15||a14 + tmp[4] = product[8];//a17||a16 + tmp[5] = product[9];//a19||a18 + carry += vli_add(result, result, tmp, ndigits); + + /* s5 */ + tmp[0] = 0; // 0|| 0 + tmp[1] = 0; // 0|| 0 + tmp[2] = product[10]; //a21||a20 + tmp[3] = product[11]; //a23||a22 + tmp[4] = 0; // 0|| 0 + tmp[5] = 0; // 0|| 0 + carry += vli_add(result, result, tmp, ndigits); + + /* s6 */ + tmp[0] = AND64L(product[10]); // 0 ||a20 + tmp[1] = AND64H(product[10]); //a21|| 0 + tmp[2] = product[11]; //a23||a22 + tmp[3] = 0; // 0 || 0 + tmp[4] = 0; // 0 || 0 + tmp[5] = 0; // 0 || 0 + carry += vli_add(result, result, tmp, ndigits); + + /* d1 */ + tmp[0] = SL32OR32(product[6], (product[11]>>32)); //a12||a23 + tmp[1] = SL32OR32(product[7], (product[6]>>32));//a14||a13 + tmp[2] = SL32OR32(product[8], (product[7]>>32));//a16||a15 + tmp[3] = SL32OR32(product[9], (product[8]>>32));//a18||a17 + tmp[4] = SL32OR32(product[10], (product[9]>>32)); //a20||a19 + tmp[5] = SL32OR32(product[11], (product[10]>>32)); //a22||a21 + carry -= vli_sub(result, result, tmp, ndigits); + + /* d2 */ + tmp[0] = (product[10]<<32); //a20|| 0 + tmp[1] = SL32OR32(product[11], (product[10]>>32)); //a22||a21 + tmp[2] = (product[11]>>32); // 0 ||a23 + tmp[3] = 0; // 0 || 0 + tmp[4] = 0; // 0 || 0 + tmp[5] = 0; // 0 || 0 + carry -= vli_sub(result, result, tmp, ndigits); + + /* d3 */ + tmp[0] = 0; // 0 || 0 + tmp[1] = AND64H(product[11]); //a23|| 0 + tmp[2] = product[11]>>32; // 0 ||a23 + tmp[3] = 0; // 0 || 0 + tmp[4] = 0; // 0 || 0 + tmp[5] = 0; // 0 || 0 + carry -= vli_sub(result, result, tmp, ndigits); + + if (carry < 0) { + do { + carry += vli_add(result, result, curve_prime, ndigits); + } while (carry < 0); + } else { + while (carry || vli_cmp(curve_prime, result, ndigits) != 1) +
[PATCH v10 8/9] x509: Add OID for NIST P384 and extend parser for it
From: Saulo Alessandre * crypto/asymmetric_keys/x509_cert_parser.c - prepare x509 parser to load nist_secp384r1 * include/linux/oid_registry.h - add OID_id_secp384r1 Signed-off-by: Saulo Alessandre Tested-by: Stefan Berger --- crypto/asymmetric_keys/x509_cert_parser.c | 3 +++ include/linux/oid_registry.h | 1 + 2 files changed, 4 insertions(+) diff --git a/crypto/asymmetric_keys/x509_cert_parser.c b/crypto/asymmetric_keys/x509_cert_parser.c index f5d547c6dfb5..526c6a407e07 100644 --- a/crypto/asymmetric_keys/x509_cert_parser.c +++ b/crypto/asymmetric_keys/x509_cert_parser.c @@ -510,6 +510,9 @@ int x509_extract_key_data(void *context, size_t hdrlen, case OID_id_prime256v1: ctx->cert->pub->pkey_algo = "ecdsa-nist-p256"; break; + case OID_id_secp384r1: + ctx->cert->pub->pkey_algo = "ecdsa-nist-p384"; + break; default: return -ENOPKG; } diff --git a/include/linux/oid_registry.h b/include/linux/oid_registry.h index 3583908cf1ca..d656450dfc66 100644 --- a/include/linux/oid_registry.h +++ b/include/linux/oid_registry.h @@ -64,6 +64,7 @@ enum OID { OID_certAuthInfoAccess, /* 1.3.6.1.5.5.7.1.1 */ OID_sha1, /* 1.3.14.3.2.26 */ + OID_id_secp384r1, /* 1.3.132.0.34 */ OID_sha256, /* 2.16.840.1.101.3.4.2.1 */ OID_sha384, /* 2.16.840.1.101.3.4.2.2 */ OID_sha512, /* 2.16.840.1.101.3.4.2.3 */ -- 2.29.2
[PATCH v10 4/9] ecdsa: Register NIST P384 and extend test suite
From: Saulo Alessandre * crypto/ecdsa.c - add ecdsa_nist_p384_init_tfm - register and unregister P384 tfm * crypto/testmgr.c - add test vector for P384 on vector of tests * crypto/testmgr.h - add test vector params for P384(sha1, sha224, sha256, sha384 and sha512) Signed-off-by: Saulo Alessandre Tested-by: Stefan Berger --- crypto/ecdsa.c | 33 +- crypto/testmgr.c | 6 ++ crypto/testmgr.h | 157 +++ 3 files changed, 195 insertions(+), 1 deletion(-) diff --git a/crypto/ecdsa.c b/crypto/ecdsa.c index 04fbb3d2abc5..8cce80e4154e 100644 --- a/crypto/ecdsa.c +++ b/crypto/ecdsa.c @@ -145,7 +145,7 @@ static int _ecdsa_verify(struct ecc_ctx *ctx, const u64 *hash, /* res.x = res.x mod n (if res.x > order) */ if (unlikely(vli_cmp(res.x, curve->n, ndigits) == 1)) - /* faster alternative for NIST p256 & p192 */ + /* faster alternative for NIST p384, p256 & p192 */ vli_sub(res.x, res.x, curve->n, ndigits); if (!vli_cmp(res.x, r, ndigits)) @@ -289,6 +289,28 @@ static unsigned int ecdsa_max_size(struct crypto_akcipher *tfm) return ctx->pub_key.ndigits << ECC_DIGITS_TO_BYTES_SHIFT; } +static int ecdsa_nist_p384_init_tfm(struct crypto_akcipher *tfm) +{ + struct ecc_ctx *ctx = akcipher_tfm_ctx(tfm); + + return ecdsa_ecc_ctx_init(ctx, ECC_CURVE_NIST_P384); +} + +static struct akcipher_alg ecdsa_nist_p384 = { + .verify = ecdsa_verify, + .set_pub_key = ecdsa_set_pub_key, + .max_size = ecdsa_max_size, + .init = ecdsa_nist_p384_init_tfm, + .exit = ecdsa_exit_tfm, + .base = { + .cra_name = "ecdsa-nist-p384", + .cra_driver_name = "ecdsa-nist-p384-generic", + .cra_priority = 100, + .cra_module = THIS_MODULE, + .cra_ctxsize = sizeof(struct ecc_ctx), + }, +}; + static int ecdsa_nist_p256_init_tfm(struct crypto_akcipher *tfm) { struct ecc_ctx *ctx = akcipher_tfm_ctx(tfm); @@ -345,8 +367,16 @@ static int ecdsa_init(void) ret = crypto_register_akcipher(&ecdsa_nist_p256); if (ret) goto nist_p256_error; + + ret = crypto_register_akcipher(&ecdsa_nist_p384); + if (ret) + goto nist_p384_error; + return 0; +nist_p384_error: + crypto_unregister_akcipher(&ecdsa_nist_p256); + nist_p256_error: if (ecdsa_nist_p192_registered) crypto_unregister_akcipher(&ecdsa_nist_p192); @@ -358,6 +388,7 @@ static void ecdsa_exit(void) if (ecdsa_nist_p192_registered) crypto_unregister_akcipher(&ecdsa_nist_p192); crypto_unregister_akcipher(&ecdsa_nist_p256); + crypto_unregister_akcipher(&ecdsa_nist_p384); } subsys_initcall(ecdsa_init); diff --git a/crypto/testmgr.c b/crypto/testmgr.c index 2607602f9de5..08f85719338a 100644 --- a/crypto/testmgr.c +++ b/crypto/testmgr.c @@ -4925,6 +4925,12 @@ static const struct alg_test_desc alg_test_descs[] = { .suite = { .akcipher = __VECS(ecdsa_nist_p256_tv_template) } + }, { + .alg = "ecdsa-nist-p384", + .test = alg_test_akcipher, + .suite = { + .akcipher = __VECS(ecdsa_nist_p384_tv_template) + } }, { .alg = "ecrdsa", .test = alg_test_akcipher, diff --git a/crypto/testmgr.h b/crypto/testmgr.h index 2adcc0dc0bdd..e63a760aca2d 100644 --- a/crypto/testmgr.h +++ b/crypto/testmgr.h @@ -833,6 +833,163 @@ static const struct akcipher_testvec ecdsa_nist_p256_tv_template[] = { }, }; +static const struct akcipher_testvec ecdsa_nist_p384_tv_template[] = { + { + .key = /* secp384r1(sha1) */ + "\x04\x89\x25\xf3\x97\x88\xcb\xb0\x78\xc5\x72\x9a\x14\x6e\x7a\xb1" + "\x5a\xa5\x24\xf1\x95\x06\x9e\x28\xfb\xc4\xb9\xbe\x5a\x0d\xd9\x9f" + "\xf3\xd1\x4d\x2d\x07\x99\xbd\xda\xa7\x66\xec\xbb\xea\xba\x79\x42" + "\xc9\x34\x89\x6a\xe7\x0b\xc3\xf2\xfe\x32\x30\xbe\xba\xf9\xdf\x7e" + "\x4b\x6a\x07\x8e\x26\x66\x3f\x1d\xec\xa2\x57\x91\x51\xdd\x17\x0e" + "\x0b\x25\xd6\x80\x5c\x3b\xe6\x1a\x98\x48\x91\x45\x7a\x73\xb0\xc3" + "\xf1", + .key_len = 97, + .params = + "\x30\x10\x06\x07\x2a\x86\x48\xce\x3d\x02\x01\x06\x05\x2b\x81\x04" + "\x00\x22", + .param_len = 18, + .m = + "\x12\x55\x28\xf0\x77\xd5\xb6\x21\x71\x32\x48\xcd\x28\xa8\x25\x22" + "\x3a\x69\xc1\x93", + .m_size = 20, + .algo = OID_id_ecdsa_with_sha1, + .c = + "\x30\x66\x02\x31\x00\xf5\x0f\x24\x4c\x07\x93\x6f\x21\x57\x55\x07" + "\x20\x43\x30\xde\xa0\x8d\x26\x8e\xae\x63\x3f\xbc\x20\x3a\xc6\xf1" + "\x32\x3c\xce\x70\x2b\x78\xf1\x4c\x26\xe6\x5b\x86\xcf\xec\x7c\x7e" + "\xd0\x87\xd7\xd7\x6e\x02\x31\x00\xcd\xbb\x7e\x81\x5d\x8f\x63\xc0" + "\x5f\x63\xb1\xbe
Re: [PATCH v10 0/9] Add support for x509 certs with NIST P384/256/192 keys
Herbert, you can take patches 1-8. 9 will not apply without Nayna's series as mentioned in the patch. Regards, Stefan On 3/4/21 7:51 PM, Stefan Berger wrote: From: Stefan Berger This series of patches adds support for x509 certificates signed by a CA that uses NIST P384, P256 or P192 keys for signing. It also adds support for certificates where the public key is one of this type of a key. The math for ECDSA signature verification is also added as well as the math for fast mmod operation for NIST P384. Since self-signed certificates are verified upon loading, the following script can be used for testing of NIST P256 keys: k=$(keyctl newring test @u) while :; do for hash in sha1 sha224 sha256 sha384 sha512; do openssl req \ -x509 \ -${hash} \ -newkey ec \ -pkeyopt ec_paramgen_curve:prime256v1 \ -keyout key.pem \ -days 365 \ -subj '/CN=test' \ -nodes \ -outform der \ -out cert.der keyctl padd asymmetric testkey $k < cert.der if [ $? -ne 0 ]; then echo "ERROR" exit 1 fi done done Ecdsa support also works with restricted keyrings where an RSA key is used to sign a NIST P384/256/192 key. Scripts for testing are here: https://github.com/stefanberger/eckey-testing The ECDSA signature verification will be used by IMA Appraisal where ECDSA file signatures stored in RPM packages will use substantially less space than if RSA signatures were to be used. Further, a patch is added that allows kernel modules to be signed with a NIST p384 key. Stefan and Saulo v9->v10: - rearranged order of patches to have crypto patches first - moved hunk from patch 3 to patch 2 to avoid compilation warning due to unused symbol v8->v9: - Appended Saulo's patches - Appended patch to support kernel modules signed with NIST p384 key. This patch requires Nayna's series here: https://lkml.org/lkml/2021/2/18/856 v7->v8: - patch 3/4: Do not determine key algo using parse_OID in public_key.c but do this when parsing the certificate. This addresses an issue with certain build configurations where OID_REGISTRY is not available as 'Reported-by: kernel test robot '. v6->v7: - Moved some OID defintions to patch 1 for bisectability - Applied R-b's v5->v6: - moved ecdsa code into its own module ecdsa_generic built from ecdsa.c - added script-generated test vectors for NIST P256 & P192 and all hashes - parsing of OID that contain header with new parse_oid() v4->v5: - registering crypto support under names ecdsa-nist-p256/p192 following Hubert Xu's suggestion in other thread - appended IMA ECDSA support patch v3->v4: - split off of ecdsa crypto part; registering akcipher as "ecdsa" and deriving used curve from digits in parsed key v2->v3: - patch 2 now includes linux/scatterlist.h v1->v2: - using faster vli_sub rather than newly added vli_mod_fast to 'reduce' result - rearranged switch statements to follow after RSA - 3rd patch from 1st posting is now 1st patch Saulo Alessandre (4): crypto: Add NIST P384 curve parameters crypto: Add math to support fast NIST P384 ecdsa: Register NIST P384 and extend test suite x509: Add OID for NIST P384 and extend parser for it Stefan Berger (5): crypto: Add support for ECDSA signature verification x509: Detect sm2 keys by their parameters OID x509: Add support for parsing x509 certs with ECDSA keys ima: Support EC keys for signature verification certs: Add support for using elliptic curve keys for signing modules certs/Kconfig | 22 ++ certs/Makefile| 14 + crypto/Kconfig| 10 + crypto/Makefile | 6 + crypto/asymmetric_keys/pkcs7_parser.c | 4 + crypto/asymmetric_keys/public_key.c | 4 +- crypto/asymmetric_keys/x509_cert_parser.c | 49 ++- crypto/asymmetric_keys/x509_public_key.c | 4 +- crypto/ecc.c | 281 +- crypto/ecc.h | 31 +- crypto/ecc_curve_defs.h | 32 ++ crypto/ecdsa.c| 400 crypto/ecdsasignature.asn1| 4 + crypto/testmgr.c | 18 + crypto/testmgr.h | 424 ++ include/crypto/ecdh.h | 1 + include/keys/asymmetric-type.h| 6 + include/linux/oid_registry.h | 10 +- lib/oid_registry.c| 13 + security/integrity/digsig_asymmetric.c| 30 +- 20
[PATCH] crypto: allwinner: sun8i-ce: fix error return code in sun8i_ce_prng_generate()
When dma_mapping_error() returns an error, no error return code of sun8i_ce_prng_generate() is assigned. To fix this bug, err is assigned with -EFAULT as error return code. Reported-by: TOTE Robot Signed-off-by: Jia-Ju Bai --- drivers/crypto/allwinner/sun8i-ce/sun8i-ce-prng.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-prng.c b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-prng.c index cfde9ee4356b..cd1baee424a1 100644 --- a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-prng.c +++ b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-prng.c @@ -99,6 +99,7 @@ int sun8i_ce_prng_generate(struct crypto_rng *tfm, const u8 *src, dma_iv = dma_map_single(ce->dev, ctx->seed, ctx->slen, DMA_TO_DEVICE); if (dma_mapping_error(ce->dev, dma_iv)) { dev_err(ce->dev, "Cannot DMA MAP IV\n"); + err = -EFAULT; goto err_iv; } -- 2.17.1
Re: [PATCH] hwrng: bcm2835: set quality to 1000
Hi Florian, > El 4 mar 2021, a las 23:28, Florian Fainelli escribió: > > On 3/4/21 7:11 AM, Nicolas Saenz Julienne wrote: >> On Wed, 2021-03-03 at 10:29 +0100, Álvaro Fernández Rojas wrote: >>> Hi Herbert, >>> El 3 mar 2021, a las 10:20, Herbert Xu escribió: On Sat, Feb 20, 2021 at 08:12:45PM +0100, Álvaro Fernández Rojas wrote: > > I ran rngtest and this is what I got: This is meaningless except for sources that have not been whitened. Your justification needs to be based on what the hardware does or is documented to do. >>> >>> Ok, so I guess that we’re never setting that value to anything since there’s >>> no public documentation about that ¯\_(ツ)_/¯. >> >> @Florian, is there a way you might be able to get the official value? > > I will be looking into the documentation this weekend and let you know > whether we can change the driver's quality accordingly. Could you do that for iproc-rng200.c too? > -- > Florian Best regards, Álvaro.
[PATCH v2 2/2] crypto: qat - fix use of 'dma_map_single'
DMA_TO_DEVICE synchronisation must be done after the last modification of the memory region by the software and before it is handed off to the device. Signed-off-by: Hui Tang Reported-by: kernel test robot Reported-by: Dan Carpenter --- drivers/crypto/qat/qat_common/qat_algs.c | 27 ++- 1 file changed, 14 insertions(+), 13 deletions(-) diff --git a/drivers/crypto/qat/qat_common/qat_algs.c b/drivers/crypto/qat/qat_common/qat_algs.c index ea1c689..f998ed5 100644 --- a/drivers/crypto/qat/qat_common/qat_algs.c +++ b/drivers/crypto/qat/qat_common/qat_algs.c @@ -718,8 +718,8 @@ static int qat_alg_sgl_to_bufl(struct qat_crypto_instance *inst, int n = sg_nents(sgl); struct qat_alg_buf_list *bufl; struct qat_alg_buf_list *buflout = NULL; - dma_addr_t blp; - dma_addr_t bloutp; + dma_addr_t blp = DMA_MAPPING_ERROR; + dma_addr_t bloutp = DMA_MAPPING_ERROR; struct scatterlist *sg; size_t sz_out, sz = struct_size(bufl, bufers, n + 1); @@ -734,10 +734,6 @@ static int qat_alg_sgl_to_bufl(struct qat_crypto_instance *inst, for_each_sg(sgl, sg, n, i) bufl->bufers[i].addr = DMA_MAPPING_ERROR; - blp = dma_map_single(dev, bufl, sz, DMA_TO_DEVICE); - if (unlikely(dma_mapping_error(dev, blp))) - goto err_in; - for_each_sg(sgl, sg, n, i) { int y = sg_nctr; @@ -753,6 +749,9 @@ static int qat_alg_sgl_to_bufl(struct qat_crypto_instance *inst, sg_nctr++; } bufl->num_bufs = sg_nctr; + blp = dma_map_single(dev, bufl, sz, DMA_TO_DEVICE); + if (unlikely(dma_mapping_error(dev, blp))) + goto err_in; qat_req->buf.bl = bufl; qat_req->buf.blp = blp; qat_req->buf.sz = sz; @@ -772,9 +771,6 @@ static int qat_alg_sgl_to_bufl(struct qat_crypto_instance *inst, for_each_sg(sglout, sg, n, i) bufers[i].addr = DMA_MAPPING_ERROR; - bloutp = dma_map_single(dev, buflout, sz_out, DMA_TO_DEVICE); - if (unlikely(dma_mapping_error(dev, bloutp))) - goto err_out; for_each_sg(sglout, sg, n, i) { int y = sg_nctr; @@ -791,6 +787,9 @@ static int qat_alg_sgl_to_bufl(struct qat_crypto_instance *inst, } buflout->num_bufs = sg_nctr; buflout->num_mapped_bufs = sg_nctr; + bloutp = dma_map_single(dev, buflout, sz_out, DMA_TO_DEVICE); + if (unlikely(dma_mapping_error(dev, bloutp))) + goto err_out; qat_req->buf.blout = buflout; qat_req->buf.bloutp = bloutp; qat_req->buf.sz_out = sz_out; @@ -802,17 +801,21 @@ static int qat_alg_sgl_to_bufl(struct qat_crypto_instance *inst, return 0; err_out: + if (!dma_mapping_error(dev, bloutp)) + dma_unmap_single(dev, bloutp, sz_out, DMA_TO_DEVICE); + n = sg_nents(sglout); for (i = 0; i < n; i++) if (!dma_mapping_error(dev, buflout->bufers[i].addr)) dma_unmap_single(dev, buflout->bufers[i].addr, buflout->bufers[i].len, DMA_BIDIRECTIONAL); - if (!dma_mapping_error(dev, bloutp)) - dma_unmap_single(dev, bloutp, sz_out, DMA_TO_DEVICE); kfree(buflout); err_in: + if (!dma_mapping_error(dev, blp)) + dma_unmap_single(dev, blp, sz, DMA_TO_DEVICE); + n = sg_nents(sgl); for (i = 0; i < n; i++) if (!dma_mapping_error(dev, bufl->bufers[i].addr)) @@ -820,8 +823,6 @@ static int qat_alg_sgl_to_bufl(struct qat_crypto_instance *inst, bufl->bufers[i].len, DMA_BIDIRECTIONAL); - if (!dma_mapping_error(dev, blp)) - dma_unmap_single(dev, blp, sz, DMA_TO_DEVICE); kfree(bufl); dev_err(dev, "Failed to map buf for dma\n"); -- 2.8.1
[PATCH v2 1/2] crypto: qat - fix unmap invalid dma address
'dma_mapping_error' return a negative value if 'dma_addr' is equal to 'DMA_MAPPING_ERROR' not zero, so fix initialization of 'dma_addr'. Signed-off-by: Hui Tang --- drivers/crypto/qat/qat_common/qat_algs.c | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/crypto/qat/qat_common/qat_algs.c b/drivers/crypto/qat/qat_common/qat_algs.c index ff78c73..ea1c689 100644 --- a/drivers/crypto/qat/qat_common/qat_algs.c +++ b/drivers/crypto/qat/qat_common/qat_algs.c @@ -719,7 +719,7 @@ static int qat_alg_sgl_to_bufl(struct qat_crypto_instance *inst, struct qat_alg_buf_list *bufl; struct qat_alg_buf_list *buflout = NULL; dma_addr_t blp; - dma_addr_t bloutp = 0; + dma_addr_t bloutp; struct scatterlist *sg; size_t sz_out, sz = struct_size(bufl, bufers, n + 1); @@ -731,6 +731,9 @@ static int qat_alg_sgl_to_bufl(struct qat_crypto_instance *inst, if (unlikely(!bufl)) return -ENOMEM; + for_each_sg(sgl, sg, n, i) + bufl->bufers[i].addr = DMA_MAPPING_ERROR; + blp = dma_map_single(dev, bufl, sz, DMA_TO_DEVICE); if (unlikely(dma_mapping_error(dev, blp))) goto err_in; @@ -764,10 +767,14 @@ static int qat_alg_sgl_to_bufl(struct qat_crypto_instance *inst, dev_to_node(&GET_DEV(inst->accel_dev))); if (unlikely(!buflout)) goto err_in; + + bufers = buflout->bufers; + for_each_sg(sglout, sg, n, i) + bufers[i].addr = DMA_MAPPING_ERROR; + bloutp = dma_map_single(dev, buflout, sz_out, DMA_TO_DEVICE); if (unlikely(dma_mapping_error(dev, bloutp))) goto err_out; - bufers = buflout->bufers; for_each_sg(sglout, sg, n, i) { int y = sg_nctr; -- 2.8.1
[PATCH v2 0/2] crypto: qat - fixes related to 'dma_map_single'
This patchset fix bugs related to 'dma_map_single' use: Hui Tang (2): crypto: qat - fix 'dma_unmap_single' invalid address crypto: qat - fix use of 'dma_map_single' v1 -> v2: 1.fix build warning reported by kernel test rebot 2.add patch #1 drivers/crypto/qat/qat_common/qat_algs.c | 32 1 file changed, 20 insertions(+), 12 deletions(-) -- 2.8.1
[PATCH v6 0/3] hwrng: bcm2835: add reset support
Some devices may need to perform a reset before using the RNG, such as the BCM6368. v6: fix dt-bindings documentation, add patch makings clocks mandatory for BCM6368. v5: remove reset_control_rearm() and apply on latest herbert/cryptodev-2.6.git. v4: fix documentation, add reset_control_rearm(). v3: make resets required if brcm,bcm6368-rng. v2: document reset support. Álvaro Fernández Rojas (3): dt-bindings: rng: bcm2835: add clock constraints dt-bindings: rng: bcm2835: document reset support hwrng: bcm2835: add reset support .../devicetree/bindings/rng/brcm,bcm2835.yaml | 21 +++ drivers/char/hw_random/bcm2835-rng.c | 10 + 2 files changed, 31 insertions(+) -- 2.20.1
[PATCH v6 1/3] dt-bindings: rng: bcm2835: add clock constraints
brcm,bcm6368-rng controllers require enabling the IPSEC clock in order to get a functional RNG. Signed-off-by: Álvaro Fernández Rojas --- v6: add new patch making clocks mandatory for BCM6368. .../devicetree/bindings/rng/brcm,bcm2835.yaml | 10 ++ 1 file changed, 10 insertions(+) diff --git a/Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml b/Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml index c147900f9041..5174492e22f3 100644 --- a/Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml +++ b/Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml @@ -35,6 +35,16 @@ required: - compatible - reg +if: + properties: +compatible: + enum: +- brcm,bcm6368-rng +then: + required: +- clocks +- clock-names + additionalProperties: false examples: -- 2.20.1
[PATCH v6 3/3] hwrng: bcm2835: add reset support
BCM6368 devices need to reset the IPSEC controller in order to generate true random numbers. This is what BCM6368 produces without a reset: root@OpenWrt:/# cat /dev/hwrng | rngtest -c 1000 rngtest 6.10 Copyright (c) 2004 by Henrique de Moraes Holschuh This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. rngtest: starting FIPS tests... rngtest: bits received from input: 2032 rngtest: FIPS 140-2 successes: 0 rngtest: FIPS 140-2 failures: 1000 rngtest: FIPS 140-2(2001-10-10) Monobit: 2 rngtest: FIPS 140-2(2001-10-10) Poker: 1000 rngtest: FIPS 140-2(2001-10-10) Runs: 1000 rngtest: FIPS 140-2(2001-10-10) Long run: 30 rngtest: FIPS 140-2(2001-10-10) Continuous run: 0 rngtest: input channel speed: (min=37.253; avg=320.827; max=635.783)Mibits/s rngtest: FIPS tests speed: (min=12.141; avg=15.034; max=16.428)Mibits/s rngtest: Program run time: 1336176 microseconds Signed-off-by: Álvaro Fernández Rojas --- v6: fix commit description. v5: remove reset_control_rearm(). v4: add reset_control_rearm(). v3: no changes. v2: no changes. drivers/char/hw_random/bcm2835-rng.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/char/hw_random/bcm2835-rng.c b/drivers/char/hw_random/bcm2835-rng.c index be5be395b341..e7dd457e9b22 100644 --- a/drivers/char/hw_random/bcm2835-rng.c +++ b/drivers/char/hw_random/bcm2835-rng.c @@ -13,6 +13,7 @@ #include #include #include +#include #define RNG_CTRL 0x0 #define RNG_STATUS 0x4 @@ -32,6 +33,7 @@ struct bcm2835_rng_priv { void __iomem *base; bool mask_interrupts; struct clk *clk; + struct reset_control *reset; }; static inline struct bcm2835_rng_priv *to_rng_priv(struct hwrng *rng) @@ -92,6 +94,10 @@ static int bcm2835_rng_init(struct hwrng *rng) if (ret) return ret; + ret = reset_control_reset(priv->reset); + if (ret) + return ret; + if (priv->mask_interrupts) { /* mask the interrupt */ val = rng_readl(priv, RNG_INT_MASK); @@ -156,6 +162,10 @@ static int bcm2835_rng_probe(struct platform_device *pdev) if (IS_ERR(priv->clk)) return PTR_ERR(priv->clk); + priv->reset = devm_reset_control_get_optional_exclusive(dev, NULL); + if (IS_ERR(priv->reset)) + return PTR_ERR(priv->reset); + priv->rng.name = pdev->name; priv->rng.init = bcm2835_rng_init; priv->rng.read = bcm2835_rng_read; -- 2.20.1
[PATCH v6 2/3] dt-bindings: rng: bcm2835: document reset support
brcm,bcm6368-rng controllers require resetting the IPSEC clock in order to get a functional RNG. Signed-off-by: Álvaro Fernández Rojas --- v6: fix dt-bindings warnings. v5: no changes. v4: pass dt_binding_check. v3: make resets required if brcm,bcm6368-rng. v2: document reset support. .../devicetree/bindings/rng/brcm,bcm2835.yaml | 11 +++ 1 file changed, 11 insertions(+) diff --git a/Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml b/Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml index 5174492e22f3..6da674666d45 100644 --- a/Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml +++ b/Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml @@ -28,6 +28,12 @@ properties: clock-names: const: ipsec + resets: +maxItems: 1 + + reset-names: +const: ipsec + interrupts: maxItems: 1 @@ -44,6 +50,8 @@ then: required: - clocks - clock-names +- resets +- reset-names additionalProperties: false @@ -68,4 +76,7 @@ examples: clocks = <&periph_clk 18>; clock-names = "ipsec"; + +resets = <&periph_rst 4>; +reset-names = "ipsec"; }; -- 2.20.1
Re: [PATCH v9 2/9] x509: Detect sm2 keys by their parameters OID
Hi, On 3/4/21 7:46 AM, Stefan Berger wrote: Tianjia, can you say whether SM2 support works for you before and after applying this patch? I cannot verify it with an sm2 key I have created using a sequence of commands like this: > modprobe sm2_generic > id=$(keyctl newring test @u) > keyctl padd asymmetric "" $id < sm2.der add_key: Key was rejected by service > keyctl padd asymmetric "" $id < eckeys/cert-prime192v1-0.der 88506426 The sm2 key is reject but the pime192v1 key works just fine. SM2 support neither worked for me before nor after this patch here. The difference is that before it returned 'add_key: Package not installed'. This is my sm2 cert: > base64 < sm2.der MIIBbzCCARWgAwIBAgIUfqwndeAy7reymWLwvCHOgYPU2YUwCgYIKoZIzj0EAwIwDTELMAkGA1UE AwwCbWUwHhcNMjEwMTI0MTgwNjQ3WhcNMjIwMTI0MTgwNjQ3WjANMQswCQYDVQQDDAJtZTBZMBMG ByqGSM49AgEGCCqBHM9VAYItA0IABEtiMaczdk46MEugmOsY/u+puf5qoi7JdLd/w3VpdixvDd26 vrxLKL7lCTVn5w3a07G7QB1dgdMDpzIRgWrVXC6jUzBRMB0GA1UdDgQWBBSxOVnE7ihvTb6Nczb4 /mow+HIc9TAfBgNVHSMEGDAWgBSxOVnE7ihvTb6Nczb4/mow+HIc9TAPBgNVHRMBAf8EBTADAQH/ MAoGCCqGSM49BAMCA0gAMEUCIE1kiji2ABUy663NANe0iCPjCeeqg02Yk4b3K+Ci/Qh4AiEA/cFB eJEVklyveRMvuTP7BN7FG4U8iRdtedjiX+YrNio= Regards, Stefan Yes, it works fine here. Your test method may be wrong. First of all, the certificate looks wrong, I don’t know if it is not sent completely. Secondly, the SM2 algorithm must be compiled with builtin. There will be a problem when it is compiled into a module. This is a restriction for SM2 signature with Za. you may refer to this discussion: https://lkml.org/lkml/2021/1/12/1736 In addition, give you a self-signed root certificate for my test: -BEGIN CERTIFICATE- MIICLjCCAdWgAwIBAgIUEoozP6LzMYWh4gCpcWlzsUyfgsIwCgYIKoEcz1UBg3Uw bTELMAkGA1UEBhMCQ04xCzAJBgNVBAgMAkdTMQswCQYDVQQHDAJHdDENMAsGA1UE CgwEYmFiYTELMAkGA1UECwwCT1MxCzAJBgNVBAMMAmNhMRswGQYJKoZIhvcNAQkB FgxjYUB3b3JsZC5jb20wHhcNMjAwNDE1MTE1NDA3WhcNMzAwNDEzMTE1NDA3WjBt MQswCQYDVQQGEwJDTjELMAkGA1UECAwCR1MxCzAJBgNVBAcMAkd0MQ0wCwYDVQQK DARiYWJhMQswCQYDVQQLDAJPUzELMAkGA1UEAwwCY2ExGzAZBgkqhkiG9w0BCQEW DGNhQHdvcmxkLmNvbTBZMBMGByqGSM49AgEGCCqBHM9VAYItA0IABMTGRiHezKm5 MiKHlyfa5Bv5jLxge/WRRG0nLNsZx1yf0XQTQBR/tFFjPGePEr7+Fa1CPgYpXExx i44coYMmQT6jUzBRMB0GA1UdDgQWBBSjd9GWIe98Ll9J0dquxgCktp9DrTAfBgNV HSMEGDAWgBSjd9GWIe98Ll9J0dquxgCktp9DrTAPBgNVHRMBAf8EBTADAQH/MAoG CCqBHM9VAYN1A0cAMEQCIAvLWIfGFq85u/vVMLc5H1D/DnrNS0VhSkQA4daRO4tc AiABbeWENcQZDZLWTuqG9P2KDPOoNqV/QV/+0XjMAVblhg== -END CERTIFICATE- If you can, please add: Tested-by: Tianjia Zhang good luck! Tianjia
Re: [PATCH v10 5/9] x509: Detect sm2 keys by their parameters OID
Hi, On 3/5/21 8:51 AM, Stefan Berger wrote: From: Stefan Berger Detect whether a key is an sm2 type of key by its OID in the parameters array rather than assuming that everything under OID_id_ecPublicKey is sm2, which is not the case. Cc: David Howells Cc: keyri...@vger.kernel.org Signed-off-by: Stefan Berger Reviewed-by: Tianjia Zhang --- crypto/asymmetric_keys/x509_cert_parser.c | 12 +++- include/linux/oid_registry.h | 1 + lib/oid_registry.c| 13 + 3 files changed, 25 insertions(+), 1 deletion(-) diff --git a/crypto/asymmetric_keys/x509_cert_parser.c b/crypto/asymmetric_keys/x509_cert_parser.c index 52c9b455fc7d..1621ceaf5c95 100644 --- a/crypto/asymmetric_keys/x509_cert_parser.c +++ b/crypto/asymmetric_keys/x509_cert_parser.c @@ -459,6 +459,7 @@ int x509_extract_key_data(void *context, size_t hdrlen, const void *value, size_t vlen) { struct x509_parse_context *ctx = context; + enum OID oid; ctx->key_algo = ctx->last_oid; switch (ctx->last_oid) { @@ -470,7 +471,16 @@ int x509_extract_key_data(void *context, size_t hdrlen, ctx->cert->pub->pkey_algo = "ecrdsa"; break; case OID_id_ecPublicKey: - ctx->cert->pub->pkey_algo = "sm2"; + if (parse_OID(ctx->params, ctx->params_size, &oid) != 0) + return -EBADMSG; + + switch (oid) { + case OID_sm2: + ctx->cert->pub->pkey_algo = "sm2"; + break; + default: + return -ENOPKG; + } break; default: return -ENOPKG; diff --git a/include/linux/oid_registry.h b/include/linux/oid_registry.h index b504e2f36b25..f32d91895e4d 100644 --- a/include/linux/oid_registry.h +++ b/include/linux/oid_registry.h @@ -121,6 +121,7 @@ enum OID { }; extern enum OID look_up_OID(const void *data, size_t datasize); +extern int parse_OID(const void *data, size_t datasize, enum OID *oid); extern int sprint_oid(const void *, size_t, char *, size_t); extern int sprint_OID(enum OID, char *, size_t); diff --git a/lib/oid_registry.c b/lib/oid_registry.c index f7ad43f28579..508e0b34b5f0 100644 --- a/lib/oid_registry.c +++ b/lib/oid_registry.c @@ -11,6 +11,7 @@ #include #include #include +#include #include "oid_registry_data.c" MODULE_DESCRIPTION("OID Registry"); @@ -92,6 +93,18 @@ enum OID look_up_OID(const void *data, size_t datasize) } EXPORT_SYMBOL_GPL(look_up_OID); +int parse_OID(const void *data, size_t datasize, enum OID *oid) +{ + const unsigned char *v = data; + + if (datasize < 2 || v[0] != ASN1_OID || v[1] != datasize - 2) + return -EBADMSG; + + *oid = look_up_OID(data + 2, datasize - 2); + return 0; +} +EXPORT_SYMBOL_GPL(parse_OID); + /* * sprint_OID - Print an Object Identifier into a buffer * @data: The encoded OID to print Tested-by: Tianjia Zhang Best regards, Tianjia