Re: [PATCH v5 2/2] hwrng: bcm2835: add reset support

2021-03-04 Thread Philipp Zabel
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

2021-03-04 Thread Alessandrelli, Daniele
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

2021-03-04 Thread Nicolas Saenz Julienne
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

2021-03-04 Thread Nicolas Saenz Julienne
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

2021-03-04 Thread Álvaro Fernández Rojas



> 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

2021-03-04 Thread Nicolas Saenz Julienne
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'

2021-03-04 Thread Dan Carpenter
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

2021-03-04 Thread Stefan Berger

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

2021-03-04 Thread Álvaro Fernández Rojas
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

2021-03-04 Thread Nicolas Saenz Julienne
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)

2021-03-04 Thread Robin Murphy

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

2021-03-04 Thread Thara Gopinath
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

2021-03-04 Thread Rob Herring
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

2021-03-04 Thread Rob Herring
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

2021-03-04 Thread Florian Fainelli
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

2021-03-04 Thread Herbert Xu
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

2021-03-04 Thread Brijesh Singh


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

2021-03-04 Thread Stefan Berger
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

2021-03-04 Thread Stefan Berger
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

2021-03-04 Thread Stefan Berger
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

2021-03-04 Thread Stefan Berger
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

2021-03-04 Thread Stefan Berger
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

2021-03-04 Thread Stefan Berger
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

2021-03-04 Thread Stefan Berger
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

2021-03-04 Thread Stefan Berger
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

2021-03-04 Thread Stefan Berger
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

2021-03-04 Thread Stefan Berger
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

2021-03-04 Thread Stefan Berger

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()

2021-03-04 Thread Jia-Ju Bai
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

2021-03-04 Thread Álvaro Fernández Rojas
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'

2021-03-04 Thread Hui Tang
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

2021-03-04 Thread Hui Tang
'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'

2021-03-04 Thread Hui Tang
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

2021-03-04 Thread Álvaro Fernández Rojas
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

2021-03-04 Thread Álvaro Fernández Rojas
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

2021-03-04 Thread Álvaro Fernández Rojas
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

2021-03-04 Thread Álvaro Fernández Rojas
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

2021-03-04 Thread Tianjia Zhang

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

2021-03-04 Thread Tianjia Zhang

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