Re: [PATCH 1/2] tpm2-sessions: Add full HMAC and encrypt/decrypt session handling

On Fri, Mar 02, 2018 at 10:06:15PM -0800, James Bottomley wrote: > diff --git a/drivers/char/tpm/tpm2b.h b/drivers/char/tpm/tpm2b.h > new file mode 100644 > index ..c7726f2895aa > --- /dev/null > +++ b/drivers/char/tpm/tpm2b.h > @@ -0,0 +1,82 @@ > +/* SPDX-License-Identifier: GPL-2.0

Re: Why are we testing an intermediate result in ahash?

On Fri, Mar 02, 2018 at 03:11:52PM -0600, Gary R Hook wrote: > Commit 466d7b9f6 (cryptodev-2.6) added code to testmgr to populate, for > async hash operations, the result buffer with a known value and to test the > buffer against that value at intermediate steps. If the result buffer > changes the

Re: [PATCH 2/4] crypto: omap-sham - Fix misleading indentation

On 01/03/18 22:50, Krzysztof Kozlowski wrote: Commit 8043bb1ae03c ("crypto: omap-sham - convert driver logic to use sgs for data xmit") removed the if() clause leaving the statement as is. The intention was in that case to finish the request always so the goto instruction seems sensible. Remove

[PATCH] crypto: doc - clarify hash callbacks state machine

Even though it doesn't make too much sense, it is perfectly legal to: - call .init() and then (as many times) .update() - subseqently _not_ call any of .final(), .finup() or .export() Update documentation since this is an important issue to consider from resource management perspective. Link:

Re: Why are we testing an intermediate result in ahash?

On 02.03.2018 22:11, Gary R Hook wrote: > Commit 466d7b9f6 (cryptodev-2.6) added code to testmgr to populate, for async > hash operations, > the result buffer with a known value and to test the buffer against that > value at intermediate > steps. If the result buffer changes the operation is

Re: [PATCH 1/2] tpm2-sessions: Add full HMAC and encrypt/decrypt session handling

On Mon, Mar 05, 2018 at 01:35:33PM +0200, Jarkko Sakkinen wrote: > On Fri, Mar 02, 2018 at 10:06:15PM -0800, James Bottomley wrote: > > diff --git a/drivers/char/tpm/tpm2b.h b/drivers/char/tpm/tpm2b.h > > new file mode 100644 > > index ..c7726f2895aa > > --- /dev/null > > +++

[PATCH][next] crypto: x86/des3_ede: make array des3_ede_skciphers static

From: Colin Ian King The array des3_ede_skciphers is local to the source and does not need to be in global scope, so make it static. Cleans up sparse warning: arch/x86/crypto/des3_ede_glue.c:407:21: warning: symbol 'des3_ede_skciphers' was not declared. Should it be

Re: [RFC 0/2] add integrity and security to TPM2 transactions

On Fri, Mar 02, 2018 at 10:04:54PM -0800, James Bottomley wrote: > By now, everybody knows we have a problem with the TPM2_RS_PW easy > button on TPM2 in that transactions on the TPM bus can be intercepted > and altered.  The way to fix this is to use real sessions for HMAC > capabilities to

Re: [PATCH 1/2] tpm2-sessions: Add full HMAC and encrypt/decrypt session handling

On Mon, 2018-03-05 at 13:35 +0200, Jarkko Sakkinen wrote: > On Fri, Mar 02, 2018 at 10:06:15PM -0800, James Bottomley wrote: > > > > diff --git a/drivers/char/tpm/tpm2b.h b/drivers/char/tpm/tpm2b.h > > new file mode 100644 > > index ..c7726f2895aa > > --- /dev/null > > +++

[PATCH] crypto: ccp: Use memdup_user() rather than duplicating its implementation

From: Markus Elfring Date: Mon, 5 Mar 2018 13:50:13 +0100 Reuse existing functionality from memdup_user() instead of keeping duplicate source code. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring

Re: [RFC 0/2] add integrity and security to TPM2 transactions

On Mon, 2018-03-05 at 07:04 -0700, Jason Gunthorpe wrote: > On Fri, Mar 02, 2018 at 10:04:54PM -0800, James Bottomley wrote: > > > > By now, everybody knows we have a problem with the TPM2_RS_PW easy > > button on TPM2 in that transactions on the TPM bus can be > > intercepted and altered.  The

Re: [PATCH 1/2] tpm2-sessions: Add full HMAC and encrypt/decrypt session handling

On Mon, Mar 05, 2018 at 06:58:32AM -0800, James Bottomley wrote: > On Mon, 2018-03-05 at 13:35 +0200, Jarkko Sakkinen wrote: > > On Fri, Mar 02, 2018 at 10:06:15PM -0800, James Bottomley wrote: > > > > > > diff --git a/drivers/char/tpm/tpm2b.h b/drivers/char/tpm/tpm2b.h > > > new file mode 100644

Re: Why are we testing an intermediate result in ahash?

On 03/05/2018 03:50 AM, Herbert Xu wrote: On Fri, Mar 02, 2018 at 03:11:52PM -0600, Gary R Hook wrote: Commit 466d7b9f6 (cryptodev-2.6) added code to testmgr to populate, for async hash operations, the result buffer with a known value and to test the buffer against that value at intermediate

Re: Why are we testing an intermediate result in ahash?

On 03/05/2018 03:57 AM, Kamil Konieczny wrote: On 02.03.2018 22:11, Gary R Hook wrote: Commit 466d7b9f6 (cryptodev-2.6) added code to testmgr to populate, for async hash operations, the result buffer with a known value and to test the buffer against that value at intermediate steps. If the

Re: Why are we testing an intermediate result in ahash?

On 05.03.2018 18:47, Gary R Hook wrote: > On 03/05/2018 03:57 AM, Kamil Konieczny wrote: >> >> >> On 02.03.2018 22:11, Gary R Hook wrote: >>> Commit 466d7b9f6 (cryptodev-2.6) added code to testmgr to populate, for >>> async hash operations, >>> the result buffer with a known value and to test

[PATCH v11 6/7] crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64

Clean up the extra ifdefs which defined the wr_reg64 and rd_reg64 functions in non-64bit cases in favour of the new common io-64-nonatomic-lo-hi header. To be consistent with CAAM engine HW spec: in case of 64-bit registers, irrespective of device endianness, the lower address should be read from

[PATCH v11 1/7] powerpc: io.h: move iomap.h include so that it can use readq/writeq defs

Subsequent patches in this series makes use of the readq and writeq defines in iomap.h. However, as is, they get missed on the powerpc platform seeing the include comes before the define. This patch moves the include down to fix this. Signed-off-by: Logan Gunthorpe Acked-by:

[PATCH v11 4/7] io-64-nonatomic: add io{read|write}64[be]{_lo_hi|_hi_lo} macros

This patch adds generic io{read|write}64[be]{_lo_hi|_hi_lo} macros if they are not already defined by the architecture. (As they are provided by the generic iomap library). The patch also points io{read|write}64[be] to the variant specified by the header name. This is because new drivers are

[PATCH v11 7/7] ntb: ntb_hw_switchtec: Cleanup 64bit IO defines to use the common header

Clean up the ifdefs which conditionally defined the io{read|write}64 functions in favour of the new common io-64-nonatomic-lo-hi header. Signed-off-by: Logan Gunthorpe Cc: Jon Mason --- drivers/ntb/hw/mscc/ntb_hw_switchtec.c | 30

[PATCH v11 5/7] ntb: ntb_hw_intel: use io-64-nonatomic instead of in-driver hacks

Now that ioread64 and iowrite64 are available in io-64-nonatomic, we can remove the hack at the top of ntb_hw_intel.c and replace it with an include. Signed-off-by: Logan Gunthorpe Reviewed-by: Andy Shevchenko Acked-by: Dave Jiang

[PATCH v11 0/7] Add io{read|write}64 to io-64-atomic headers

This is v11 of my cleanup series to push a number of instances of people defining their own io{read|write}64 functions into common headers seing they don't exist in non-64bit systems. This series adds inline functions to the io-64-nonatomic headers and then cleans up the drivers that defined their

Re: [PATCH] crypto: ccp: Use memdup_user() rather than duplicating its implementation

On 3/5/18 7:10 AM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Mon, 5 Mar 2018 13:50:13 +0100 > > Reuse existing functionality from memdup_user() instead of keeping > duplicate source code. > > This issue was detected by using the Coccinelle software.

[PATCH v11 3/7] iomap: introduce io{read|write}64_{lo_hi|hi_lo}

In order to provide non-atomic functions for io{read|write}64 that will use readq and writeq when appropriate. We define a number of variants of these functions in the generic iomap that will do non-atomic operations on pio but atomic operations on mmio. These functions are only defined if readq

[PATCH v11 2/7] powerpc: iomap.c: introduce io{read|write}64_{lo_hi|hi_lo}

These functions will be introduced into the generic iomap.c so they can deal with PIO accesses in hi-lo/lo-hi variants. Thus, the powerpc version of iomap.c will need to provide the same functions even though, in this arch, they are identical to the regular io{read|write}64 functions.

Re: [PATCH] crypto: ccp: Use memdup_user() rather than duplicating its implementation

On 03/05/2018 07:10 AM, SF Markus Elfring wrote: From: Markus Elfring Date: Mon, 5 Mar 2018 13:50:13 +0100 Reuse existing functionality from memdup_user() instead of keeping duplicate source code. This issue was detected by using the Coccinelle software.

Re: [PATCH 1/2] dt-bindings: rng: Document Freescale i.MX31 RNGA compatible

On Mon, Feb 26, 2018 at 08:38:48PM +0200, Vladimir Zapolskiy wrote: > Freescale i.MX31 SoC contains a Security Random Number Generator > Accelerator module (RNGA), which is replaced by RNGB and RNGC modules > on later i.MX SoC series, the change adds a new compatible property > to describe the

[PATCH v2 0/2] hwrng: mxc-rnga - add driver support on boards with device tree

The series is a trivial change to extend Freescale i.MX31 RNGA driver to work on boards with device description taken from device tree blob. The change was tested on a legacy LogicPD MX31Lite board. Vladimir Zapolskiy (2): dt-bindings: rng: Document Freescale i.MX21 and i.MX31 RNGA compatibles

[PATCH v2 1/2] dt-bindings: rng: Document Freescale i.MX21 and i.MX31 RNGA compatibles

Freescale i.MX21 and i.MX31 SoCs contain a Random Number Generator Accelerator module (RNGA), which is replaced by RNGB and RNGC modules on later i.MX SoC series, the change adds a new compatible property to describe the controller. Since all versions of Freescale RNG modules are legacy,

Re: [PATCH v2 2/2] hwrng: mxc-rnga - add driver support on boards with device tree

Hi Vladimir, On Mon, Mar 5, 2018 at 7:21 PM, Vladimir Zapolskiy wrote: > The driver works well on i.MX31 powered boards with device description > taken from board device tree, the only change to add to the driver is > the missing OF device id, the affected list of included

Re: Why are we testing an intermediate result in ahash?

On 03/05/2018 12:31 PM, Kamil Konieczny wrote: On 05.03.2018 18:47, Gary R Hook wrote: On 03/05/2018 03:57 AM, Kamil Konieczny wrote: On 02.03.2018 22:11, Gary R Hook wrote: Commit 466d7b9f6 (cryptodev-2.6) added code to testmgr to populate, for async hash operations, the result buffer

Re: Why are we testing an intermediate result in ahash?

On 3/5/2018 12:31 PM, Kamil Konieczny wrote: > > > On 05.03.2018 18:47, Gary R Hook wrote: >> On 03/05/2018 03:57 AM, Kamil Konieczny wrote: >>> >>> >>> On 02.03.2018 22:11, Gary R Hook wrote: Commit 466d7b9f6 (cryptodev-2.6) added code to testmgr to populate, for async hash

Re: [PATCH v2 2/2] hwrng: mxc-rnga - add driver support on boards with device tree

Hi Fabio, On 03/06/2018 12:24 AM, Fabio Estevam wrote: > Hi Vladimir, > > On Mon, Mar 5, 2018 at 7:21 PM, Vladimir Zapolskiy wrote: >> The driver works well on i.MX31 powered boards with device description >> taken from board device tree, the only change to add to the driver is

Re: [PATCH v2 2/2] hwrng: mxc-rnga - add driver support on boards with device tree

On Mon, Mar 5, 2018 at 7:21 PM, Vladimir Zapolskiy wrote: > The driver works well on i.MX31 powered boards with device description > taken from board device tree, the only change to add to the driver is > the missing OF device id, the affected list of included headers and >

Re: [PATCH v2 1/2] dt-bindings: rng: Document Freescale i.MX21 and i.MX31 RNGA compatibles

On Mon, Mar 5, 2018 at 7:20 PM, Vladimir Zapolskiy wrote: > Freescale i.MX21 and i.MX31 SoCs contain a Random Number Generator > Accelerator module (RNGA), which is replaced by RNGB and RNGC modules > on later i.MX SoC series, the change adds a new compatible property > to

Re: [PATCH v2 2/2] hwrng: mxc-rnga - add driver support on boards with device tree

Hi Vladimir, On Mon, Mar 5, 2018 at 8:44 PM, Vladimir Zapolskiy wrote: > Yes, I have a pretty good i.MX31 dtsi change (tested everything but USB > and multimedia, and that notorious watchdog problem still has to be > agreed with Uwe and solved), but I'm trying to save my time a

Re: [PATCH 1/2] Documentation: dt: rng: add bindings doc for Keystone SA HWRNG driver

On Thu, Mar 01, 2018 at 07:54:59AM -0500, Vitaly Andrianov wrote: > The Keystone SA module has a hardware random generator module. > This commit adds binding doc for the KS2 SA HWRNG driver. Preferred subject prefix is "dt-bindings: rng: ..." > > Signed-off-by: Vitaly Andrianov

[PATCH v2 1/5] crypto:chelsio: Use kernel round function to align lengths

Replace DIV_ROUND_UP to roundup or rounddown Signed-off-by: Harsh Jain --- drivers/crypto/chelsio/chcr_algo.c | 73 ++ drivers/crypto/chelsio/chcr_algo.h | 1 - 2 files changed, 34 insertions(+), 40 deletions(-) diff --git

[PATCH v2 3/5] crypto:chelsio: Update IV before sending request to HW

CBC Decryption requires Last Block as IV. In case src/dst buffer are same last block will be replaced by plain text. This patch copies the Last Block before sending request to HW. Signed-off-by: Harsh Jain --- drivers/crypto/chelsio/chcr_algo.c | 19 +++ 1

[PATCH v2 4/5] crypto:chelsio: Fix iv passed in fallback path for rfc3686

We use ctr(aes) to fallback rfc3686(ctr) request. Send updated IV to fallback path. Signed-off-by: Harsh Jain --- drivers/crypto/chelsio/chcr_algo.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/crypto/chelsio/chcr_algo.c

Re: [PATCH 0/5] crypto: chelsio - Cleanup and bug fixes

Hi Herbert, Please ignore this series. V2 sent with minor change. On 11-01-2018 16:45, Harsh Jain wrote: > This series include cleanup, bug fixes and authenc algo supporting > ctr(aes)-sha operation. > > Harsh Jain (5): > crypto: chelsio - Fix Indentation > crypto: chelsio - check for sg

[PATCH v2 5/5] crypto:chelsio:Split Hash requests for large scatter gather list

Send multiple WRs to H/W when No. of entries received in scatter list cannot be sent in single request. Signed-off-by: Harsh Jain --- drivers/crypto/chelsio/chcr_algo.c | 358 ++- drivers/crypto/chelsio/chcr_algo.h | 10 +-

[PATCH v2 2/5] crypto:chelsio: Fix src buffer dma length

ulptx header cannot have length > 64k. Adjust length accordingly. Signed-off-by: Harsh Jain --- drivers/crypto/chelsio/chcr_algo.c | 17 - 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/drivers/crypto/chelsio/chcr_algo.c

[PATCH v2 0/5] crypto:chelsio: Bug fixes and cleanup

It includes bug fixes and code cleanup. Changes from v1: Remove Redundant soffset initialisation from 2/5. Harsh Jain (5): crypto:chelsio: Use kernel round function to align lengths crypto:chelsio: Fix src buffer dma length crypto:chelsio: Update IV before sending request to HW

Re: [PATCH v2 0/5] crypto:chelsio: Bug fixes and cleanup

On Tue, Mar 06, 2018 at 10:37:47AM +0530, Harsh Jain wrote: > It includes bug fixes and code cleanup. > > Changes from v1: > > Remove Redundant soffset initialisation from 2/5. Hmm, the first series has already been applied. So if you want to change it then you'll need to send patches based on

Re: Why are we testing an intermediate result in ahash?

On Mon, Mar 05, 2018 at 02:30:57PM -0600, Gary R Hook wrote: > > So a failure to communicate a newly-required behavior change, much less > document it, is addressed by breaking drivers? For some reason this seems > wrong. > > It's also wrong to change the documentation after the fact, and after