* [PATCH 0/3] Fix crypto/vmx/p8_ghash memory corruption
From: Marcelo Cerri @ 2016-09-28 16:42 UTC (permalink / raw)
To: linux-crypto, Herbert Xu
Cc: David S. Miller, Paulo Flabiano Smorigo, Leonidas S. Barbosa,
linuxppc-dev, linux-kernel, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, George Wilson, Marcelo Cerri
This series fixes the memory corruption found by Jan Stancek in 4.8-rc7. The
problem however also affects previous versions of the driver.
Marcelo Cerri (3):
crypto: ghash-generic - move common definitions to a new header file
crypto: vmx - Fix memory corruption caused by p8_ghash
crypto: vmx - Ensure ghash-generic is enabled
crypto/ghash-generic.c | 13 +------------
drivers/crypto/vmx/Kconfig | 2 +-
drivers/crypto/vmx/ghash.c | 31 ++++++++++++++++---------------
include/crypto/ghash.h | 23 +++++++++++++++++++++++
4 files changed, 41 insertions(+), 28 deletions(-)
create mode 100644 include/crypto/ghash.h
--
2.7.4
^ permalink raw reply
* Re: [PATCH 1/2] crypto: ccp - data structure cleanup
From: Tom Lendacky @ 2016-09-28 16:23 UTC (permalink / raw)
To: Gary R Hook, linux-crypto; +Cc: herbert, davem
In-Reply-To: <20160928154921.22138.76929.stgit@taos>
On 09/28/2016 10:49 AM, Gary R Hook wrote:
> Change names of data structure instances; add const
> keyword where appropriate.
>
> Signed-off-by: Gary R Hook <gary.hook@amd.com>
> ---
> drivers/crypto/ccp/ccp-dev-v3.c | 2 +-
> drivers/crypto/ccp/ccp-dev-v5.c | 7 +++++--
> drivers/crypto/ccp/ccp-dev.h | 6 +++---
> drivers/crypto/ccp/ccp-pci.c | 4 ++--
> 4 files changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/crypto/ccp/ccp-dev-v3.c b/drivers/crypto/ccp/ccp-dev-v3.c
> index 578522d..b6615b1 100644
> --- a/drivers/crypto/ccp/ccp-dev-v3.c
> +++ b/drivers/crypto/ccp/ccp-dev-v3.c
> @@ -566,7 +566,7 @@ static const struct ccp_actions ccp3_actions = {
> .irqhandler = ccp_irq_handler,
> };
>
> -struct ccp_vdata ccpv3 = {
> +const struct ccp_vdata ccpv3 = {
> .version = CCP_VERSION(3, 0),
> .setup = NULL,
> .perform = &ccp3_actions,
> diff --git a/drivers/crypto/ccp/ccp-dev-v5.c b/drivers/crypto/ccp/ccp-dev-v5.c
> index 9df1526..a90ca9e 100644
> --- a/drivers/crypto/ccp/ccp-dev-v5.c
> +++ b/drivers/crypto/ccp/ccp-dev-v5.c
> @@ -839,6 +839,9 @@ static int ccp5_init(struct ccp_device *ccp)
>
> return 0;
>
> +e_hwrng:
> + ccp_unregister_rng(ccp);
> +
This label has been added but is never used. I assume that you wanted
to put a goto e_hwrng if ccp_dmaengine_register() fails.
Thanks,
Tom
> e_kthread:
> for (i = 0; i < ccp->cmd_q_count; i++)
> if (ccp->cmd_q[i].kthread)
> @@ -994,7 +997,7 @@ static const struct ccp_actions ccp5_actions = {
> .irqhandler = ccp5_irq_handler,
> };
>
> -struct ccp_vdata ccpv5 = {
> +const struct ccp_vdata ccpv5a = {
> .version = CCP_VERSION(5, 0),
> .setup = ccp5_config,
> .perform = &ccp5_actions,
> @@ -1002,7 +1005,7 @@ struct ccp_vdata ccpv5 = {
> .offset = 0x0,
> };
>
> -struct ccp_vdata ccpv5other = {
> +const struct ccp_vdata ccpv5b = {
> .version = CCP_VERSION(5, 0),
> .setup = ccp5other_config,
> .perform = &ccp5_actions,
> diff --git a/drivers/crypto/ccp/ccp-dev.h b/drivers/crypto/ccp/ccp-dev.h
> index ebc9365..08f58b0 100644
> --- a/drivers/crypto/ccp/ccp-dev.h
> +++ b/drivers/crypto/ccp/ccp-dev.h
> @@ -639,8 +639,8 @@ struct ccp_vdata {
> const unsigned int offset;
> };
>
> -extern struct ccp_vdata ccpv3;
> -extern struct ccp_vdata ccpv5;
> -extern struct ccp_vdata ccpv5other;
> +extern const struct ccp_vdata ccpv3;
> +extern const struct ccp_vdata ccpv5a;
> +extern const struct ccp_vdata ccpv5b;
>
> #endif
> diff --git a/drivers/crypto/ccp/ccp-pci.c b/drivers/crypto/ccp/ccp-pci.c
> index 239cbf2..28a9996 100644
> --- a/drivers/crypto/ccp/ccp-pci.c
> +++ b/drivers/crypto/ccp/ccp-pci.c
> @@ -325,8 +325,8 @@ static int ccp_pci_resume(struct pci_dev *pdev)
>
> static const struct pci_device_id ccp_pci_table[] = {
> { PCI_VDEVICE(AMD, 0x1537), (kernel_ulong_t)&ccpv3 },
> - { PCI_VDEVICE(AMD, 0x1456), (kernel_ulong_t)&ccpv5 },
> - { PCI_VDEVICE(AMD, 0x1468), (kernel_ulong_t)&ccpv5other },
> + { PCI_VDEVICE(AMD, 0x1456), (kernel_ulong_t)&ccpv5a },
> + { PCI_VDEVICE(AMD, 0x1468), (kernel_ulong_t)&ccpv5b },
> /* Last entry must be zero */
> { 0, }
> };
>
^ permalink raw reply
* [PATCH 2/2] crypto: ccp - Improve info reported when an error occurs
From: Gary R Hook @ 2016-09-28 15:49 UTC (permalink / raw)
To: linux-crypto; +Cc: thomas.lendacky, herbert, davem
In-Reply-To: <20160928154921.22138.76929.stgit@taos>
Add human readable strings to log messages about CCP errors
Signed-off-by: Gary R Hook <gary.hook@amd.com>
---
drivers/crypto/ccp/ccp-dev-v3.c | 3 ++
drivers/crypto/ccp/ccp-dev-v5.c | 3 ++
drivers/crypto/ccp/ccp-dev.c | 53 +++++++++++++++++++++++++++++++++++++++
drivers/crypto/ccp/ccp-dev.h | 2 +
4 files changed, 61 insertions(+)
diff --git a/drivers/crypto/ccp/ccp-dev-v3.c b/drivers/crypto/ccp/ccp-dev-v3.c
index b6615b1..8d2dbac 100644
--- a/drivers/crypto/ccp/ccp-dev-v3.c
+++ b/drivers/crypto/ccp/ccp-dev-v3.c
@@ -124,6 +124,9 @@ static int ccp_do_cmd(struct ccp_op *op, u32 *cr, unsigned int cr_count)
/* On error delete all related jobs from the queue */
cmd = (cmd_q->id << DEL_Q_ID_SHIFT)
| op->jobid;
+ if (cmd_q->cmd_error)
+ ccp_log_error(cmd_q->ccp,
+ cmd_q->cmd_error);
iowrite32(cmd, ccp->io_regs + DEL_CMD_Q_JOB);
diff --git a/drivers/crypto/ccp/ccp-dev-v5.c b/drivers/crypto/ccp/ccp-dev-v5.c
index a90ca9e..faf3cb3 100644
--- a/drivers/crypto/ccp/ccp-dev-v5.c
+++ b/drivers/crypto/ccp/ccp-dev-v5.c
@@ -243,6 +243,9 @@ static int ccp5_do_cmd(struct ccp5_desc *desc,
ret = wait_event_interruptible(cmd_q->int_queue,
cmd_q->int_rcvd);
if (ret || cmd_q->cmd_error) {
+ if (cmd_q->cmd_error)
+ ccp_log_error(cmd_q->ccp,
+ cmd_q->cmd_error);
/* A version 5 device doesn't use Job IDs... */
if (!ret)
ret = -EIO;
diff --git a/drivers/crypto/ccp/ccp-dev.c b/drivers/crypto/ccp/ccp-dev.c
index 38a98d8..d9885ce 100644
--- a/drivers/crypto/ccp/ccp-dev.c
+++ b/drivers/crypto/ccp/ccp-dev.c
@@ -40,6 +40,59 @@ struct ccp_tasklet_data {
struct ccp_cmd *cmd;
};
+/* Human-readable error strings */
+char *ccp_error_codes[] = {
+ "",
+ "ERR 01: ILLEGAL_ENGINE",
+ "ERR 02: ILLEGAL_KEY_ID",
+ "ERR 03: ILLEGAL_FUNCTION_TYPE",
+ "ERR 04: ILLEGAL_FUNCTION_MODE",
+ "ERR 05: ILLEGAL_FUNCTION_ENCRYPT",
+ "ERR 06: ILLEGAL_FUNCTION_SIZE",
+ "ERR 07: Zlib_MISSING_INIT_EOM",
+ "ERR 08: ILLEGAL_FUNCTION_RSVD",
+ "ERR 09: ILLEGAL_BUFFER_LENGTH",
+ "ERR 10: VLSB_FAULT",
+ "ERR 11: ILLEGAL_MEM_ADDR",
+ "ERR 12: ILLEGAL_MEM_SEL",
+ "ERR 13: ILLEGAL_CONTEXT_ID",
+ "ERR 14: ILLEGAL_KEY_ADDR",
+ "ERR 15: 0xF Reserved",
+ "ERR 16: Zlib_ILLEGAL_MULTI_QUEUE",
+ "ERR 17: Zlib_ILLEGAL_JOBID_CHANGE",
+ "ERR 18: CMD_TIMEOUT",
+ "ERR 19: IDMA0_AXI_SLVERR",
+ "ERR 20: IDMA0_AXI_DECERR",
+ "ERR 21: 0x15 Reserved",
+ "ERR 22: IDMA1_AXI_SLAVE_FAULT",
+ "ERR 23: IDMA1_AIXI_DECERR",
+ "ERR 24: 0x18 Reserved",
+ "ERR 25: ZLIBVHB_AXI_SLVERR",
+ "ERR 26: ZLIBVHB_AXI_DECERR",
+ "ERR 27: 0x1B Reserved",
+ "ERR 27: ZLIB_UNEXPECTED_EOM",
+ "ERR 27: ZLIB_EXTRA_DATA",
+ "ERR 30: ZLIB_BTYPE",
+ "ERR 31: ZLIB_UNDEFINED_SYMBOL",
+ "ERR 32: ZLIB_UNDEFINED_DISTANCE_S",
+ "ERR 33: ZLIB_CODE_LENGTH_SYMBOL",
+ "ERR 34: ZLIB _VHB_ILLEGAL_FETCH",
+ "ERR 35: ZLIB_UNCOMPRESSED_LEN",
+ "ERR 36: ZLIB_LIMIT_REACHED",
+ "ERR 37: ZLIB_CHECKSUM_MISMATCH0",
+ "ERR 38: ODMA0_AXI_SLVERR",
+ "ERR 39: ODMA0_AXI_DECERR",
+ "ERR 40: 0x28 Reserved",
+ "ERR 41: ODMA1_AXI_SLVERR",
+ "ERR 42: ODMA1_AXI_DECERR",
+ "ERR 43: LSB_PARITY_ERR",
+};
+
+void ccp_log_error(struct ccp_device *d, int e)
+{
+ dev_err(d->dev, "CCP error: %s (0x%x)\n", ccp_error_codes[e], e);
+}
+
/* List of CCPs, CCP count, read-write access lock, and access functions
*
* Lock structure: get ccp_unit_lock for reading whenever we need to
diff --git a/drivers/crypto/ccp/ccp-dev.h b/drivers/crypto/ccp/ccp-dev.h
index 08f58b0..da5f4a6 100644
--- a/drivers/crypto/ccp/ccp-dev.h
+++ b/drivers/crypto/ccp/ccp-dev.h
@@ -601,6 +601,8 @@ void ccp_platform_exit(void);
void ccp_add_device(struct ccp_device *ccp);
void ccp_del_device(struct ccp_device *ccp);
+extern void ccp_log_error(struct ccp_device *, int);
+
struct ccp_device *ccp_alloc_struct(struct device *dev);
bool ccp_queues_suspended(struct ccp_device *ccp);
int ccp_cmd_queue_thread(void *data);
^ permalink raw reply related
* [PATCH] crypto: testmgr - add guard to dst buffer for ahash_export
From: Jan Stancek @ 2016-09-28 14:38 UTC (permalink / raw)
To: linux-crypto, herbert; +Cc: linux-kernel, marcelo.cerri, jstancek
Add a guard to 'state' buffer and warn if its consistency after
call to crypto_ahash_export() changes, so that any write that
goes beyond advertised statesize (and thus causing potential
memory corruption [1]) is more visible.
[1] https://marc.info/?l=linux-crypto-vger&m=147467656516085
Signed-off-by: Jan Stancek <jstancek@redhat.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Marcelo Cerri <marcelo.cerri@canonical.com>
---
crypto/testmgr.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 5c9d5a5e7b65..96343bcae01e 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -209,16 +209,19 @@ static int ahash_partial_update(struct ahash_request **preq,
char *state;
struct ahash_request *req;
int statesize, ret = -EINVAL;
+ const char guard[] = { 0x00, 0xba, 0xad, 0x00 };
req = *preq;
statesize = crypto_ahash_statesize(
crypto_ahash_reqtfm(req));
- state = kmalloc(statesize, GFP_KERNEL);
+ state = kmalloc(statesize + sizeof(guard), GFP_KERNEL);
if (!state) {
pr_err("alt: hash: Failed to alloc state for %s\n", algo);
goto out_nostate;
}
+ memcpy(state + statesize, guard, sizeof(guard));
ret = crypto_ahash_export(req, state);
+ WARN_ON(memcmp(state + statesize, guard, sizeof(guard)));
if (ret) {
pr_err("alt: hash: Failed to export() for %s\n", algo);
goto out;
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] crypto: sha1-powerpc: little-endian support
From: Marcelo Cerri @ 2016-09-28 13:27 UTC (permalink / raw)
To: Herbert Xu
Cc: linux-crypto, linuxppc-dev, linux-kernel, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, George Wilson, Claudio Carvalho,
Paulo Flabiano Smorigo, joy.latten, David S. Miller
In-Reply-To: <20160928132015.GA21312@gondor.apana.org.au>
[-- Attachment #1: Type: text/plain, Size: 586 bytes --]
On Wed, Sep 28, 2016 at 09:20:15PM +0800, Herbert Xu wrote:
> On Wed, Sep 28, 2016 at 10:15:51AM -0300, Marcelo Cerri wrote:
> > Hi Herbert,
> >
> > Any thoughts on this one?
>
> Can this patch wait until the next merge window? On the broken
> platforms it should just fail the self-test, right?
Yes. It fails on any LE platform (including Ubuntu and RHEL 7.1).
>
> Cheers,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
Regards,
Marcelo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7
From: Paulo Flabiano Smorigo @ 2016-09-28 13:22 UTC (permalink / raw)
To: Herbert Xu
Cc: Marcelo Cerri, Jan Stancek, rui y wang, mhcerri, leosilva,
linux-crypto, linuxppc-dev, linux-kernel
In-Reply-To: <20160928123318.GB20839@gondor.apana.org.au>
Wed, Sep 28, 2016 at 08:33:18PM +0800, Herbert Xu wrote:
> On Wed, Sep 28, 2016 at 09:28:44AM -0300, Marcelo Cerri wrote:
> >
> > The big difference between p8_ghash and padlock_sha1 is that
> > padlock_sha1 defines alg->statesize as sizeof(struct sha1_state), which
> > is the descsize value used by sha1_generic. This probably works but
> > it's also wrong because the padlock_sha1 driver does not ensures that
> > sha1_generic is always used.
>
> It should work because all our SHA implementations use the same
> export format. This is not necessarily the case for GHASH though.
>
> > So, one solution is to hardcode ghash-generic as the fallback algorithm
> > and update the descsize direct in its shash_alg structure. There's only
> > one problem with that. ghash-generic desc type (struct ghash_desc_ctx)
> > is not available for vmx_crypto at compile type, the type is defined
> > directly in crypto/ghash-generic.c. That's the reason I added a function
> > to get the fallback desc size at runtime in the patch I wrote as a prove
> > of concept.
>
> The problem with your patch is that there is no guarantee that
> you will get the same algorithm every time you allocate a fallback.
> Someone may have loaded a new module for example.
>
> So I think the safe approach is to stick with ghash-generic and
> expose its state data structure in a header file.
Since generic is the only posible fallback for ppc, I think that's a
good solution. :)
>
> Thanks,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
>
--
Paulo Flabiano Smorigo
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH] crypto: sha1-powerpc: little-endian support
From: Herbert Xu @ 2016-09-28 13:20 UTC (permalink / raw)
To: Marcelo Cerri
Cc: linux-crypto, linuxppc-dev, linux-kernel, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, George Wilson, Claudio Carvalho,
Paulo Flabiano Smorigo, joy.latten, David S. Miller
In-Reply-To: <20160928131551.GA31082@gallifrey>
On Wed, Sep 28, 2016 at 10:15:51AM -0300, Marcelo Cerri wrote:
> Hi Herbert,
>
> Any thoughts on this one?
Can this patch wait until the next merge window? On the broken
platforms it should just fail the self-test, right?
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: sha1-powerpc: little-endian support
From: Marcelo Cerri @ 2016-09-28 13:15 UTC (permalink / raw)
To: Herbert Xu
Cc: linux-crypto, linuxppc-dev, linux-kernel, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, George Wilson, Claudio Carvalho,
Paulo Flabiano Smorigo, joy.latten, David S. Miller
In-Reply-To: <1474659116-4689-1-git-send-email-marcelo.cerri@canonical.com>
[-- Attachment #1: Type: text/plain, Size: 1476 bytes --]
Hi Herbert,
Any thoughts on this one?
--
Regards,
Marcelo
On Fri, Sep 23, 2016 at 04:31:56PM -0300, Marcelo Cerri wrote:
> The driver does not handle endianness properly when loading the input
> data.
>
> Signed-off-by: Marcelo Cerri <marcelo.cerri@canonical.com>
> ---
> arch/powerpc/crypto/sha1-powerpc-asm.S | 13 +++++++++++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/crypto/sha1-powerpc-asm.S b/arch/powerpc/crypto/sha1-powerpc-asm.S
> index 125e165..82ddc9b 100644
> --- a/arch/powerpc/crypto/sha1-powerpc-asm.S
> +++ b/arch/powerpc/crypto/sha1-powerpc-asm.S
> @@ -7,6 +7,15 @@
> #include <asm/ppc_asm.h>
> #include <asm/asm-offsets.h>
>
> +#ifdef __BIG_ENDIAN__
> +#define LWZ(rt, d, ra) \
> + lwz rt,d(ra)
> +#else
> +#define LWZ(rt, d, ra) \
> + li rt,d; \
> + lwbrx rt,rt,ra
> +#endif
> +
> /*
> * We roll the registers for T, A, B, C, D, E around on each
> * iteration; T on iteration t is A on iteration t+1, and so on.
> @@ -23,7 +32,7 @@
> #define W(t) (((t)%16)+16)
>
> #define LOADW(t) \
> - lwz W(t),(t)*4(r4)
> + LWZ(W(t),(t)*4,r4)
>
> #define STEPD0_LOAD(t) \
> andc r0,RD(t),RB(t); \
> @@ -33,7 +42,7 @@
> add r0,RE(t),r15; \
> add RT(t),RT(t),r6; \
> add r14,r0,W(t); \
> - lwz W((t)+4),((t)+4)*4(r4); \
> + LWZ(W((t)+4),((t)+4)*4,r4); \
> rotlwi RB(t),RB(t),30; \
> add RT(t),RT(t),r14
>
> --
> 2.7.4
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7
From: Herbert Xu @ 2016-09-28 13:09 UTC (permalink / raw)
To: Marcelo Cerri
Cc: Jan Stancek, rui y wang, mhcerri, leosilva, pfsmorigo,
linux-crypto, linuxppc-dev, linux-kernel
In-Reply-To: <20160928125558.GE15729@gallifrey>
On Wed, Sep 28, 2016 at 09:55:58AM -0300, Marcelo Cerri wrote:
>
> Great! If we check the descsize every time a fallback tfm is allocated
> that should be enough to prevent bigger problems such as memory
> corruptions.
Yes a check wouldn't hurt.
> Can I move ghash_desc_ctx to a header file under include/crypto/? Or do
> you do you prefer to do that?
No you can go ahead and do the move.
> Maybe include/crypto/internal/hash.h or a new header file
> include/crypto/internal/ghash.h ?
Let's put it in include/crypto/ghash.h.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7
From: Marcelo Cerri @ 2016-09-28 12:55 UTC (permalink / raw)
To: Herbert Xu
Cc: Jan Stancek, rui y wang, mhcerri, leosilva, pfsmorigo,
linux-crypto, linuxppc-dev, linux-kernel
In-Reply-To: <20160928124452.GA21011@gondor.apana.org.au>
[-- Attachment #1: Type: text/plain, Size: 1862 bytes --]
On Wed, Sep 28, 2016 at 08:44:52PM +0800, Herbert Xu wrote:
> On Wed, Sep 28, 2016 at 09:38:41AM -0300, Marcelo Cerri wrote:
> >
> > The patch forces ghash-generic as the fallback. And I don't think that
> > is a big problem if we decide to go by this path.
>
> Right it should work but could break for example if we ever decide
> to change the exported state structure for ghash and someone unloads
> the ghash-generic module and reloads a new one.
>
Great! If we check the descsize every time a fallback tfm is allocated
that should be enough to prevent bigger problems such as memory
corruptions.
> > That would be nice because it would allow p8_ghash to keep using a
> > dynamic fallback, but I'm not that is viable. What do you think?
>
> We did it for SHA because it was desirable to have multiple
> fallbacks, i.e., a generic C version plus an assembly-optimised
> version.
>
> Not sure whether the same motiviation exists for GHASH.
>
> > > Otherwise we can go back to allocating just ghash-generic and
> > > also move its data structure into an exported header file.
> > >
> >
> > That would make the fix much more simple and it wouldn't require to get
> > the fallback descsize at runtime.
>
> This is the easiest fix so let's go with this now. If we ever
> care enough to have multiple fallbacks for GHASH we can always
> revisit this. The exported format is not exposed to user-space
> so it can always be changed.
Can I move ghash_desc_ctx to a header file under include/crypto/? Or do
you do you prefer to do that?
Maybe include/crypto/internal/hash.h or a new header file
include/crypto/internal/ghash.h ?
>
> Cheers,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7
From: Herbert Xu @ 2016-09-28 12:44 UTC (permalink / raw)
To: Marcelo Cerri
Cc: Jan Stancek, rui y wang, mhcerri, leosilva, pfsmorigo,
linux-crypto, linuxppc-dev, linux-kernel
In-Reply-To: <20160928123841.GD15729@gallifrey>
On Wed, Sep 28, 2016 at 09:38:41AM -0300, Marcelo Cerri wrote:
>
> The patch forces ghash-generic as the fallback. And I don't think that
> is a big problem if we decide to go by this path.
Right it should work but could break for example if we ever decide
to change the exported state structure for ghash and someone unloads
the ghash-generic module and reloads a new one.
> That would be nice because it would allow p8_ghash to keep using a
> dynamic fallback, but I'm not that is viable. What do you think?
We did it for SHA because it was desirable to have multiple
fallbacks, i.e., a generic C version plus an assembly-optimised
version.
Not sure whether the same motiviation exists for GHASH.
> > Otherwise we can go back to allocating just ghash-generic and
> > also move its data structure into an exported header file.
> >
>
> That would make the fix much more simple and it wouldn't require to get
> the fallback descsize at runtime.
This is the easiest fix so let's go with this now. If we ever
care enough to have multiple fallbacks for GHASH we can always
revisit this. The exported format is not exposed to user-space
so it can always be changed.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7
From: Marcelo Cerri @ 2016-09-28 12:38 UTC (permalink / raw)
To: Herbert Xu
Cc: Jan Stancek, rui y wang, mhcerri, leosilva, pfsmorigo,
linux-crypto, linuxppc-dev, linux-kernel
In-Reply-To: <20160928122935.GA20839@gondor.apana.org.au>
[-- Attachment #1: Type: text/plain, Size: 1944 bytes --]
Hi Hebert,
On Wed, Sep 28, 2016 at 08:29:35PM +0800, Herbert Xu wrote:
> On Wed, Sep 28, 2016 at 03:40:51AM -0400, Jan Stancek wrote:
> >
> > Thanks for clearing up how this works in padlock-sha, but
> > we are not exactly in same situation with p8_ghash.
> >
> > p8_ghash_init_tfm() already updates descsize. Problem in original report
> > is that without custom export/import/statesize p8_ghash_alg.statesize
> > gets initialized by shash_prepare_alg() to alg->descsize:
>
> Right.
>
> > so I think we need either:
> > 1) make sure p8_ghash_alg.descsize is correct before we register shash,
> > this is what Marcelo's last patch is doing
>
> This approach doesn't work because there is no guarantee that
> you'll get the same fallback the next time you allocate a tfm.
> So relying on the descsize being constant can only work if all
> implementations of the fallback use the same desc struct.
The patch forces ghash-generic as the fallback. And I don't think that
is a big problem if we decide to go by this path.
>
> > 2) provide custom export/import/statesize for p8_ghash_alg
>
> This works for padlock-sha because every implementation of SHA
> uses the same state data structure from sha.h. If we can make
> all implementations of ghash agree on the exported state then
> we can use the same approach.
That would be nice because it would allow p8_ghash to keep using a
dynamic fallback, but I'm not that is viable. What do you think?
>
> Otherwise we can go back to allocating just ghash-generic and
> also move its data structure into an exported header file.
>
That would make the fix much more simple and it wouldn't require to get
the fallback descsize at runtime.
> Cheers,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
Regards,
Marcelo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7
From: Herbert Xu @ 2016-09-28 12:33 UTC (permalink / raw)
To: Marcelo Cerri
Cc: Jan Stancek, rui y wang, mhcerri, leosilva, pfsmorigo,
linux-crypto, linuxppc-dev, linux-kernel
In-Reply-To: <20160928122844.GC15729@gallifrey>
On Wed, Sep 28, 2016 at 09:28:44AM -0300, Marcelo Cerri wrote:
>
> The big difference between p8_ghash and padlock_sha1 is that
> padlock_sha1 defines alg->statesize as sizeof(struct sha1_state), which
> is the descsize value used by sha1_generic. This probably works but
> it's also wrong because the padlock_sha1 driver does not ensures that
> sha1_generic is always used.
It should work because all our SHA implementations use the same
export format. This is not necessarily the case for GHASH though.
> So, one solution is to hardcode ghash-generic as the fallback algorithm
> and update the descsize direct in its shash_alg structure. There's only
> one problem with that. ghash-generic desc type (struct ghash_desc_ctx)
> is not available for vmx_crypto at compile type, the type is defined
> directly in crypto/ghash-generic.c. That's the reason I added a function
> to get the fallback desc size at runtime in the patch I wrote as a prove
> of concept.
The problem with your patch is that there is no guarantee that
you will get the same algorithm every time you allocate a fallback.
Someone may have loaded a new module for example.
So I think the safe approach is to stick with ghash-generic and
expose its state data structure in a header file.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7
From: Herbert Xu @ 2016-09-28 12:29 UTC (permalink / raw)
To: Jan Stancek
Cc: Marcelo Cerri, rui y wang, mhcerri, leosilva, pfsmorigo,
linux-crypto, linuxppc-dev, linux-kernel
In-Reply-To: <1597189480.51836.1475048451846.JavaMail.zimbra@redhat.com>
On Wed, Sep 28, 2016 at 03:40:51AM -0400, Jan Stancek wrote:
>
> Thanks for clearing up how this works in padlock-sha, but
> we are not exactly in same situation with p8_ghash.
>
> p8_ghash_init_tfm() already updates descsize. Problem in original report
> is that without custom export/import/statesize p8_ghash_alg.statesize
> gets initialized by shash_prepare_alg() to alg->descsize:
Right.
> so I think we need either:
> 1) make sure p8_ghash_alg.descsize is correct before we register shash,
> this is what Marcelo's last patch is doing
This approach doesn't work because there is no guarantee that
you'll get the same fallback the next time you allocate a tfm.
So relying on the descsize being constant can only work if all
implementations of the fallback use the same desc struct.
> 2) provide custom export/import/statesize for p8_ghash_alg
This works for padlock-sha because every implementation of SHA
uses the same state data structure from sha.h. If we can make
all implementations of ghash agree on the exported state then
we can use the same approach.
Otherwise we can go back to allocating just ghash-generic and
also move its data structure into an exported header file.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7
From: Marcelo Cerri @ 2016-09-28 12:28 UTC (permalink / raw)
To: Herbert Xu
Cc: Jan Stancek, rui y wang, mhcerri, leosilva, pfsmorigo,
linux-crypto, linuxppc-dev, linux-kernel
In-Reply-To: <20160928024549.GB14034@gondor.apana.org.au>
[-- Attachment #1: Type: text/plain, Size: 1931 bytes --]
Hi Herbert,
On Wed, Sep 28, 2016 at 10:45:49AM +0800, Herbert Xu wrote:
> On Tue, Sep 27, 2016 at 04:46:44PM -0300, Marcelo Cerri wrote:
> >
> > Can you check if the problem occurs with this patch?
>
> In light of the fact that padlock-sha is the correct example
> to follow, you only need to add one line to the init_tfm fucntion
> to update the descsize based on that of the fallback.
>
Not sure if I'm missing something here but p8_ghash already does that:
56 static int p8_ghash_init_tfm(struct crypto_tfm *tfm)
57 {
...
83 shash_tfm->descsize = sizeof(struct p8_ghash_desc_ctx)
84 + crypto_shash_descsize(fallback);
85
86 return 0;
87 }
I think the problem here is that crypto_ahash_statesize uses the
statesize value (that is initialized with the descsize value from
shash_alg) instead of using the value from the tfm that was updated.
For padlock_sha1, it uses the value from alg->statesize since it defines
import and export functions. It doesn't make much difference if it uses
the value from descsize or statesize here, what really matter is that
it uses the value defined in struct shash_alg and not from the tfm.
The big difference between p8_ghash and padlock_sha1 is that
padlock_sha1 defines alg->statesize as sizeof(struct sha1_state), which
is the descsize value used by sha1_generic. This probably works but
it's also wrong because the padlock_sha1 driver does not ensures that
sha1_generic is always used.
So, one solution is to hardcode ghash-generic as the fallback algorithm
and update the descsize direct in its shash_alg structure. There's only
one problem with that. ghash-generic desc type (struct ghash_desc_ctx)
is not available for vmx_crypto at compile type, the type is defined
directly in crypto/ghash-generic.c. That's the reason I added a function
to get the fallback desc size at runtime in the patch I wrote as a prove
of concept.
--
Regards,
Marcelo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* [PATCH] crypto/caam/jr : Unmap region obtained by of_iomap
From: Arvind Yadav @ 2016-09-28 10:31 UTC (permalink / raw)
To: herbert, davem
Cc: alexandru.porosanu, fabio.estevam, horia.geanta, cata.vasile,
linux-crypto, linux-kernel, Arvind Yadav
From: Arvind Yadav <arvind.yadav.cs@gmail.com>
Free memory mapping, if probe is not successful.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
---
drivers/crypto/caam/jr.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/crypto/caam/jr.c b/drivers/crypto/caam/jr.c
index a81f551..9e7f281 100644
--- a/drivers/crypto/caam/jr.c
+++ b/drivers/crypto/caam/jr.c
@@ -513,6 +513,7 @@ static int caam_jr_probe(struct platform_device *pdev)
error = caam_jr_init(jrdev); /* now turn on hardware */
if (error) {
irq_dispose_mapping(jrpriv->irq);
+ iounmap(ctrl);
return error;
}
--
1.7.9.5
^ permalink raw reply related
* Re: [2/2] ath9k: disable RNG by default
From: Kalle Valo @ 2016-09-28 10:00 UTC (permalink / raw)
To: miaoqing pan
Cc: linux-wireless, ath9k-devel, linux-crypto, smueller, jason,
pouyans, Miaoqing Pan
In-Reply-To: <1470726147-30095-2-git-send-email-miaoqing@codeaurora.org>
miaoqing pan <miaoqing@codeaurora.org> wrote:
> From: Miaoqing Pan <miaoqing@codeaurora.org>
>
> ath9k RNG will dominates all the noise sources from the real HW
> RNG, disable it by default. But we strongly recommand to enable
> it if the system without HW RNG, especially on embedded systems.
>
> Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
> Acked-by: Stephan Mueller <smueller@chronox.de>
> Acked-by: Stephan Mueller <smueller@chronox.de>
> Reviewed-by: Jason Cooper <jason@lakedaemon.net>
Patch applied to ath-next branch of ath.git, thanks.
739ccd76b40e ath9k: disable RNG by default
--
https://patchwork.kernel.org/patch/9270467/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7
From: Jan Stancek @ 2016-09-28 8:59 UTC (permalink / raw)
To: Marcelo Cerri
Cc: Herbert Xu, rui y wang, mhcerri, leosilva, pfsmorigo,
linux-crypto, linuxppc-dev, linux-kernel
In-Reply-To: <20160927194644.GB15729@gallifrey>
> Jan,
>
> Can you check if the problem occurs with this patch?
No issues in over-night test with this patch.
> --- a/drivers/crypto/vmx/vmx.c
> +++ b/drivers/crypto/vmx/vmx.c
> @@ -28,6 +28,8 @@
> #include <asm/cputable.h>
> #include <crypto/internal/hash.h>
>
> +int p8_ghash_fallback_descsize(void);
> +
> extern struct shash_alg p8_ghash_alg;
> extern struct crypto_alg p8_aes_alg;
> extern struct crypto_alg p8_aes_cbc_alg;
> @@ -45,6 +47,7 @@ int __init p8_init(void)
> {
> int ret = 0;
> struct crypto_alg **alg_it;
> + int ghash_descsize;
>
> for (alg_it = algs; *alg_it; alg_it++) {
> ret = crypto_register_alg(*alg_it);
> @@ -59,6 +62,12 @@ int __init p8_init(void)
> if (ret)
> return ret;
>
> + ghash_descsize = p8_ghash_fallback_descsize();
> + if (ghash_descsize < 0) {
> + printk(KERN_ERR "Cannot get descsize for p8_ghash fallback\n");
> + return ghash_descsize;
> + }
> + p8_ghash_alg.descsize += ghash_descsize;
> ret = crypto_register_shash(&p8_ghash_alg);
> if (ret) {
> for (alg_it = algs; *alg_it; alg_it++)
I'd suggest to move this inside vmx/ghash.c to a new function, so all p8_ghash
related code is at single place. Then p8_init() would just call the new
function:
- ret = crypto_register_shash(&p8_ghash_alg);
+ ret = register_p8_ghash();
Regards,
Jan
^ permalink raw reply
* Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7
From: Jan Stancek @ 2016-09-28 7:40 UTC (permalink / raw)
To: Herbert Xu
Cc: Marcelo Cerri, rui y wang, mhcerri, leosilva, pfsmorigo,
linux-crypto, linuxppc-dev, linux-kernel
In-Reply-To: <20160928024549.GB14034@gondor.apana.org.au>
----- Original Message -----
> From: "Herbert Xu" <herbert@gondor.apana.org.au>
> To: "Marcelo Cerri" <marcelo.cerri@canonical.com>
> Cc: "Jan Stancek" <jstancek@redhat.com>, "rui y wang" <rui.y.wang@intel.com>, mhcerri@linux.vnet.ibm.com,
> leosilva@linux.vnet.ibm.com, pfsmorigo@linux.vnet.ibm.com, linux-crypto@vger.kernel.org,
> linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
> Sent: Wednesday, 28 September, 2016 4:45:49 AM
> Subject: Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7
>
> On Tue, Sep 27, 2016 at 04:46:44PM -0300, Marcelo Cerri wrote:
> >
> > Can you check if the problem occurs with this patch?
>
> In light of the fact that padlock-sha is the correct example
> to follow, you only need to add one line to the init_tfm fucntion
> to update the descsize based on that of the fallback.
Thanks for clearing up how this works in padlock-sha, but
we are not exactly in same situation with p8_ghash.
p8_ghash_init_tfm() already updates descsize. Problem in original report
is that without custom export/import/statesize p8_ghash_alg.statesize
gets initialized by shash_prepare_alg() to alg->descsize:
crash> p p8_ghash_alg.statesize
$1 = 56
testmgr allocates space for export based on crypto_shash_statesize(),
but shash_default_export() writes based on crypto_shash_descsize():
[ 8.297902] state: c0000004b873aa80, statesize: 56
[ 8.297932] shash_default_export memcpy c0000004b873aa80 c0000004b8607da0, len: 76
so I think we need either:
1) make sure p8_ghash_alg.descsize is correct before we register shash,
this is what Marcelo's last patch is doing
2) provide custom export/import/statesize for p8_ghash_alg
Regards,
Jan
>
> Thanks,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
>
^ permalink raw reply
* Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7
From: Herbert Xu @ 2016-09-28 2:45 UTC (permalink / raw)
To: Marcelo Cerri
Cc: Jan Stancek, rui y wang, mhcerri, leosilva, pfsmorigo,
linux-crypto, linuxppc-dev, linux-kernel
In-Reply-To: <20160927194644.GB15729@gallifrey>
On Tue, Sep 27, 2016 at 04:46:44PM -0300, Marcelo Cerri wrote:
>
> Can you check if the problem occurs with this patch?
In light of the fact that padlock-sha is the correct example
to follow, you only need to add one line to the init_tfm fucntion
to update the descsize based on that of the fallback.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7
From: Herbert Xu @ 2016-09-28 2:44 UTC (permalink / raw)
To: Jan Stancek
Cc: Marcelo Cerri, rui y wang, mhcerri, leosilva, pfsmorigo,
linux-crypto, linuxppc-dev, linux-kernel
In-Reply-To: <346154437.225735.1474966863173.JavaMail.zimbra@redhat.com>
On Tue, Sep 27, 2016 at 05:01:03AM -0400, Jan Stancek wrote:
>
> Also, does that mean that padlock_sha has similar problem?
> It does not seem to reserve any space for fallback __ctx and it calls
> init()/update()/export() with padlock_sha_desc's fallback:
>
> struct padlock_sha_desc {
> struct shash_desc fallback;
> };
>
> static struct shash_alg sha1_alg = {
> .descsize = sizeof(struct padlock_sha_desc),
Actually I was wrong when I said that the API couldn't handle
a dynamic fallback. It can and padlock-sha does the right thing
by updating descsize in the cra_init function.
So this is what vmx should do too.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7
From: Marcelo Cerri @ 2016-09-27 19:46 UTC (permalink / raw)
To: Jan Stancek
Cc: Herbert Xu, rui y wang, mhcerri, leosilva, pfsmorigo,
linux-crypto, linuxppc-dev, linux-kernel
In-Reply-To: <20160927120414.GC21317@gallifrey>
[-- Attachment #1: Type: text/plain, Size: 3002 bytes --]
Jan,
Can you check if the problem occurs with this patch?
---
drivers/crypto/vmx/ghash.c | 28 +++++++++++++++++-----------
drivers/crypto/vmx/vmx.c | 9 +++++++++
2 files changed, 26 insertions(+), 11 deletions(-)
diff --git a/drivers/crypto/vmx/ghash.c b/drivers/crypto/vmx/ghash.c
index 6c999cb0..033aba1 100644
--- a/drivers/crypto/vmx/ghash.c
+++ b/drivers/crypto/vmx/ghash.c
@@ -36,6 +36,8 @@
#define GHASH_DIGEST_SIZE (16)
#define GHASH_KEY_LEN (16)
+#define GHASH_FALLBACK_ALG "ghash-generic"
+
void gcm_init_p8(u128 htable[16], const u64 Xi[2]);
void gcm_gmult_p8(u64 Xi[2], const u128 htable[16]);
void gcm_ghash_p8(u64 Xi[2], const u128 htable[16],
@@ -53,18 +55,26 @@ struct p8_ghash_desc_ctx {
struct shash_desc fallback_desc;
};
+int p8_ghash_fallback_descsize(void)
+{
+ int descsize;
+ struct crypto_shash *fallback;
+ fallback = crypto_alloc_shash(GHASH_FALLBACK_ALG, 0,
+ CRYPTO_ALG_NEED_FALLBACK);
+ if (IS_ERR(fallback)) {
+ return PTR_ERR(fallback);
+ }
+ descsize = crypto_shash_descsize(fallback);
+ crypto_free_shash(fallback);
+ return descsize;
+}
+
static int p8_ghash_init_tfm(struct crypto_tfm *tfm)
{
- const char *alg;
+ const char *alg = GHASH_FALLBACK_ALG;
struct crypto_shash *fallback;
- struct crypto_shash *shash_tfm = __crypto_shash_cast(tfm);
struct p8_ghash_ctx *ctx = crypto_tfm_ctx(tfm);
- if (!(alg = crypto_tfm_alg_name(tfm))) {
- printk(KERN_ERR "Failed to get algorithm name.\n");
- return -ENOENT;
- }
-
fallback = crypto_alloc_shash(alg, 0, CRYPTO_ALG_NEED_FALLBACK);
if (IS_ERR(fallback)) {
printk(KERN_ERR
@@ -79,10 +89,6 @@ static int p8_ghash_init_tfm(struct crypto_tfm *tfm)
crypto_shash_get_flags((struct crypto_shash
*) tfm));
ctx->fallback = fallback;
-
- shash_tfm->descsize = sizeof(struct p8_ghash_desc_ctx)
- + crypto_shash_descsize(fallback);
-
return 0;
}
diff --git a/drivers/crypto/vmx/vmx.c b/drivers/crypto/vmx/vmx.c
index 31a98dc..8a51149 100644
--- a/drivers/crypto/vmx/vmx.c
+++ b/drivers/crypto/vmx/vmx.c
@@ -28,6 +28,8 @@
#include <asm/cputable.h>
#include <crypto/internal/hash.h>
+int p8_ghash_fallback_descsize(void);
+
extern struct shash_alg p8_ghash_alg;
extern struct crypto_alg p8_aes_alg;
extern struct crypto_alg p8_aes_cbc_alg;
@@ -45,6 +47,7 @@ int __init p8_init(void)
{
int ret = 0;
struct crypto_alg **alg_it;
+ int ghash_descsize;
for (alg_it = algs; *alg_it; alg_it++) {
ret = crypto_register_alg(*alg_it);
@@ -59,6 +62,12 @@ int __init p8_init(void)
if (ret)
return ret;
+ ghash_descsize = p8_ghash_fallback_descsize();
+ if (ghash_descsize < 0) {
+ printk(KERN_ERR "Cannot get descsize for p8_ghash fallback\n");
+ return ghash_descsize;
+ }
+ p8_ghash_alg.descsize += ghash_descsize;
ret = crypto_register_shash(&p8_ghash_alg);
if (ret) {
for (alg_it = algs; *alg_it; alg_it++)
--
2.7.4
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply related
* Re: [BUG] crypto: atmel-aes - erro when compiling with VERBOSE_DEBUG enable
From: Cyrille Pitchen @ 2016-09-27 16:45 UTC (permalink / raw)
To: levent demir, Herbert Xu; +Cc: linux-crypto
In-Reply-To: <1474548357.12981.19.camel@inria.fr>
Hi Levent,
there is a typo in the subject line: erroR.
Also it would be better to start the summary phrase of the subject line with a
verb:
crypto: atmel-aes: fix compiler error when VERBODE_DEBUG is defined
Le 22/09/2016 à 14:45, levent demir a écrit :
> Fix debug function call in atmel_aes_write
>
> Signed-off-by: Levent DEMIR <levent.demir@inria.fr>
> ---
> drivers/crypto/atmel-aes.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/crypto/atmel-aes.c b/drivers/crypto/atmel-aes.c
> index e3d40a8..2b0f926 100644
> --- a/drivers/crypto/atmel-aes.c
> +++ b/drivers/crypto/atmel-aes.c
> @@ -317,7 +317,7 @@ static inline void atmel_aes_write(struct
> atmel_aes_dev *dd,
> char tmp[16];
>
> dev_vdbg(dd->dev, "write 0x%08x into %s\n", value,
> - atmel_aes_reg_name(offset, tmp));
> + atmel_aes_reg_name(offset, tmp, sizeof(tmp)));
It looks like a space has been removed.
> }
> #endif /* VERBOSE_DEBUG */
>
>
Best regards,
Cyrille
^ permalink raw reply
* Re: [v2] RANDOM: ATH9K RNG delivers zero bits of entropy
From: Stephan Mueller @ 2016-09-27 15:17 UTC (permalink / raw)
To: Kalle Valo
Cc: Ted Tso, herbert, linux-kernel, linux-crypto, ath9k-devel,
linux-wireless, ath9k-devel, Kalle Valo, Jason Cooper
In-Reply-To: <2ba03f89daee4f09a88a1238943eb49d@euamsexm01a.eu.qualcomm.com>
Am Dienstag, 27. September 2016, 16:44:16 CEST schrieb Kalle Valo:
Hi Kalle,
> Stephan Mueller <smueller@chronox.de> wrote:
> > The ATH9K driver implements an RNG which is completely bypassing the
> > standard Linux HW generator logic.
> >
> > The RNG may or may not deliver entropy. Considering the conservative
> > approach in treating entropy with respect to non-auditable sources, this
> > patch changes the delivered entropy value to zero. The RNG still feeds
> > data into the input_pool but it is assumed to have no entropy.
> >
> > When the ATH9K RNG changes to use the HW RNG framework, it may re-enable
> > the entropy estimation considering that a user can change that value at
> > boot and runtime.
> >
> > Reviewed-by: Jason Cooper <jason@lakedaemon.net>
> > Signed-off-by: Stephan Mueller <smueller@chronox.de>
>
> Based on the discussion I'm dropping this patch. But the discussion was
> hard to follow so please let me know if I misunderstood.
I guess the rejection is appropriate, but something needs to be done:
add_hwgenerator_randomness should not be used in this scenario.
>
> Patch set to Rejected.
Ciao
Stephan
^ permalink raw reply
* Re: [1/2] ath9k: change entropy formula for easier understanding
From: Kalle Valo @ 2016-09-27 14:53 UTC (permalink / raw)
To: miaoqing pan
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
ath9k-devel-A+ZNKFmMK5xy9aJCnZT0Uw,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
smueller-T9tCv8IpfcWELgA04lAiVw, jason-NLaQJdtUoK4Be96aLqz0jA,
pouyans-Rm6X0d1/PG5y9aJCnZT0Uw, Miaoqing Pan
In-Reply-To: <1470726147-30095-1-git-send-email-miaoqing-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
miaoqing pan <miaoqing-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> wrote:
> From: Miaoqing Pan <miaoqing-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>
> The quality of ADC entropy is 10 bits of min-entropy for
> a 32-bit value, change '(((x) * 8 * 320) >> 10)' to
> '(((x) * 8 * 10) >> 5)' for easier understanding.
>
> Signed-off-by: Miaoqing Pan <miaoqing-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
I need some help here, it this patch ok to take or should I drop it? The
discussion is available from the patchwork link below if someone needs to
refresh the memory.
--
https://patchwork.kernel.org/patch/9270463/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox