* [PATCH 0/4] STM32 CRC crypto driver
From: Fabien Dessenne @ 2017-03-14 16:37 UTC (permalink / raw)
To: Herbert Xu, David S . Miller, Rob Herring, Mark Rutland,
Maxime Coquelin, Alexandre Torgue, Russell King,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
This set of patches adds a new crypto driver for STMicroelectronics stm32f746.
The drivers uses the crypto API and provides with an HW-enabled CRC32 algorithm.
It was developed and tested (tcrypt / testmgr) on evaluation board stm32746g.
Fabien Dessenne (4):
dt-bindings: Document STM32 CRC bindings
crypto: stm32 - Support for STM32 CRC32 crypto module
ARM: dts: stm32: Add CRC support to stm32f746
ARM: dts: stm32: enable CRC on stm32746g-eval board
.../devicetree/bindings/crypto/st,stm32-crc.txt | 16 +
arch/arm/boot/dts/stm32746g-eval.dts | 4 +
arch/arm/boot/dts/stm32f746.dtsi | 7 +
drivers/crypto/Kconfig | 2 +
drivers/crypto/Makefile | 1 +
drivers/crypto/stm32/Kconfig | 8 +
drivers/crypto/stm32/Makefile | 2 +
drivers/crypto/stm32/stm32_crc32.c | 325 +++++++++++++++++++++
8 files changed, 365 insertions(+)
create mode 100644 Documentation/devicetree/bindings/crypto/st,stm32-crc.txt
create mode 100644 drivers/crypto/stm32/Kconfig
create mode 100644 drivers/crypto/stm32/Makefile
create mode 100644 drivers/crypto/stm32/stm32_crc32.c
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: crypto: deadlock between crypto_alg_sem/rtnl_mutex/genl_mutex
From: Sowmini Varadhan @ 2017-03-14 15:25 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Herbert Xu, David Miller, linux-crypto, LKML, Eric Dumazet,
Cong Wang, netdev, santosh.shilimkar, rds-devel, syzkaller
In-Reply-To: <CACT4Y+YTBPDMOZGMLuZPaQhSFXbeQeahHc8BUDOgNYm6hRy6fw@mail.gmail.com>
On (03/14/17 09:14), Dmitry Vyukov wrote:
> Another one now involving rds_tcp_listen_stop
:
> kworker/u4:1/19 is trying to acquire lock:
> (sk_lock-AF_INET){+.+.+.}, at: [<ffffffff8409a6ec>] lock_sock
> include/net/sock.h:1460 [inline]
> (sk_lock-AF_INET){+.+.+.}, at: [<ffffffff8409a6ec>]
> rds_tcp_listen_stop+0x5c/0x150 net/rds/tcp_listen.c:288
>
> but task is already holding lock:
> (rtnl_mutex){+.+.+.}, at: [<ffffffff8370b057>] rtnl_lock+0x17/0x20
> net/core/rtnetlink.c:70
Is this also a false positive?
genl_lock_dumpit takes the genl_lock and then waits on the rtnl_lock
(e.g., out of tipc_nl_bearer_dump).
netdev_run_todo takes the rtnl_lock and then wants lock_sock()
for the TCP/IPv4 socket.
Why is lockdep seeing a circular dependancy here? Same pattern
seems to be happening for
http://www.spinics.net/lists/netdev/msg423368.html
and maybe also http://www.spinics.net/lists/netdev/msg423323.html?
--Sowmini
> Chain exists of:
> sk_lock-AF_INET --> genl_mutex --> rtnl_mutex
>
> Possible unsafe locking scenario:
>
> CPU0 CPU1
> ---- ----
> lock(rtnl_mutex);
> lock(genl_mutex);
> lock(rtnl_mutex);
> lock(sk_lock-AF_INET);
>
> *** DEADLOCK ***
>
> 4 locks held by kworker/u4:1/19:
> #0: ("%s""netns"){.+.+.+}, at: [<ffffffff81497943>]
> __write_once_size include/linux/compiler.h:283 [inline]
> #0: ("%s""netns"){.+.+.+}, at: [<ffffffff81497943>] atomic64_set
> arch/x86/include/asm/atomic64_64.h:33 [inline]
> #0: ("%s""netns"){.+.+.+}, at: [<ffffffff81497943>] atomic_long_set
> include/asm-generic/atomic-long.h:56 [inline]
> #0: ("%s""netns"){.+.+.+}, at: [<ffffffff81497943>] set_work_data
> kernel/workqueue.c:617 [inline]
> #0: ("%s""netns"){.+.+.+}, at: [<ffffffff81497943>]
> set_work_pool_and_clear_pending kernel/workqueue.c:644 [inline]
> #0: ("%s""netns"){.+.+.+}, at: [<ffffffff81497943>]
> process_one_work+0xab3/0x1c10 kernel/workqueue.c:2089
> #1: (net_cleanup_work){+.+.+.}, at: [<ffffffff81497997>]
> process_one_work+0xb07/0x1c10 kernel/workqueue.c:2093
> #2: (net_mutex){+.+.+.}, at: [<ffffffff836965cb>]
> cleanup_net+0x22b/0xa90 net/core/net_namespace.c:429
> #3: (rtnl_mutex){+.+.+.}, at: [<ffffffff8370b057>]
> rtnl_lock+0x17/0x20 net/core/rtnetlink.c:70
>
^ permalink raw reply
* Re: [PATCH V2 2/3] crypto: ccp - Enable support for AES GCM on v5 CCPs
From: Stephan Müller @ 2017-03-14 15:09 UTC (permalink / raw)
To: Gary R Hook; +Cc: Hook, Gary, linux-crypto@vger.kernel.org
In-Reply-To: <58e1a934-4007-1ac3-8588-8267436c62b6@amd.com>
Am Dienstag, 14. März 2017, 15:34:00 CET schrieb Gary R Hook:
Hi Gary,
> On 03/14/2017 02:17 AM, Stephan Müller wrote:
> > Am Montag, 13. März 2017, 20:35:07 CET schrieb Gary R Hook:
> >
> > Hi Gary,
>
> Is it acceptable to snip stuff out? Most of this code seems irrelevant
> to this discussion....
Let us snip it :-)
> >> >
> >> > But then, the key is 4 bytes longer than a normal AES key as it
> >> > contains
> >> > the leading 32 bits of the IV.
> >>
> >> I had my wires crossed due to an incomplete understanding of an AEAD
> >> cipher
> >> in general, and GCM in particular. I'm hopeful that someone can help me
> >> understand:
> >>
> >> For the AES GCM encryption tests in testmgr.h, where there is an IV,
> >> they're all
> >> 12 bytes in length. As I understand AES GCM the IV can be anywhere from
> >> 1 to 2^64
> >> bits in length; the value of 96 makes for convenience and efficiency.
> >> But it's
> >> neither a requirement nor restriction.
> >
> > That is correct. For longer IVs, you would need to use Ghash to compress
> > it to
> > 96 bits. The remaining 32 bits to get to one AES block is the counter
> > that is
> > used for the CTR AES mode in GCM.
>
> Yes, understood. It's all falling into place now. What seems to be missing
> (to me) is a way for the transform to indicate that it allows all valid
> (GCM)
> IV lengths, as opposed to the (specified in the data structure) 12 bytes.
The kernel crypto API does not support varying IV sizes. So, simply stay with
12 / 8 bytes as explained should suffice.
> I
> get the context of IPSec, but I would think AF_ALG allowing access to the
> transforms means that we can't rely upon a context. And there seems to be no
> way for an implementation to let a user know about any IV restrictions (or
> not).
In algif_aead, we simply have:
unsigned ivsize =
crypto_aead_ivsize(crypto_aead_reqtfm(&ctx->aead_req));
...
if (con.iv && con.iv->ivlen != ivsize)
return -EINVAL;
Thus, if the user space caller does not provide exactly ivsize bytes of IV, he
gets an error.
>
> Do we just let the implementation return an error when it can't handle
> something?
>
> Or (highly possible) am I missing the obvious?
>
> >> There are no tests (in testmgr.h) that use an IV length other than 0 or
> >> 96.>
> > See aes_gcm_rfc4106_enc_tv_template for other types of IV.
>
> All 8 bytes, it seems, which makes sense for 4106.
>
> >> My comment about RFC4106 has to do with requiring an IV 0f 96 bits + a
> >> word
> >> that
> >> is incremented for each block (making every nonce unique, per the
> >> requirement).
> >> But let's ignore that, please.
> >>
> >> It looks as if:
> >>
> >> What seems to be missing is the ability to register a (GCM) transform
> >> that can
> >> handle an IV of arbitrary (allowable) length. I have to specify the
> >> length (ivsize)
> >> when I register an algorithm, and everything I see in the existing code
> >> appears
> >> to expect a GCM ivsize to be 96 bits, period (or zero). This is what I
> >> meant when
> >> I referenced RFC4106: I perceive restrictions not in my code, but n the
> >> way GCM seems
> >> to be supported in the crypto AEAD framework. A complete GCM
> >> implementation would not
> >> seem to have a restriction to a specific IV length (rather, a range of
> >> allowed
> >> values).
> >
> > 96 bits is the use case in IPSEC. As the kernel crypto API transforms
> > are used
> > for IPSEC. Nobody would prevent you from supporting other IV sizes. But
> > then
> > you would need to add a Ghash operation to compress it to the right
> > length. No
> > other GCM implementation has that and hence the limitation.
>
> Of course. That's the component that I'm missing, and I want to understand
> whether there's a compelling need.
I would not think that there is any need for it. If there would be, a generic
helper for the IV compression should be added instead of having the algos
implementing it itself over and over again.
>
> > But 96 bits is not the common case. See the 4106 implementations, you
> > see the
> > ivsize being 8. This is correct because setkey requires AES keysize + 4
> > bytes
> > in length (see crypto_rfc4106_setkey for an example). The trailing 4
> > bytes of
> > the key are the initial 4 bytes of the GCM IV.
>
> Yes. The RFC4106 document is pretty clear on the layout of the IV.
>
> > My comment was about your comment to refer to RFC4106. I just wanted to
> > understand your code and and make sense of your comments. :-)
> >
> >> Is my reading of the GCM description in error? Do we need/want the
> >> ability
> >> to have a flexible IV length for GCM? What am I not understanding?
> >
> > In your case, just change the wording in the comment slightly and we are
> > all good.
>
> Will do. I appreciate the discussion! Very helpful.
>
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH V2 2/3] crypto: ccp - Enable support for AES GCM on v5 CCPs
From: Gary R Hook @ 2017-03-14 14:34 UTC (permalink / raw)
To: Stephan Müller, Hook, Gary; +Cc: linux-crypto@vger.kernel.org
In-Reply-To: <4585707.bK1Ho6b7OP@tauon.atsec.com>
On 03/14/2017 02:17 AM, Stephan Müller wrote:
> Am Montag, 13. März 2017, 20:35:07 CET schrieb Gary R Hook:
>
> Hi Gary,
Is it acceptable to snip stuff out? Most of this code seems irrelevant
to this discussion....
>
>> On 03/03/2017 7:15 AM, Stephan Mueller wrote:
>> > Am Donnerstag, 2. März 2017, 22:26:54 CET schrieb Gary R Hook:
>> >
>> > Hi Gary,
>>
>> Thanks for your comments, Stephan.
>>
>> > > A version 5 device provides the primitive commands
>> > > required for AES GCM. This patch adds support for
>> > > en/decryption.
>> > >
>> > > Signed-off-by: Gary R Hook <gary.hook@amd.com>
>> > > ---
>> > >
>> > > drivers/crypto/ccp/Makefile | 1
>> > > drivers/crypto/ccp/ccp-crypto-aes-galois.c | 257
>> > >
>> > > ++++++++++++++++++++++++++++ drivers/crypto/ccp/ccp-crypto-main.c
>> > > |
>> > > 12 +
>> > >
>> > > drivers/crypto/ccp/ccp-crypto.h | 14 ++
>> > > drivers/crypto/ccp/ccp-dev-v5.c | 2
>> > > drivers/crypto/ccp/ccp-dev.h | 1
>> > > drivers/crypto/ccp/ccp-ops.c | 252
>> > >
>> > > +++++++++++++++++++++++++++ include/linux/ccp.h |
>> > > 9 +
>> > >
>> > > 8 files changed, 548 insertions(+)
>> > > create mode 100644 drivers/crypto/ccp/ccp-crypto-aes-galois.c
>> > >
>> > > diff --git a/drivers/crypto/ccp/ccp-crypto-aes-galois.c
>> > > b/drivers/crypto/ccp/ccp-crypto-aes-galois.c new file mode 100644
>> > > index 0000000..8bc18c9
>> > > --- /dev/null
>> > > +++ b/drivers/crypto/ccp/ccp-crypto-aes-galois.c
>> > > @@ -0,0 +1,257 @@
>> > > +/*
>> > > + * AMD Cryptographic Coprocessor (CCP) AES GCM crypto API support
>> > > + *
>> > > + * Copyright (C) 2016 Advanced Micro Devices, Inc.
>> > > + *
>> > > + * Author: Gary R Hook <gary.hook@amd.com>
>> > > + *
>> > > + * This program is free software; you can redistribute it and/or modify
>> > > + * it under the terms of the GNU General Public License version 2 as
>> > > + * published by the Free Software Foundation.
>> > > + */
>> > > +
>> > > +#include <linux/module.h>
>> > > +#include <linux/sched.h>
>> > > +#include <linux/delay.h>
>> > > +#include <linux/scatterlist.h>
>> > > +#include <linux/crypto.h>
>> > > +#include <crypto/internal/aead.h>
>> > > +#include <crypto/algapi.h>
>> > > +#include <crypto/aes.h>
>> > > +#include <crypto/ctr.h>
>> > > +#include <crypto/scatterwalk.h>
>> > > +#include <linux/delay.h>
>> > > +
>> > > +#include "ccp-crypto.h"
>> > > +
>> > > +#define AES_GCM_IVSIZE 12
>> > > +
>> > > +static int ccp_aes_gcm_complete(struct crypto_async_request *async_req,
>> > > int ret) +{
>> > > + return ret;
>> > > +}
>> > > +
>> > > +static int ccp_aes_gcm_setkey(struct crypto_aead *tfm, const u8 *key,
>> > > + unsigned int key_len)
>> > > +{
>> > > + struct ccp_ctx *ctx = crypto_aead_ctx(tfm);
>> > > +
>> > > + switch (key_len) {
>> > > + case AES_KEYSIZE_128:
>> > > + ctx->u.aes.type = CCP_AES_TYPE_128;
>> > > + break;
>> > > + case AES_KEYSIZE_192:
>> > > + ctx->u.aes.type = CCP_AES_TYPE_192;
>> > > + break;
>> > > + case AES_KEYSIZE_256:
>> > > + ctx->u.aes.type = CCP_AES_TYPE_256;
>> > > + break;
>> > > + default:
>> > > + crypto_aead_set_flags(tfm, CRYPTO_TFM_RES_BAD_KEY_LEN);
>> > > + return -EINVAL;
>> > > + }
>> > > +
>> > > + ctx->u.aes.mode = CCP_AES_MODE_GCM;
>> > > + ctx->u.aes.key_len = key_len;
>> > > +
>> > > + memcpy(ctx->u.aes.key, key, key_len);
>> > > + sg_init_one(&ctx->u.aes.key_sg, ctx->u.aes.key, key_len);
>> > > +
>> > > + return 0;
>> > > +}
>> > > +
>> > > +static int ccp_aes_gcm_setauthsize(struct crypto_aead *tfm,
>> > > + unsigned int authsize)
>> > > +{
>> > > + return 0;
>> > > +}
>> > > +
>> > > +static int ccp_aes_gcm_crypt(struct aead_request *req, bool encrypt)
>> > > +{
>> > > + struct crypto_aead *tfm = crypto_aead_reqtfm(req);
>> > > + struct ccp_ctx *ctx = crypto_aead_ctx(tfm);
>> > > + struct ccp_aes_req_ctx *rctx = aead_request_ctx(req);
>> > > + struct scatterlist *iv_sg = NULL;
>> > > + unsigned int iv_len = 0;
>> > > + int i;
>> > > + int ret = 0;
>> > > +
>> > > + if (!ctx->u.aes.key_len)
>> > > + return -EINVAL;
>> > > +
>> > > + if (ctx->u.aes.mode != CCP_AES_MODE_GCM)
>> > > + return -EINVAL;
>> > > +
>> > > + if (!req->iv)
>> > > + return -EINVAL;
>> > > +
>> > > + /*
>> > > + * 5 parts:
>> > > + * plaintext/ciphertext input
>> > > + * AAD
>> > > + * key
>> > > + * IV
>> > > + * Destination+tag buffer
>> > > + */
>> > > +
>> > > + /* According to the way AES GCM has been implemented here,
>> > > + * per RFC 4106 it seems, the provided IV is fixed at 12 bytes,
>> >
>> > When you have that restriction, should the cipher be called
>> > rfc4106(gcm(aes))?
>> >
>> > But then, the key is 4 bytes longer than a normal AES key as it contains
>> > the leading 32 bits of the IV.
>>
>> I had my wires crossed due to an incomplete understanding of an AEAD cipher
>> in general, and GCM in particular. I'm hopeful that someone can help me
>> understand:
>>
>> For the AES GCM encryption tests in testmgr.h, where there is an IV,
>> they're all
>> 12 bytes in length. As I understand AES GCM the IV can be anywhere from
>> 1 to 2^64
>> bits in length; the value of 96 makes for convenience and efficiency.
>> But it's
>> neither a requirement nor restriction.
>
> That is correct. For longer IVs, you would need to use Ghash to compress
> it to
> 96 bits. The remaining 32 bits to get to one AES block is the counter
> that is
> used for the CTR AES mode in GCM.
Yes, understood. It's all falling into place now. What seems to be missing
(to me) is a way for the transform to indicate that it allows all valid
(GCM)
IV lengths, as opposed to the (specified in the data structure) 12 bytes. I
get the context of IPSec, but I would think AF_ALG allowing access to the
transforms means that we can't rely upon a context. And there seems to be no
way for an implementation to let a user know about any IV restrictions
(or not).
Do we just let the implementation return an error when it can't handle
something?
Or (highly possible) am I missing the obvious?
>> There are no tests (in testmgr.h) that use an IV length other than 0 or 96.
>
> See aes_gcm_rfc4106_enc_tv_template for other types of IV.
All 8 bytes, it seems, which makes sense for 4106.
>> My comment about RFC4106 has to do with requiring an IV 0f 96 bits + a word
>> that
>> is incremented for each block (making every nonce unique, per the
>> requirement).
>> But let's ignore that, please.
>>
>> It looks as if:
>>
>> What seems to be missing is the ability to register a (GCM) transform
>> that can
>> handle an IV of arbitrary (allowable) length. I have to specify the
>> length (ivsize)
>> when I register an algorithm, and everything I see in the existing code
>> appears
>> to expect a GCM ivsize to be 96 bits, period (or zero). This is what I
>> meant when
>> I referenced RFC4106: I perceive restrictions not in my code, but n the
>> way GCM seems
>> to be supported in the crypto AEAD framework. A complete GCM
>> implementation would not
>> seem to have a restriction to a specific IV length (rather, a range of
>> allowed
>> values).
>
> 96 bits is the use case in IPSEC. As the kernel crypto API transforms
> are used
> for IPSEC. Nobody would prevent you from supporting other IV sizes. But
> then
> you would need to add a Ghash operation to compress it to the right
> length. No
> other GCM implementation has that and hence the limitation.
Of course. That's the component that I'm missing, and I want to understand
whether there's a compelling need.
> But 96 bits is not the common case. See the 4106 implementations, you
> see the
> ivsize being 8. This is correct because setkey requires AES keysize + 4
> bytes
> in length (see crypto_rfc4106_setkey for an example). The trailing 4
> bytes of
> the key are the initial 4 bytes of the GCM IV.
Yes. The RFC4106 document is pretty clear on the layout of the IV.
> My comment was about your comment to refer to RFC4106. I just wanted to
> understand your code and and make sense of your comments. :-)
>>
>> Is my reading of the GCM description in error? Do we need/want the ability
>> to have a flexible IV length for GCM? What am I not understanding?
>
> In your case, just change the wording in the comment slightly and we are
> all good.
Will do. I appreciate the discussion! Very helpful.
>>
>> For reference, I'm working from the NIST doc:
>> http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/gcm/gcm-s
>> pec.pdf
>
>>
>> > > + rctx->cmd.u.aes.key = &ctx->u.aes.key_sg;
>> > > + rctx->cmd.u.aes.key_len = ctx->u.aes.key_len;
>> > > + rctx->cmd.u.aes.iv = iv_sg;
>> > > + rctx->cmd.u.aes.iv_len = iv_len;
>> > > + rctx->cmd.u.aes.src = req->src;
>> > > + rctx->cmd.u.aes.src_len = req->cryptlen;
>> > > + rctx->cmd.u.aes.aad_len = req->assoclen;
>> >
>> > Just to be on the safe side: is the implementation good when cryptlen or
>> > assoclen is 0?
>>
>> The engine has been designed to handle those two conditions. I've been
>> watching the discussions around these issues.
>>
>> The first encryption test in testmgr.h has no input data nor IV. This
>> implementation passes that test.
>>
>> The second encryption test in testmgr.h has input data but no IV, and this
>> implementation passes.
>>
>> Is that an acceptable validation, or do we need more?
>
> I would recommend at least a private test with no input and no AAD (i.e.
> authentication only).
>
> Maybe you can add a patch to testmgr for this case. An example is found at
> [1]. Here, tag and exp is the expected result of the operation.
>
> [1] https://github.com/smuellerDD/libkcapi/blob/master/test/test.sh#L330
>>
>> Thanks,
>> Gary
>
>
>
> Ciao
> Stephan
--
This is my day job. Follow me at:
IG/Twitter/Facebook: @grhookphoto
IG/Twitter/Facebook: @grhphotographer
^ permalink raw reply
* [PATCH 2/2] hwrng: geode - Revert managed API changes
From: Prarit Bhargava @ 2017-03-14 11:36 UTC (permalink / raw)
To: linux-kernel
Cc: Prarit Bhargava, Matt Mackall, Herbert Xu, Corentin LABBE,
PrasannaKumar Muralidharan, Wei Yongjun, linux-crypto,
linux-geode
In-Reply-To: <1489491362-26339-1-git-send-email-prarit@redhat.com>
After commit e9afc746299d ("hwrng: geode - Use linux/io.h instead of
asm/io.h") the geode-rng driver uses devres with pci_dev->dev to keep
track of resources, but does not actually register a PCI driver. This
results in the following issues:
1. The driver leaks memory because the driver does not attach to a
device. The driver only uses the PCI device as a reference. devm_*()
functions will release resources on driver detach, which the geode-rng
driver will never do. As a result,
2. The driver cannot be reloaded because there is always a use of the
ioport and region after the first load of the driver.
Revert the changes made by e9afc746299d ("hwrng: geode - Use linux/io.h
instead of asm/io.h").
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Fixes: 6e9b5e76882c ("hwrng: geode - Migrate to managed API")
Cc: Matt Mackall <mpm@selenic.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Corentin LABBE <clabbe.montjoie@gmail.com>
Cc: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
Cc: Wei Yongjun <weiyongjun1@huawei.com>
Cc: linux-crypto@vger.kernel.org
Cc: linux-geode@lists.infradead.org
---
drivers/char/hw_random/geode-rng.c | 50 +++++++++++++++++++++++++-----------
1 file changed, 35 insertions(+), 15 deletions(-)
diff --git a/drivers/char/hw_random/geode-rng.c b/drivers/char/hw_random/geode-rng.c
index e7a245942029..e1d421a36a13 100644
--- a/drivers/char/hw_random/geode-rng.c
+++ b/drivers/char/hw_random/geode-rng.c
@@ -31,6 +31,9 @@
#include <linux/module.h>
#include <linux/pci.h>
+
+#define PFX KBUILD_MODNAME ": "
+
#define GEODE_RNG_DATA_REG 0x50
#define GEODE_RNG_STATUS_REG 0x54
@@ -82,6 +85,7 @@ static int geode_rng_data_present(struct hwrng *rng, int wait)
static int __init mod_init(void)
{
+ int err = -ENODEV;
struct pci_dev *pdev = NULL;
const struct pci_device_id *ent;
void __iomem *mem;
@@ -89,27 +93,43 @@ static int __init mod_init(void)
for_each_pci_dev(pdev) {
ent = pci_match_id(pci_tbl, pdev);
- if (ent) {
- rng_base = pci_resource_start(pdev, 0);
- if (rng_base == 0)
- return -ENODEV;
-
- mem = devm_ioremap(&pdev->dev, rng_base, 0x58);
- if (!mem)
- return -ENOMEM;
- geode_rng.priv = (unsigned long)mem;
-
- pr_info("AMD Geode RNG detected\n");
- return devm_hwrng_register(&pdev->dev, &geode_rng);
- }
+ if (ent)
+ goto found;
}
-
/* Device not found. */
- return -ENODEV;
+ goto out;
+
+found:
+ rng_base = pci_resource_start(pdev, 0);
+ if (rng_base == 0)
+ goto out;
+ err = -ENOMEM;
+ mem = ioremap(rng_base, 0x58);
+ if (!mem)
+ goto out;
+ geode_rng.priv = (unsigned long)mem;
+
+ pr_info("AMD Geode RNG detected\n");
+ err = hwrng_register(&geode_rng);
+ if (err) {
+ pr_err(PFX "RNG registering failed (%d)\n",
+ err);
+ goto err_unmap;
+ }
+out:
+ return err;
+
+err_unmap:
+ iounmap(mem);
+ goto out;
}
static void __exit mod_exit(void)
{
+ void __iomem *mem = (void __iomem *)geode_rng.priv;
+
+ hwrng_unregister(&geode_rng);
+ iounmap(mem);
}
module_init(mod_init);
--
1.7.9.3
^ permalink raw reply related
* [PATCH 1/2] hwrng: amd - Revert managed API changes
From: Prarit Bhargava @ 2017-03-14 11:36 UTC (permalink / raw)
To: linux-kernel
Cc: Prarit Bhargava, Matt Mackall, Herbert Xu, Corentin LABBE,
PrasannaKumar Muralidharan, Wei Yongjun, linux-crypto,
linux-geode
In-Reply-To: <1489491362-26339-1-git-send-email-prarit@redhat.com>
After commit 31b2a73c9c5f ("hwrng: amd - Migrate to managed API"), the
amd-rng driver uses devres with pci_dev->dev to keep track of resources,
but does not actually register a PCI driver. This results in the
following issues:
1. The message
WARNING: CPU: 2 PID: 621 at drivers/base/dd.c:349 driver_probe_device+0x38c
is output when the i2c_amd756 driver loads and attempts to register a PCI
driver. The PCI & device subsystems assume that no resources have been
registered for the device, and the WARN_ON() triggers since amd-rng has
already do so.
2. The driver leaks memory because the driver does not attach to a
device. The driver only uses the PCI device as a reference. devm_*()
functions will release resources on driver detach, which the amd-rng
driver will never do. As a result,
3. The driver cannot be reloaded because there is always a use of the
ioport and region after the first load of the driver.
Revert the changes made by 31b2a73c9c5f ("hwrng: amd - Migrate to managed
API").
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Fixes: 31b2a73c9c5f ("hwrng: amd - Migrate to managed API").
Cc: Matt Mackall <mpm@selenic.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Corentin LABBE <clabbe.montjoie@gmail.com>
Cc: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
Cc: Wei Yongjun <weiyongjun1@huawei.com>
Cc: linux-crypto@vger.kernel.org
Cc: linux-geode@lists.infradead.org
---
drivers/char/hw_random/amd-rng.c | 42 ++++++++++++++++++++++++++++++--------
1 file changed, 34 insertions(+), 8 deletions(-)
diff --git a/drivers/char/hw_random/amd-rng.c b/drivers/char/hw_random/amd-rng.c
index 4a99ac756f08..9959c762da2f 100644
--- a/drivers/char/hw_random/amd-rng.c
+++ b/drivers/char/hw_random/amd-rng.c
@@ -55,6 +55,7 @@
struct amd768_priv {
void __iomem *iobase;
struct pci_dev *pcidev;
+ u32 pmbase;
};
static int amd_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
@@ -148,33 +149,58 @@ static int __init mod_init(void)
if (pmbase == 0)
return -EIO;
- priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
+ priv = kzalloc(sizeof(*priv), GFP_KERNEL);
if (!priv)
return -ENOMEM;
- if (!devm_request_region(&pdev->dev, pmbase + PMBASE_OFFSET,
- PMBASE_SIZE, DRV_NAME)) {
+ if (!request_region(pmbase + PMBASE_OFFSET, PMBASE_SIZE, DRV_NAME)) {
dev_err(&pdev->dev, DRV_NAME " region 0x%x already in use!\n",
pmbase + 0xF0);
- return -EBUSY;
+ err = -EBUSY;
+ goto out;
}
- priv->iobase = devm_ioport_map(&pdev->dev, pmbase + PMBASE_OFFSET,
- PMBASE_SIZE);
+ priv->iobase = ioport_map(pmbase + PMBASE_OFFSET, PMBASE_SIZE);
if (!priv->iobase) {
pr_err(DRV_NAME "Cannot map ioport\n");
- return -ENOMEM;
+ err = -EINVAL;
+ goto err_iomap;
}
amd_rng.priv = (unsigned long)priv;
+ priv->pmbase = pmbase;
priv->pcidev = pdev;
pr_info(DRV_NAME " detected\n");
- return devm_hwrng_register(&pdev->dev, &amd_rng);
+ err = hwrng_register(&amd_rng);
+ if (err) {
+ pr_err(DRV_NAME " registering failed (%d)\n", err);
+ goto err_hwrng;
+ }
+ return 0;
+
+err_hwrng:
+ ioport_unmap(priv->iobase);
+err_iomap:
+ release_region(pmbase + PMBASE_OFFSET, PMBASE_SIZE);
+out:
+ kfree(priv);
+ return err;
}
static void __exit mod_exit(void)
{
+ struct amd768_priv *priv;
+
+ priv = (struct amd768_priv *)amd_rng.priv;
+
+ hwrng_unregister(&amd_rng);
+
+ ioport_unmap(priv->iobase);
+
+ release_region(priv->pmbase + PMBASE_OFFSET, PMBASE_SIZE);
+
+ kfree(priv);
}
module_init(mod_init);
--
1.7.9.3
^ permalink raw reply related
* [PATCH 0/2] hwrng: revert managed API changes for amd and geode
From: Prarit Bhargava @ 2017-03-14 11:36 UTC (permalink / raw)
To: linux-kernel
Cc: Prarit Bhargava, Matt Mackall, Herbert Xu, Corentin LABBE,
PrasannaKumar Muralidharan, Wei Yongjun, linux-crypto,
linux-geode
When booting top-of-tree the following WARN_ON triggers in the kernel on
a 15h AMD system.
WARNING: CPU: 2 PID: 621 at drivers/base/dd.c:349 driver_probe_device+0x38c
Modules linked in: i2c_amd756(+) amd_rng sg pcspkr parport_pc(+) parport k8
CPU: 2 PID: 621 Comm: systemd-udevd Not tainted 4.11.0-0.rc1.git0.1.el7_UNS
Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./TYAN High-End
Call Trace:
dump_stack+0x63/0x8e
__warn+0xd1/0xf0
warn_slowpath_null+0x1d/0x20
driver_probe_device+0x38c/0x470
__driver_attach+0xc9/0xf0
? driver_probe_device+0x470/0x470
bus_for_each_dev+0x5d/0x90
driver_attach+0x1e/0x20
bus_add_driver+0x1d0/0x290
driver_register+0x60/0xe0
? 0xffffffffa0037000
__pci_register_driver+0x4c/0x50
amd756_driver_init+0x1e/0x1000 [i2c_amd756]
do_one_initcall+0x51/0x1b0
? __vunmap+0x85/0xd0
? do_init_module+0x27/0x1fa
do_init_module+0x60/0x1fa
load_module+0x15d1/0x1ad0
? m_show+0x1c0/0x1c0
SYSC_finit_module+0xa9/0xd0
There are PCI devices that contain both a RNG and SMBUS device. The
RNG device is initialized by the amd-rng driver but the driver does not
register against the device. The SMBUS device is initialized by the
i2c-amd756 driver and registers against the device and hits the WARN_ON()
because the amd-rng driver has already allocated resources against the
device.
The amd-rng driver was incorrectly migrated to the device resource model
(devres), and after code inspection I found that the geode-rng driver was also
incorrectly migrated. These drivers are using devres but do not register a
driver against the device, and both drivers are expecting a memory cleanup on
a driver detach that will never happen. This results in a memory leak when the
driver is unloaded and the inability to reload the driver.
Revert 31b2a73c9c5f ("hwrng: amd - Migrate to managed API"), and 6e9b5e76882c
("hwrng: geode - Migrate to managed API").
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Fixes: 31b2a73c9c5f ("hwrng: amd - Migrate to managed API").
Fixes: 6e9b5e76882c ("hwrng: geode - Migrate to managed API")
Cc: Matt Mackall <mpm@selenic.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Corentin LABBE <clabbe.montjoie@gmail.com>
Cc: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
Cc: Wei Yongjun <weiyongjun1@huawei.com>
Cc: linux-crypto@vger.kernel.org
Cc: linux-geode@lists.infradead.org
Prarit Bhargava (2):
hwrng: amd - Revert managed API changes
hwrng: geode - Revert managed API changes
drivers/char/hw_random/amd-rng.c | 42 ++++++++++++++++++++++++------
drivers/char/hw_random/geode-rng.c | 50 +++++++++++++++++++++++++-----------
2 files changed, 69 insertions(+), 23 deletions(-)
--
1.7.9.3
^ permalink raw reply
* Re: crypto: deadlock between crypto_alg_sem/rtnl_mutex/genl_mutex
From: Dmitry Vyukov @ 2017-03-14 10:31 UTC (permalink / raw)
To: Herbert Xu
Cc: David Miller, linux-crypto, LKML, Eric Dumazet, Cong Wang, netdev,
syzkaller
In-Reply-To: <20170314102557.GA1225@gondor.apana.org.au>
On Tue, Mar 14, 2017 at 11:25 AM, Herbert Xu
<herbert@gondor.apana.org.au> wrote:
> On Tue, Mar 14, 2017 at 10:44:10AM +0100, Dmitry Vyukov wrote:
>>
>> Yes, please.
>> Disregarding some reports is not a good way long term.
>
> Please try this patch.
Applied on bots. I should have a conclusion within a day.
Thanks!
> ---8<---
> Subject: netlink: Annotate nlk cb_mutex by protocol
>
> Currently all occurences of nlk->cb_mutex are annotated by lockdep
> as a single class. This causes a false lcokdep cycle involving
> genl and crypto_user.
>
> This patch fixes it by dividing cb_mutex into individual classes
> based on the netlink protocol. As genl and crypto_user do not
> use the same netlink protocol this breaks the false dependency
> loop.
>
> Reported-by: Dmitry Vyukov <dvyukov@google.com>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>
> diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
> index 7b73c7c..596eaff 100644
> --- a/net/netlink/af_netlink.c
> +++ b/net/netlink/af_netlink.c
> @@ -96,6 +96,44 @@ static inline int netlink_is_kernel(struct sock *sk)
>
> static DECLARE_WAIT_QUEUE_HEAD(nl_table_wait);
>
> +static struct lock_class_key nlk_cb_mutex_keys[MAX_LINKS];
> +
> +static const char *const nlk_cb_mutex_key_strings[MAX_LINKS + 1] = {
> + "nlk_cb_mutex-ROUTE",
> + "nlk_cb_mutex-1",
> + "nlk_cb_mutex-USERSOCK",
> + "nlk_cb_mutex-FIREWALL",
> + "nlk_cb_mutex-SOCK_DIAG",
> + "nlk_cb_mutex-NFLOG",
> + "nlk_cb_mutex-XFRM",
> + "nlk_cb_mutex-SELINUX",
> + "nlk_cb_mutex-ISCSI",
> + "nlk_cb_mutex-AUDIT",
> + "nlk_cb_mutex-FIB_LOOKUP",
> + "nlk_cb_mutex-CONNECTOR",
> + "nlk_cb_mutex-NETFILTER",
> + "nlk_cb_mutex-IP6_FW",
> + "nlk_cb_mutex-DNRTMSG",
> + "nlk_cb_mutex-KOBJECT_UEVENT",
> + "nlk_cb_mutex-GENERIC",
> + "nlk_cb_mutex-17",
> + "nlk_cb_mutex-SCSITRANSPORT",
> + "nlk_cb_mutex-ECRYPTFS",
> + "nlk_cb_mutex-RDMA",
> + "nlk_cb_mutex-CRYPTO",
> + "nlk_cb_mutex-SMC",
> + "nlk_cb_mutex-23",
> + "nlk_cb_mutex-24",
> + "nlk_cb_mutex-25",
> + "nlk_cb_mutex-26",
> + "nlk_cb_mutex-27",
> + "nlk_cb_mutex-28",
> + "nlk_cb_mutex-29",
> + "nlk_cb_mutex-30",
> + "nlk_cb_mutex-31",
> + "nlk_cb_mutex-MAX_LINKS"
> +};
> +
> static int netlink_dump(struct sock *sk);
> static void netlink_skb_destructor(struct sk_buff *skb);
>
> @@ -585,6 +623,9 @@ static int __netlink_create(struct net *net, struct socket *sock,
> } else {
> nlk->cb_mutex = &nlk->cb_def_mutex;
> mutex_init(nlk->cb_mutex);
> + lockdep_set_class_and_name(nlk->cb_mutex,
> + nlk_cb_mutex_keys + protocol,
> + nlk_cb_mutex_key_strings[protocol]);
> }
> init_waitqueue_head(&nlk->wait);
>
> --
> 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: crypto: deadlock between crypto_alg_sem/rtnl_mutex/genl_mutex
From: Herbert Xu @ 2017-03-14 10:25 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: David Miller, linux-crypto, LKML, Eric Dumazet, Cong Wang, netdev,
syzkaller
In-Reply-To: <CACT4Y+YT6EZFtMTNywd4BtKyzWrJ9vtDU96TUFi9WLpypkgWhg@mail.gmail.com>
On Tue, Mar 14, 2017 at 10:44:10AM +0100, Dmitry Vyukov wrote:
>
> Yes, please.
> Disregarding some reports is not a good way long term.
Please try this patch.
---8<---
Subject: netlink: Annotate nlk cb_mutex by protocol
Currently all occurences of nlk->cb_mutex are annotated by lockdep
as a single class. This causes a false lcokdep cycle involving
genl and crypto_user.
This patch fixes it by dividing cb_mutex into individual classes
based on the netlink protocol. As genl and crypto_user do not
use the same netlink protocol this breaks the false dependency
loop.
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 7b73c7c..596eaff 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -96,6 +96,44 @@ static inline int netlink_is_kernel(struct sock *sk)
static DECLARE_WAIT_QUEUE_HEAD(nl_table_wait);
+static struct lock_class_key nlk_cb_mutex_keys[MAX_LINKS];
+
+static const char *const nlk_cb_mutex_key_strings[MAX_LINKS + 1] = {
+ "nlk_cb_mutex-ROUTE",
+ "nlk_cb_mutex-1",
+ "nlk_cb_mutex-USERSOCK",
+ "nlk_cb_mutex-FIREWALL",
+ "nlk_cb_mutex-SOCK_DIAG",
+ "nlk_cb_mutex-NFLOG",
+ "nlk_cb_mutex-XFRM",
+ "nlk_cb_mutex-SELINUX",
+ "nlk_cb_mutex-ISCSI",
+ "nlk_cb_mutex-AUDIT",
+ "nlk_cb_mutex-FIB_LOOKUP",
+ "nlk_cb_mutex-CONNECTOR",
+ "nlk_cb_mutex-NETFILTER",
+ "nlk_cb_mutex-IP6_FW",
+ "nlk_cb_mutex-DNRTMSG",
+ "nlk_cb_mutex-KOBJECT_UEVENT",
+ "nlk_cb_mutex-GENERIC",
+ "nlk_cb_mutex-17",
+ "nlk_cb_mutex-SCSITRANSPORT",
+ "nlk_cb_mutex-ECRYPTFS",
+ "nlk_cb_mutex-RDMA",
+ "nlk_cb_mutex-CRYPTO",
+ "nlk_cb_mutex-SMC",
+ "nlk_cb_mutex-23",
+ "nlk_cb_mutex-24",
+ "nlk_cb_mutex-25",
+ "nlk_cb_mutex-26",
+ "nlk_cb_mutex-27",
+ "nlk_cb_mutex-28",
+ "nlk_cb_mutex-29",
+ "nlk_cb_mutex-30",
+ "nlk_cb_mutex-31",
+ "nlk_cb_mutex-MAX_LINKS"
+};
+
static int netlink_dump(struct sock *sk);
static void netlink_skb_destructor(struct sk_buff *skb);
@@ -585,6 +623,9 @@ static int __netlink_create(struct net *net, struct socket *sock,
} else {
nlk->cb_mutex = &nlk->cb_def_mutex;
mutex_init(nlk->cb_mutex);
+ lockdep_set_class_and_name(nlk->cb_mutex,
+ nlk_cb_mutex_keys + protocol,
+ nlk_cb_mutex_key_strings[protocol]);
}
init_waitqueue_head(&nlk->wait);
--
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 related
* Re: crypto: deadlock between crypto_alg_sem/rtnl_mutex/genl_mutex
From: Dmitry Vyukov @ 2017-03-14 9:44 UTC (permalink / raw)
To: Herbert Xu
Cc: David Miller, linux-crypto, LKML, Eric Dumazet, Cong Wang, netdev,
syzkaller
In-Reply-To: <20170314091649.GA711@gondor.apana.org.au>
On Tue, Mar 14, 2017 at 10:16 AM, Herbert Xu
<herbert@gondor.apana.org.au> wrote:
> On Sun, Mar 05, 2017 at 04:08:39PM +0100, Dmitry Vyukov wrote:
>>
>> -> #1 (genl_mutex){+.+.+.}:
>> validate_chain kernel/locking/lockdep.c:2267 [inline]
>> __lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3340
>> lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3755
>> __mutex_lock_common kernel/locking/mutex.c:756 [inline]
>> __mutex_lock+0x172/0x1730 kernel/locking/mutex.c:893
>> mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:908
>> genl_lock net/netlink/genetlink.c:32 [inline]
>> genl_lock_dumpit+0x41/0x90 net/netlink/genetlink.c:478
>> netlink_dump+0x54d/0xd40 net/netlink/af_netlink.c:2127
>> __netlink_dump_start+0x4e5/0x760 net/netlink/af_netlink.c:2217
>> genl_family_rcv_msg+0xd9d/0x1040 net/netlink/genetlink.c:546
>> genl_rcv_msg+0xa6/0x140 net/netlink/genetlink.c:620
>> netlink_rcv_skb+0x2ab/0x390 net/netlink/af_netlink.c:2298
>> genl_rcv+0x28/0x40 net/netlink/genetlink.c:631
>> netlink_unicast_kernel net/netlink/af_netlink.c:1231 [inline]
>> netlink_unicast+0x514/0x730 net/netlink/af_netlink.c:1257
>> netlink_sendmsg+0xa9f/0xe50 net/netlink/af_netlink.c:1803
>> sock_sendmsg_nosec net/socket.c:633 [inline]
>> sock_sendmsg+0xca/0x110 net/socket.c:643
>> sock_write_iter+0x326/0x600 net/socket.c:846
>> call_write_iter include/linux/fs.h:1733 [inline]
>> new_sync_write fs/read_write.c:497 [inline]
>> __vfs_write+0x483/0x740 fs/read_write.c:510
>> vfs_write+0x187/0x530 fs/read_write.c:558
>> SYSC_write fs/read_write.c:605 [inline]
>> SyS_write+0xfb/0x230 fs/read_write.c:597
>> entry_SYSCALL_64_fastpath+0x1f/0xc2
>>
>> -> #0 (nlk->cb_mutex){+.+.+.}:
>> check_prev_add kernel/locking/lockdep.c:1830 [inline]
>> check_prevs_add+0xa8f/0x19f0 kernel/locking/lockdep.c:1940
>> validate_chain kernel/locking/lockdep.c:2267 [inline]
>> __lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3340
>> lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3755
>> __mutex_lock_common kernel/locking/mutex.c:756 [inline]
>> __mutex_lock+0x172/0x1730 kernel/locking/mutex.c:893
>> mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:908
>> __netlink_dump_start+0xf4/0x760 net/netlink/af_netlink.c:2187
>> netlink_dump_start include/linux/netlink.h:165 [inline]
>> crypto_user_rcv_msg+0x2ad/0x4f0 crypto/crypto_user.c:517
>> netlink_rcv_skb+0x2ab/0x390 net/netlink/af_netlink.c:2298
>> crypto_netlink_rcv+0x2a/0x40 crypto/crypto_user.c:538
>> netlink_unicast_kernel net/netlink/af_netlink.c:1231 [inline]
>> netlink_unicast+0x514/0x730 net/netlink/af_netlink.c:1257
>> netlink_sendmsg+0xa9f/0xe50 net/netlink/af_netlink.c:1803
>> sock_sendmsg_nosec net/socket.c:633 [inline]
>> sock_sendmsg+0xca/0x110 net/socket.c:643
>> ___sys_sendmsg+0x8fa/0x9f0 net/socket.c:1985
>> __sys_sendmsg+0x138/0x300 net/socket.c:2019
>> SYSC_sendmsg net/socket.c:2030 [inline]
>> SyS_sendmsg+0x2d/0x50 net/socket.c:2026
>> entry_SYSCALL_64_fastpath+0x1f/0xc2
>
> This looks like a false positive. The cb_mutex in #1 is not the
> same as the cb_mutex in #0. The cb_mutex in #0 comes is obtained
> by crypto_user which uses straight netlink. The cb_mutex in #1
> is a genl netlink socket.
>
> I'll have a look to see if we can annotate this.
Yes, please.
Disregarding some reports is not a good way long term.
^ permalink raw reply
* Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
From: Herbert Xu @ 2017-03-14 9:20 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Nathan Royce, davem, linux-crypto, linux-kernel, Marek Szyprowski
In-Reply-To: <20170313170601.ozolfzgixqu6aa4g@kozik-lap>
On Mon, Mar 13, 2017 at 07:06:01PM +0200, Krzysztof Kozlowski wrote:
>
> I bisected this to commit f1c131b45410 ("crypto: xts - Convert to
> skcipher"). The s5p-sss driver stays the same... but the xts changes and
> as a result we have a NULL pointer dereference (actually of value
> 00000004):
> [ 18.930195] Unable to handle kernel NULL pointer dereference at virtual address 00000004
> ...
> [ 18.972325] [<c0313c98>] (post_crypt) from [<c031408c>] (decrypt_done+0x4c/0x54)
> [ 18.972343] [<c031408c>] (decrypt_done) from [<c056309c>] (s5p_aes_interrupt+0x1bc/0x208)
> [ 18.972360] [<c056309c>] (s5p_aes_interrupt) from [<c0164930>] (irq_thread_fn+0x1c/0x54)
Well that's hardly surprising since xts prior to this commit used
simple AES as opposed to ecb(aes) so it couldn't have triggered
this bug.
> Any hints?
I'll have a look when I have time but no promises.
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: crypto: deadlock between crypto_alg_sem/rtnl_mutex/genl_mutex
From: Herbert Xu @ 2017-03-14 9:17 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: David Miller, linux-crypto, LKML, Eric Dumazet, Cong Wang, netdev,
syzkaller
In-Reply-To: <CACT4Y+bJ1-d3DhCvzEN0PeDd7+P2LNgjF2NHwALXBubOKaOEsw@mail.gmail.com>
On Sun, Mar 05, 2017 at 06:36:12PM +0100, Dmitry Vyukov wrote:
>
> > -> #1 (genl_mutex){+.+.+.}:
> > validate_chain kernel/locking/lockdep.c:2267 [inline]
> > __lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3340
> > lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3755
> > __mutex_lock_common kernel/locking/mutex.c:756 [inline]
> > __mutex_lock+0x172/0x1730 kernel/locking/mutex.c:893
> > mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:908
> > genl_lock net/netlink/genetlink.c:32 [inline]
> > genl_lock_dumpit+0x41/0x90 net/netlink/genetlink.c:478
> > netlink_dump+0x54d/0xd40 net/netlink/af_netlink.c:2127
> > __netlink_dump_start+0x4e5/0x760 net/netlink/af_netlink.c:2217
> > genl_family_rcv_msg+0xd9d/0x1040 net/netlink/genetlink.c:546
> > genl_rcv_msg+0xa6/0x140 net/netlink/genetlink.c:620
> > netlink_rcv_skb+0x2ab/0x390 net/netlink/af_netlink.c:2298
> > genl_rcv+0x28/0x40 net/netlink/genetlink.c:631
> > netlink_unicast_kernel net/netlink/af_netlink.c:1231 [inline]
> > netlink_unicast+0x514/0x730 net/netlink/af_netlink.c:1257
> > netlink_sendmsg+0xa9f/0xe50 net/netlink/af_netlink.c:1803
> > sock_sendmsg_nosec net/socket.c:633 [inline]
> > sock_sendmsg+0xca/0x110 net/socket.c:643
> > sock_write_iter+0x326/0x600 net/socket.c:846
> > call_write_iter include/linux/fs.h:1733 [inline]
> > new_sync_write fs/read_write.c:497 [inline]
> > __vfs_write+0x483/0x740 fs/read_write.c:510
> > vfs_write+0x187/0x530 fs/read_write.c:558
> > SYSC_write fs/read_write.c:605 [inline]
> > SyS_write+0xfb/0x230 fs/read_write.c:597
> > entry_SYSCALL_64_fastpath+0x1f/0xc2
> >
> > -> #0 (nlk->cb_mutex){+.+.+.}:
> > check_prev_add kernel/locking/lockdep.c:1830 [inline]
> > check_prevs_add+0xa8f/0x19f0 kernel/locking/lockdep.c:1940
> > validate_chain kernel/locking/lockdep.c:2267 [inline]
> > __lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3340
> > lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3755
> > __mutex_lock_common kernel/locking/mutex.c:756 [inline]
> > __mutex_lock+0x172/0x1730 kernel/locking/mutex.c:893
> > mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:908
> > __netlink_dump_start+0xf4/0x760 net/netlink/af_netlink.c:2187
> > netlink_dump_start include/linux/netlink.h:165 [inline]
> > crypto_user_rcv_msg+0x2ad/0x4f0 crypto/crypto_user.c:517
> > netlink_rcv_skb+0x2ab/0x390 net/netlink/af_netlink.c:2298
> > crypto_netlink_rcv+0x2a/0x40 crypto/crypto_user.c:538
> > netlink_unicast_kernel net/netlink/af_netlink.c:1231 [inline]
> > netlink_unicast+0x514/0x730 net/netlink/af_netlink.c:1257
> > netlink_sendmsg+0xa9f/0xe50 net/netlink/af_netlink.c:1803
> > sock_sendmsg_nosec net/socket.c:633 [inline]
> > sock_sendmsg+0xca/0x110 net/socket.c:643
> > ___sys_sendmsg+0x8fa/0x9f0 net/socket.c:1985
> > __sys_sendmsg+0x138/0x300 net/socket.c:2019
> > SYSC_sendmsg net/socket.c:2030 [inline]
> > SyS_sendmsg+0x2d/0x50 net/socket.c:2026
> > entry_SYSCALL_64_fastpath+0x1f/0xc2
Ditto. Please disregard any reports involving genl_mutex and
cb_mutex where the latter comes from crypto_user.
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: crypto: deadlock between crypto_alg_sem/rtnl_mutex/genl_mutex
From: Herbert Xu @ 2017-03-14 9:16 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: David Miller, linux-crypto, LKML, Eric Dumazet, Cong Wang, netdev,
syzkaller
In-Reply-To: <CACT4Y+bLbNbf0T376JHvemuY+za0+qgrfOKWzvJg5vAkJTCRFg@mail.gmail.com>
On Sun, Mar 05, 2017 at 04:08:39PM +0100, Dmitry Vyukov wrote:
>
> -> #1 (genl_mutex){+.+.+.}:
> validate_chain kernel/locking/lockdep.c:2267 [inline]
> __lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3340
> lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3755
> __mutex_lock_common kernel/locking/mutex.c:756 [inline]
> __mutex_lock+0x172/0x1730 kernel/locking/mutex.c:893
> mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:908
> genl_lock net/netlink/genetlink.c:32 [inline]
> genl_lock_dumpit+0x41/0x90 net/netlink/genetlink.c:478
> netlink_dump+0x54d/0xd40 net/netlink/af_netlink.c:2127
> __netlink_dump_start+0x4e5/0x760 net/netlink/af_netlink.c:2217
> genl_family_rcv_msg+0xd9d/0x1040 net/netlink/genetlink.c:546
> genl_rcv_msg+0xa6/0x140 net/netlink/genetlink.c:620
> netlink_rcv_skb+0x2ab/0x390 net/netlink/af_netlink.c:2298
> genl_rcv+0x28/0x40 net/netlink/genetlink.c:631
> netlink_unicast_kernel net/netlink/af_netlink.c:1231 [inline]
> netlink_unicast+0x514/0x730 net/netlink/af_netlink.c:1257
> netlink_sendmsg+0xa9f/0xe50 net/netlink/af_netlink.c:1803
> sock_sendmsg_nosec net/socket.c:633 [inline]
> sock_sendmsg+0xca/0x110 net/socket.c:643
> sock_write_iter+0x326/0x600 net/socket.c:846
> call_write_iter include/linux/fs.h:1733 [inline]
> new_sync_write fs/read_write.c:497 [inline]
> __vfs_write+0x483/0x740 fs/read_write.c:510
> vfs_write+0x187/0x530 fs/read_write.c:558
> SYSC_write fs/read_write.c:605 [inline]
> SyS_write+0xfb/0x230 fs/read_write.c:597
> entry_SYSCALL_64_fastpath+0x1f/0xc2
>
> -> #0 (nlk->cb_mutex){+.+.+.}:
> check_prev_add kernel/locking/lockdep.c:1830 [inline]
> check_prevs_add+0xa8f/0x19f0 kernel/locking/lockdep.c:1940
> validate_chain kernel/locking/lockdep.c:2267 [inline]
> __lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3340
> lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3755
> __mutex_lock_common kernel/locking/mutex.c:756 [inline]
> __mutex_lock+0x172/0x1730 kernel/locking/mutex.c:893
> mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:908
> __netlink_dump_start+0xf4/0x760 net/netlink/af_netlink.c:2187
> netlink_dump_start include/linux/netlink.h:165 [inline]
> crypto_user_rcv_msg+0x2ad/0x4f0 crypto/crypto_user.c:517
> netlink_rcv_skb+0x2ab/0x390 net/netlink/af_netlink.c:2298
> crypto_netlink_rcv+0x2a/0x40 crypto/crypto_user.c:538
> netlink_unicast_kernel net/netlink/af_netlink.c:1231 [inline]
> netlink_unicast+0x514/0x730 net/netlink/af_netlink.c:1257
> netlink_sendmsg+0xa9f/0xe50 net/netlink/af_netlink.c:1803
> sock_sendmsg_nosec net/socket.c:633 [inline]
> sock_sendmsg+0xca/0x110 net/socket.c:643
> ___sys_sendmsg+0x8fa/0x9f0 net/socket.c:1985
> __sys_sendmsg+0x138/0x300 net/socket.c:2019
> SYSC_sendmsg net/socket.c:2030 [inline]
> SyS_sendmsg+0x2d/0x50 net/socket.c:2026
> entry_SYSCALL_64_fastpath+0x1f/0xc2
This looks like a false positive. The cb_mutex in #1 is not the
same as the cb_mutex in #0. The cb_mutex in #0 comes is obtained
by crypto_user which uses straight netlink. The cb_mutex in #1
is a genl netlink socket.
I'll have a look to see if we can annotate this.
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: crypto: deadlock between crypto_alg_sem/rtnl_mutex/genl_mutex
From: Dmitry Vyukov @ 2017-03-14 8:14 UTC (permalink / raw)
To: Herbert Xu, David Miller, linux-crypto, LKML, Eric Dumazet,
Cong Wang, netdev, santosh.shilimkar, rds-devel
Cc: syzkaller
In-Reply-To: <CACT4Y+YhLM0CetOZn6uXwyBBGM_oVsW-CC3NMg8A5K0xd3F2mA@mail.gmail.com>
On Mon, Mar 6, 2017 at 10:36 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
> On Sun, Mar 5, 2017 at 6:36 PM, Dmitry Vyukov <dvyukov@google.com> wrote:
>> On Sun, Mar 5, 2017 at 4:08 PM, Dmitry Vyukov <dvyukov@google.com> wrote:
>>> Hello,
>>>
>>> I am getting the following deadlock reports while running syzkaller
>>> fuzzer on net-next/8d70eeb84ab277377c017af6a21d0a337025dede:
>>>
>>> ======================================================
>>> [ INFO: possible circular locking dependency detected ]
>>> 4.10.0+ #5 Not tainted
>>> -------------------------------------------------------
>>> syz-executor6/6143 is trying to acquire lock:
>>> (nlk->cb_mutex){+.+.+.}, at: [<ffffffff837df634>]
>>> __netlink_dump_start+0xf4/0x760 net/netlink/af_netlink.c:2187
>>>
>>> but task is already holding lock:
>>> (crypto_alg_sem){+++++.}, at: [<ffffffff821cd1f6>]
>>> crypto_user_rcv_msg+0x136/0x4f0 crypto/crypto_user.c:507
>>>
>>> which lock already depends on the new lock.
>>>
>>>
>>> the existing dependency chain (in reverse order) is:
>>>
>>> -> #4 (crypto_alg_sem){+++++.}:
>>> validate_chain kernel/locking/lockdep.c:2267 [inline]
>>> __lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3340
>>> lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3755
>>> down_read+0x9b/0x150 kernel/locking/rwsem.c:23
>>> crypto_alg_lookup+0x23/0x50 crypto/api.c:199
>>> crypto_larval_lookup.part.10+0x9a/0x3b0 crypto/api.c:217
>>> crypto_larval_lookup crypto/api.c:211 [inline]
>>> crypto_alg_mod_lookup+0x77/0x1b0 crypto/api.c:270
>>> crypto_alloc_base+0x50/0x1e0 crypto/api.c:416
>>> crypto_alloc_cipher include/linux/crypto.h:1407 [inline]
>>> tcp_fastopen_reset_cipher+0xc2/0x2e0 net/ipv4/tcp_fastopen.c:48
>>> tcp_fastopen_init_key_once+0x114/0x120 net/ipv4/tcp_fastopen.c:29
>>> do_tcp_setsockopt.isra.36+0x140a/0x20a0 net/ipv4/tcp.c:2684
>>> tcp_setsockopt+0xb0/0xd0 net/ipv4/tcp.c:2733
>>> sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2731
>>> SYSC_setsockopt net/socket.c:1786 [inline]
>>> SyS_setsockopt+0x25c/0x390 net/socket.c:1765
>>> entry_SYSCALL_64_fastpath+0x1f/0xc2
>>>
>>> -> #3 (sk_lock-AF_INET){+.+.+.}:
>>> validate_chain kernel/locking/lockdep.c:2267 [inline]
>>> __lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3340
>>> lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3755
>>> lock_sock_nested+0xcb/0x120 net/core/sock.c:2536
>>> lock_sock include/net/sock.h:1460 [inline]
>>> rds_tcp_listen_stop+0x57/0x140 net/rds/tcp_listen.c:284
>>> rds_tcp_kill_sock net/rds/tcp.c:529 [inline]
>>> rds_tcp_dev_event+0x383/0xc50 net/rds/tcp.c:568
>>> notifier_call_chain+0x1b5/0x2b0 kernel/notifier.c:93
>>> __raw_notifier_call_chain kernel/notifier.c:394 [inline]
>>> raw_notifier_call_chain+0x2d/0x40 kernel/notifier.c:401
>>> call_netdevice_notifiers_info+0x51/0x90 net/core/dev.c:1646
>>> call_netdevice_notifiers net/core/dev.c:1662 [inline]
>>> netdev_run_todo+0x3b2/0xa30 net/core/dev.c:7530
>>> rtnl_unlock+0xe/0x10 net/core/rtnetlink.c:104
>>> default_device_exit_batch+0x504/0x620 net/core/dev.c:8334
>>> ops_exit_list.isra.6+0x100/0x150 net/core/net_namespace.c:144
>>> cleanup_net+0x551/0xa90 net/core/net_namespace.c:463
>>> process_one_work+0xbd0/0x1c10 kernel/workqueue.c:2096
>>> worker_thread+0x223/0x1990 kernel/workqueue.c:2230
>>> kthread+0x326/0x3f0 kernel/kthread.c:229
>>> ret_from_fork+0x31/0x40 arch/x86/entry/entry_64.S:430
>>>
>>> -> #2 (rtnl_mutex){+.+.+.}:
>>> validate_chain kernel/locking/lockdep.c:2267 [inline]
>>> __lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3340
>>> lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3755
>>> __mutex_lock_common kernel/locking/mutex.c:756 [inline]
>>> __mutex_lock+0x172/0x1730 kernel/locking/mutex.c:893
>>> mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:908
>>> rtnl_lock+0x17/0x20 net/core/rtnetlink.c:70
>>> tipc_nl_bearer_dump+0x3ef/0x720 net/tipc/bearer.c:774
>>> genl_lock_dumpit+0x68/0x90 net/netlink/genetlink.c:479
>>> netlink_dump+0x54d/0xd40 net/netlink/af_netlink.c:2127
>>> __netlink_dump_start+0x4e5/0x760 net/netlink/af_netlink.c:2217
>>> genl_family_rcv_msg+0xd9d/0x1040 net/netlink/genetlink.c:546
>>> genl_rcv_msg+0xa6/0x140 net/netlink/genetlink.c:620
>>> netlink_rcv_skb+0x2ab/0x390 net/netlink/af_netlink.c:2298
>>> genl_rcv+0x28/0x40 net/netlink/genetlink.c:631
>>> netlink_unicast_kernel net/netlink/af_netlink.c:1231 [inline]
>>> netlink_unicast+0x514/0x730 net/netlink/af_netlink.c:1257
>>> netlink_sendmsg+0xa9f/0xe50 net/netlink/af_netlink.c:1803
>>> sock_sendmsg_nosec net/socket.c:633 [inline]
>>> sock_sendmsg+0xca/0x110 net/socket.c:643
>>> sock_write_iter+0x326/0x600 net/socket.c:846
>>> call_write_iter include/linux/fs.h:1733 [inline]
>>> new_sync_write fs/read_write.c:497 [inline]
>>> __vfs_write+0x483/0x740 fs/read_write.c:510
>>> vfs_write+0x187/0x530 fs/read_write.c:558
>>> SYSC_write fs/read_write.c:605 [inline]
>>> SyS_write+0xfb/0x230 fs/read_write.c:597
>>> entry_SYSCALL_64_fastpath+0x1f/0xc2
>>>
>>> -> #1 (genl_mutex){+.+.+.}:
>>> validate_chain kernel/locking/lockdep.c:2267 [inline]
>>> __lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3340
>>> lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3755
>>> __mutex_lock_common kernel/locking/mutex.c:756 [inline]
>>> __mutex_lock+0x172/0x1730 kernel/locking/mutex.c:893
>>> mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:908
>>> genl_lock net/netlink/genetlink.c:32 [inline]
>>> genl_lock_dumpit+0x41/0x90 net/netlink/genetlink.c:478
>>> netlink_dump+0x54d/0xd40 net/netlink/af_netlink.c:2127
>>> __netlink_dump_start+0x4e5/0x760 net/netlink/af_netlink.c:2217
>>> genl_family_rcv_msg+0xd9d/0x1040 net/netlink/genetlink.c:546
>>> genl_rcv_msg+0xa6/0x140 net/netlink/genetlink.c:620
>>> netlink_rcv_skb+0x2ab/0x390 net/netlink/af_netlink.c:2298
>>> genl_rcv+0x28/0x40 net/netlink/genetlink.c:631
>>> netlink_unicast_kernel net/netlink/af_netlink.c:1231 [inline]
>>> netlink_unicast+0x514/0x730 net/netlink/af_netlink.c:1257
>>> netlink_sendmsg+0xa9f/0xe50 net/netlink/af_netlink.c:1803
>>> sock_sendmsg_nosec net/socket.c:633 [inline]
>>> sock_sendmsg+0xca/0x110 net/socket.c:643
>>> sock_write_iter+0x326/0x600 net/socket.c:846
>>> call_write_iter include/linux/fs.h:1733 [inline]
>>> new_sync_write fs/read_write.c:497 [inline]
>>> __vfs_write+0x483/0x740 fs/read_write.c:510
>>> vfs_write+0x187/0x530 fs/read_write.c:558
>>> SYSC_write fs/read_write.c:605 [inline]
>>> SyS_write+0xfb/0x230 fs/read_write.c:597
>>> entry_SYSCALL_64_fastpath+0x1f/0xc2
>>>
>>> -> #0 (nlk->cb_mutex){+.+.+.}:
>>> check_prev_add kernel/locking/lockdep.c:1830 [inline]
>>> check_prevs_add+0xa8f/0x19f0 kernel/locking/lockdep.c:1940
>>> validate_chain kernel/locking/lockdep.c:2267 [inline]
>>> __lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3340
>>> lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3755
>>> __mutex_lock_common kernel/locking/mutex.c:756 [inline]
>>> __mutex_lock+0x172/0x1730 kernel/locking/mutex.c:893
>>> mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:908
>>> __netlink_dump_start+0xf4/0x760 net/netlink/af_netlink.c:2187
>>> netlink_dump_start include/linux/netlink.h:165 [inline]
>>> crypto_user_rcv_msg+0x2ad/0x4f0 crypto/crypto_user.c:517
>>> netlink_rcv_skb+0x2ab/0x390 net/netlink/af_netlink.c:2298
>>> crypto_netlink_rcv+0x2a/0x40 crypto/crypto_user.c:538
>>> netlink_unicast_kernel net/netlink/af_netlink.c:1231 [inline]
>>> netlink_unicast+0x514/0x730 net/netlink/af_netlink.c:1257
>>> netlink_sendmsg+0xa9f/0xe50 net/netlink/af_netlink.c:1803
>>> sock_sendmsg_nosec net/socket.c:633 [inline]
>>> sock_sendmsg+0xca/0x110 net/socket.c:643
>>> ___sys_sendmsg+0x8fa/0x9f0 net/socket.c:1985
>>> __sys_sendmsg+0x138/0x300 net/socket.c:2019
>>> SYSC_sendmsg net/socket.c:2030 [inline]
>>> SyS_sendmsg+0x2d/0x50 net/socket.c:2026
>>> entry_SYSCALL_64_fastpath+0x1f/0xc2
>>>
>>> other info that might help us debug this:
>>>
>>> Chain exists of:
>>> nlk->cb_mutex --> sk_lock-AF_INET --> crypto_alg_sem
>>>
>>> Possible unsafe locking scenario:
>>>
>>> CPU0 CPU1
>>> ---- ----
>>> lock(crypto_alg_sem);
>>> lock(sk_lock-AF_INET);
>>> lock(crypto_alg_sem);
>>> lock(nlk->cb_mutex);
>>>
>>> *** DEADLOCK ***
>>>
>>> 2 locks held by syz-executor6/6143:
>>> #0: (crypto_cfg_mutex){+.+...}, at: [<ffffffff821cad9b>]
>>> crypto_netlink_rcv+0x1b/0x40 crypto/crypto_user.c:537
>>> #1: (crypto_alg_sem){+++++.}, at: [<ffffffff821cd1f6>]
>>> crypto_user_rcv_msg+0x136/0x4f0 crypto/crypto_user.c:507
>>>
>>> stack backtrace:
>>> CPU: 0 PID: 6143 Comm: syz-executor6 Not tainted 4.10.0+ #5
>>> Hardware name: Google Google Compute Engine/Google Compute Engine,
>>> BIOS Google 01/01/2011
>>> Call Trace:
>>> __dump_stack lib/dump_stack.c:16 [inline]
>>> dump_stack+0x2ee/0x3ef lib/dump_stack.c:52
>>> print_circular_bug+0x307/0x3b0 kernel/locking/lockdep.c:1204
>>> check_prev_add kernel/locking/lockdep.c:1830 [inline]
>>> check_prevs_add+0xa8f/0x19f0 kernel/locking/lockdep.c:1940
>>> validate_chain kernel/locking/lockdep.c:2267 [inline]
>>> __lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3340
>>> lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3755
>>> __mutex_lock_common kernel/locking/mutex.c:756 [inline]
>>> __mutex_lock+0x172/0x1730 kernel/locking/mutex.c:893
>>> mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:908
>>> __netlink_dump_start+0xf4/0x760 net/netlink/af_netlink.c:2187
>>> netlink_dump_start include/linux/netlink.h:165 [inline]
>>> crypto_user_rcv_msg+0x2ad/0x4f0 crypto/crypto_user.c:517
>>> netlink_rcv_skb+0x2ab/0x390 net/netlink/af_netlink.c:2298
>>> crypto_netlink_rcv+0x2a/0x40 crypto/crypto_user.c:538
>>> netlink_unicast_kernel net/netlink/af_netlink.c:1231 [inline]
>>> netlink_unicast+0x514/0x730 net/netlink/af_netlink.c:1257
>>> netlink_sendmsg+0xa9f/0xe50 net/netlink/af_netlink.c:1803
>>> sock_sendmsg_nosec net/socket.c:633 [inline]
>>> sock_sendmsg+0xca/0x110 net/socket.c:643
>>> ___sys_sendmsg+0x8fa/0x9f0 net/socket.c:1985
>>> __sys_sendmsg+0x138/0x300 net/socket.c:2019
>>> SYSC_sendmsg net/socket.c:2030 [inline]
>>> SyS_sendmsg+0x2d/0x50 net/socket.c:2026
>>> entry_SYSCALL_64_fastpath+0x1f/0xc2
>>
>>
>>
>> Another one involving tcp_md5sig_mutex:
>>
>>
>> ======================================================
>> [ INFO: possible circular locking dependency detected ]
>> SELinux: unrecognized netlink message: protocol=9 nlmsg_type=2
>> sclass=netlink_audit_socket pig=4033 comm=syz-executor4
>> 4.10.0+ #5 Not tainted
>> -------------------------------------------------------
>> syz-executor8/4018 is trying to acquire lock:
>> (crypto_alg_sem){++++++}, at: [<ffffffff82193473>]
>> crypto_alg_lookup+0x23/0x50 crypto/api.c:199
>>
>> but task is already holding lock:
>> (tcp_md5sig_mutex){+.+...}, at: [<ffffffff838e4efa>]
>> tcp_alloc_md5sig_pool+0x4a/0x470 net/ipv4/tcp.c:3196
>>
>> which lock already depends on the new lock.
>>
>>
>> the existing dependency chain (in reverse order) is:
>>
>> -> #5 (tcp_md5sig_mutex){+.+...}:
>> validate_chain kernel/locking/lockdep.c:2267 [inline]
>> __lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3340
>> lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3755
>> __mutex_lock_common kernel/locking/mutex.c:756 [inline]
>> __mutex_lock+0x172/0x1730 kernel/locking/mutex.c:893
>> mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:908
>> tcp_alloc_md5sig_pool+0x4a/0x470 net/ipv4/tcp.c:3196
>> tcp_md5_do_add+0x1d8/0x5d0 net/ipv4/tcp_ipv4.c:969
>> tcp_v4_parse_md5_keys+0x1c7/0x2b0 net/ipv4/tcp_ipv4.c:1037
>> do_tcp_setsockopt.isra.36+0x657/0x20a0 net/ipv4/tcp.c:2668
>> tcp_setsockopt+0xb0/0xd0 net/ipv4/tcp.c:2733
>> sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2731
>> SYSC_setsockopt net/socket.c:1786 [inline]
>> SyS_setsockopt+0x25c/0x390 net/socket.c:1765
>> do_syscall_64+0x2e8/0x930 arch/x86/entry/common.c:281
>> return_from_SYSCALL_64+0x0/0x7a
>>
>> -> #4 (sk_lock-AF_INET){+.+.+.}:
>> validate_chain kernel/locking/lockdep.c:2267 [inline]
>> __lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3340
>> lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3755
>> lock_sock_nested+0xcb/0x120 net/core/sock.c:2536
>> lock_sock include/net/sock.h:1460 [inline]
>> do_ip_setsockopt.isra.12+0x301/0x3760 net/ipv4/ip_sockglue.c:653
>> ip_setsockopt+0x3a/0xb0 net/ipv4/ip_sockglue.c:1265
>> tcp_setsockopt+0x82/0xd0 net/ipv4/tcp.c:2731
>> sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2731
>> SYSC_setsockopt net/socket.c:1786 [inline]
>> SyS_setsockopt+0x25c/0x390 net/socket.c:1765
>> entry_SYSCALL_64_fastpath+0x1f/0xc2
>>
>> -> #3 (rtnl_mutex){+.+.+.}:
>> validate_chain kernel/locking/lockdep.c:2267 [inline]
>> __lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3340
>> lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3755
>> __mutex_lock_common kernel/locking/mutex.c:756 [inline]
>> __mutex_lock+0x172/0x1730 kernel/locking/mutex.c:893
>> mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:908
>> rtnl_lock+0x17/0x20 net/core/rtnetlink.c:70
>> nl80211_prepare_wdev_dump.isra.37+0x2c/0x5d0 net/wireless/nl80211.c:548
>> nl80211_dump_station+0x178/0xd80 net/wireless/nl80211.c:4455
>> genl_lock_dumpit+0x68/0x90 net/netlink/genetlink.c:479
>> netlink_dump+0x54d/0xd40 net/netlink/af_netlink.c:2127
>> __netlink_dump_start+0x4e5/0x760 net/netlink/af_netlink.c:2217
>> genl_family_rcv_msg+0xd9d/0x1040 net/netlink/genetlink.c:546
>> genl_rcv_msg+0xa6/0x140 net/netlink/genetlink.c:620
>> netlink_rcv_skb+0x2ab/0x390 net/netlink/af_netlink.c:2298
>> genl_rcv+0x28/0x40 net/netlink/genetlink.c:631
>> netlink_unicast_kernel net/netlink/af_netlink.c:1231 [inline]
>> netlink_unicast+0x514/0x730 net/netlink/af_netlink.c:1257
>> netlink_sendmsg+0xa9f/0xe50 net/netlink/af_netlink.c:1803
>> sock_sendmsg_nosec net/socket.c:633 [inline]
>> sock_sendmsg+0xca/0x110 net/socket.c:643
>> sock_write_iter+0x326/0x600 net/socket.c:846
>> call_write_iter include/linux/fs.h:1733 [inline]
>> new_sync_write fs/read_write.c:497 [inline]
>> __vfs_write+0x483/0x740 fs/read_write.c:510
>> vfs_write+0x187/0x530 fs/read_write.c:558
>> SYSC_write fs/read_write.c:605 [inline]
>> SyS_write+0xfb/0x230 fs/read_write.c:597
>> entry_SYSCALL_64_fastpath+0x1f/0xc2
>>
>> -> #2 (genl_mutex){+.+.+.}:
>> validate_chain kernel/locking/lockdep.c:2267 [inline]
>> __lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3340
>> lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3755
>> __mutex_lock_common kernel/locking/mutex.c:756 [inline]
>> __mutex_lock+0x172/0x1730 kernel/locking/mutex.c:893
>> mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:908
>> genl_lock net/netlink/genetlink.c:32 [inline]
>> genl_lock_dumpit+0x41/0x90 net/netlink/genetlink.c:478
>> netlink_dump+0x54d/0xd40 net/netlink/af_netlink.c:2127
>> __netlink_dump_start+0x4e5/0x760 net/netlink/af_netlink.c:2217
>> genl_family_rcv_msg+0xd9d/0x1040 net/netlink/genetlink.c:546
>> genl_rcv_msg+0xa6/0x140 net/netlink/genetlink.c:620
>> netlink_rcv_skb+0x2ab/0x390 net/netlink/af_netlink.c:2298
>> genl_rcv+0x28/0x40 net/netlink/genetlink.c:631
>> netlink_unicast_kernel net/netlink/af_netlink.c:1231 [inline]
>> netlink_unicast+0x514/0x730 net/netlink/af_netlink.c:1257
>> netlink_sendmsg+0xa9f/0xe50 net/netlink/af_netlink.c:1803
>> sock_sendmsg_nosec net/socket.c:633 [inline]
>> sock_sendmsg+0xca/0x110 net/socket.c:643
>> sock_write_iter+0x326/0x600 net/socket.c:846
>> call_write_iter include/linux/fs.h:1733 [inline]
>> new_sync_write fs/read_write.c:497 [inline]
>> __vfs_write+0x483/0x740 fs/read_write.c:510
>> vfs_write+0x187/0x530 fs/read_write.c:558
>> SYSC_write fs/read_write.c:605 [inline]
>> SyS_write+0xfb/0x230 fs/read_write.c:597
>> entry_SYSCALL_64_fastpath+0x1f/0xc2
>>
>> -> #1 (nlk->cb_mutex){+.+.+.}:
>> validate_chain kernel/locking/lockdep.c:2267 [inline]
>> __lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3340
>> lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3755
>> __mutex_lock_common kernel/locking/mutex.c:756 [inline]
>> __mutex_lock+0x172/0x1730 kernel/locking/mutex.c:893
>> mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:908
>> __netlink_dump_start+0xf4/0x760 net/netlink/af_netlink.c:2187
>> netlink_dump_start include/linux/netlink.h:165 [inline]
>> crypto_user_rcv_msg+0x2ad/0x4f0 crypto/crypto_user.c:517
>> netlink_rcv_skb+0x2ab/0x390 net/netlink/af_netlink.c:2298
>> crypto_netlink_rcv+0x2a/0x40 crypto/crypto_user.c:538
>> netlink_unicast_kernel net/netlink/af_netlink.c:1231 [inline]
>> netlink_unicast+0x514/0x730 net/netlink/af_netlink.c:1257
>> netlink_sendmsg+0xa9f/0xe50 net/netlink/af_netlink.c:1803
>> sock_sendmsg_nosec net/socket.c:633 [inline]
>> sock_sendmsg+0xca/0x110 net/socket.c:643
>> ___sys_sendmsg+0x8fa/0x9f0 net/socket.c:1985
>> __sys_sendmsg+0x138/0x300 net/socket.c:2019
>> SYSC_sendmsg net/socket.c:2030 [inline]
>> SyS_sendmsg+0x2d/0x50 net/socket.c:2026
>> entry_SYSCALL_64_fastpath+0x1f/0xc2
>>
>> -> #0 (crypto_alg_sem){++++++}:
>> check_prev_add kernel/locking/lockdep.c:1830 [inline]
>> check_prevs_add+0xa8f/0x19f0 kernel/locking/lockdep.c:1940
>> validate_chain kernel/locking/lockdep.c:2267 [inline]
>> __lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3340
>> lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3755
>> down_read+0x9b/0x150 kernel/locking/rwsem.c:23
>> crypto_alg_lookup+0x23/0x50 crypto/api.c:199
>> crypto_larval_lookup.part.10+0x9a/0x3b0 crypto/api.c:217
>> crypto_larval_lookup crypto/api.c:211 [inline]
>> crypto_alg_mod_lookup+0x77/0x1b0 crypto/api.c:270
>> crypto_find_alg crypto/api.c:500 [inline]
>> crypto_alloc_tfm+0x101/0x2e0 crypto/api.c:533
>> crypto_alloc_ahash+0x2c/0x40 crypto/ahash.c:525
>> __tcp_alloc_md5sig_pool net/ipv4/tcp.c:3158 [inline]
>> tcp_alloc_md5sig_pool+0x85/0x470 net/ipv4/tcp.c:3199
>> tcp_md5_do_add+0x1d8/0x5d0 net/ipv4/tcp_ipv4.c:969
>> tcp_v4_parse_md5_keys+0x1c7/0x2b0 net/ipv4/tcp_ipv4.c:1037
>> do_tcp_setsockopt.isra.36+0x657/0x20a0 net/ipv4/tcp.c:2668
>> tcp_setsockopt+0xb0/0xd0 net/ipv4/tcp.c:2733
>> sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2731
>> SYSC_setsockopt net/socket.c:1786 [inline]
>> SyS_setsockopt+0x25c/0x390 net/socket.c:1765
>> do_syscall_64+0x2e8/0x930 arch/x86/entry/common.c:281
>> return_from_SYSCALL_64+0x0/0x7a
>>
>> other info that might help us debug this:
>>
>> Chain exists of:
>> crypto_alg_sem --> sk_lock-AF_INET --> tcp_md5sig_mutex
>>
>> Possible unsafe locking scenario:
>>
>> CPU0 CPU1
>> ---- ----
>> lock(tcp_md5sig_mutex);
>> lock(sk_lock-AF_INET);
>> lock(tcp_md5sig_mutex);
>> lock(crypto_alg_sem);
>>
>> *** DEADLOCK ***
>>
>> 2 locks held by syz-executor8/4018:
>> #0: (sk_lock-AF_INET){+.+.+.}, at: [<ffffffff838e7a26>] lock_sock
>> include/net/sock.h:1460 [inline]
>> #0: (sk_lock-AF_INET){+.+.+.}, at: [<ffffffff838e7a26>]
>> do_tcp_setsockopt.isra.36+0x216/0x20a0 net/ipv4/tcp.c:2466
>> #1: (tcp_md5sig_mutex){+.+...}, at: [<ffffffff838e4efa>]
>> tcp_alloc_md5sig_pool+0x4a/0x470 net/ipv4/tcp.c:3196
>>
>> stack backtrace:
>> CPU: 0 PID: 4018 Comm: syz-executor8 Not tainted 4.10.0+ #5
>> Hardware name: Google Google Compute Engine/Google Compute Engine,
>> BIOS Google 01/01/2011
>> Call Trace:
>> __dump_stack lib/dump_stack.c:16 [inline]
>> dump_stack+0x2ee/0x3ef lib/dump_stack.c:52
>> print_circular_bug+0x307/0x3b0 kernel/locking/lockdep.c:1204
>> check_prev_add kernel/locking/lockdep.c:1830 [inline]
>> check_prevs_add+0xa8f/0x19f0 kernel/locking/lockdep.c:1940
>> validate_chain kernel/locking/lockdep.c:2267 [inline]
>> __lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3340
>> lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3755
>> down_read+0x9b/0x150 kernel/locking/rwsem.c:23
>> crypto_alg_lookup+0x23/0x50 crypto/api.c:199
>> crypto_larval_lookup.part.10+0x9a/0x3b0 crypto/api.c:217
>> crypto_larval_lookup crypto/api.c:211 [inline]
>> crypto_alg_mod_lookup+0x77/0x1b0 crypto/api.c:270
>> crypto_find_alg crypto/api.c:500 [inline]
>> crypto_alloc_tfm+0x101/0x2e0 crypto/api.c:533
>> crypto_alloc_ahash+0x2c/0x40 crypto/ahash.c:525
>> __tcp_alloc_md5sig_pool net/ipv4/tcp.c:3158 [inline]
>> tcp_alloc_md5sig_pool+0x85/0x470 net/ipv4/tcp.c:3199
>> tcp_md5_do_add+0x1d8/0x5d0 net/ipv4/tcp_ipv4.c:969
>> tcp_v4_parse_md5_keys+0x1c7/0x2b0 net/ipv4/tcp_ipv4.c:1037
>> do_tcp_setsockopt.isra.36+0x657/0x20a0 net/ipv4/tcp.c:2668
>> tcp_setsockopt+0xb0/0xd0 net/ipv4/tcp.c:2733
>> sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2731
>> SYSC_setsockopt net/socket.c:1786 [inline]
>> SyS_setsockopt+0x25c/0x390 net/socket.c:1765
>> do_syscall_64+0x2e8/0x930 arch/x86/entry/common.c:281
>
>
>
> Another one:
>
> ======================================================
> [ INFO: possible circular locking dependency detected ]
> 4.10.0+ #6 Not tainted
> -------------------------------------------------------
> syz-executor8/3613 is trying to acquire lock:
> (sk_lock-AF_INET6){+.+.+.}, at: [<ffffffff83b72eb9>] lock_sock
> include/net/sock.h:1460 [inline]
> (sk_lock-AF_INET6){+.+.+.}, at: [<ffffffff83b72eb9>]
> do_ipv6_setsockopt.isra.11+0x229/0x36e0 net/ipv6/ipv6_sockglue.c:167
>
> but task is already holding lock:
> (rtnl_mutex){+.+.+.}, at: [<ffffffff8370a197>] rtnl_lock+0x17/0x20
> net/core/rtnetlink.c:70
>
> which lock already depends on the new lock.
>
>
> the existing dependency chain (in reverse order) is:
>
> -> #4 (rtnl_mutex){+.+.+.}:
> validate_chain kernel/locking/lockdep.c:2267 [inline]
> __lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3340
> lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3755
> __mutex_lock_common kernel/locking/mutex.c:756 [inline]
> __mutex_lock+0x172/0x1730 kernel/locking/mutex.c:893
> mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:908
> rtnl_lock+0x17/0x20 net/core/rtnetlink.c:70
> tipc_nl_node_dump_monitor+0x260/0x510 net/tipc/node.c:2128
> genl_lock_dumpit+0x68/0x90 net/netlink/genetlink.c:479
> netlink_dump+0x54d/0xd40 net/netlink/af_netlink.c:2127
> __netlink_dump_start+0x4e5/0x760 net/netlink/af_netlink.c:2217
> genl_family_rcv_msg+0xd9d/0x1040 net/netlink/genetlink.c:546
> genl_rcv_msg+0xa6/0x140 net/netlink/genetlink.c:620
> netlink_rcv_skb+0x2ab/0x390 net/netlink/af_netlink.c:2298
> genl_rcv+0x28/0x40 net/netlink/genetlink.c:631
> netlink_unicast_kernel net/netlink/af_netlink.c:1231 [inline]
> netlink_unicast+0x514/0x730 net/netlink/af_netlink.c:1257
> netlink_sendmsg+0xa9f/0xe50 net/netlink/af_netlink.c:1803
> sock_sendmsg_nosec net/socket.c:633 [inline]
> sock_sendmsg+0xca/0x110 net/socket.c:643
> sock_write_iter+0x326/0x600 net/socket.c:846
> call_write_iter include/linux/fs.h:1733 [inline]
> new_sync_write fs/read_write.c:497 [inline]
> __vfs_write+0x483/0x740 fs/read_write.c:510
> vfs_write+0x187/0x530 fs/read_write.c:558
> SYSC_write fs/read_write.c:605 [inline]
> SyS_write+0xfb/0x230 fs/read_write.c:597
> entry_SYSCALL_64_fastpath+0x1f/0xc2
>
> -> #3 (genl_mutex){+.+.+.}:
> validate_chain kernel/locking/lockdep.c:2267 [inline]
> __lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3340
> lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3755
> __mutex_lock_common kernel/locking/mutex.c:756 [inline]
> __mutex_lock+0x172/0x1730 kernel/locking/mutex.c:893
> mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:908
> genl_lock net/netlink/genetlink.c:32 [inline]
> genl_lock_dumpit+0x41/0x90 net/netlink/genetlink.c:478
> netlink_dump+0x54d/0xd40 net/netlink/af_netlink.c:2127
> __netlink_dump_start+0x4e5/0x760 net/netlink/af_netlink.c:2217
> genl_family_rcv_msg+0xd9d/0x1040 net/netlink/genetlink.c:546
> genl_rcv_msg+0xa6/0x140 net/netlink/genetlink.c:620
> netlink_rcv_skb+0x2ab/0x390 net/netlink/af_netlink.c:2298
> genl_rcv+0x28/0x40 net/netlink/genetlink.c:631
> netlink_unicast_kernel net/netlink/af_netlink.c:1231 [inline]
> netlink_unicast+0x514/0x730 net/netlink/af_netlink.c:1257
> netlink_sendmsg+0xa9f/0xe50 net/netlink/af_netlink.c:1803
> sock_sendmsg_nosec net/socket.c:633 [inline]
> sock_sendmsg+0xca/0x110 net/socket.c:643
> sock_write_iter+0x326/0x600 net/socket.c:846
> call_write_iter include/linux/fs.h:1733 [inline]
> new_sync_write fs/read_write.c:497 [inline]
> __vfs_write+0x483/0x740 fs/read_write.c:510
> vfs_write+0x187/0x530 fs/read_write.c:558
> SYSC_write fs/read_write.c:605 [inline]
> SyS_write+0xfb/0x230 fs/read_write.c:597
> entry_SYSCALL_64_fastpath+0x1f/0xc2
>
> -> #2 (nlk->cb_mutex){+.+.+.}:
> validate_chain kernel/locking/lockdep.c:2267 [inline]
> __lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3340
> lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3755
> __mutex_lock_common kernel/locking/mutex.c:756 [inline]
> __mutex_lock+0x172/0x1730 kernel/locking/mutex.c:893
> mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:908
> __netlink_dump_start+0xf4/0x760 net/netlink/af_netlink.c:2187
> netlink_dump_start include/linux/netlink.h:165 [inline]
> crypto_user_rcv_msg+0x2ad/0x4f0 crypto/crypto_user.c:517
> netlink_rcv_skb+0x2ab/0x390 net/netlink/af_netlink.c:2298
> crypto_netlink_rcv+0x2a/0x40 crypto/crypto_user.c:538
> netlink_unicast_kernel net/netlink/af_netlink.c:1231 [inline]
> netlink_unicast+0x514/0x730 net/netlink/af_netlink.c:1257
> netlink_sendmsg+0xa9f/0xe50 net/netlink/af_netlink.c:1803
> sock_sendmsg_nosec net/socket.c:633 [inline]
> sock_sendmsg+0xca/0x110 net/socket.c:643
> ___sys_sendmsg+0x8fa/0x9f0 net/socket.c:1985
> __sys_sendmsg+0x138/0x300 net/socket.c:2019
> SYSC_sendmsg net/socket.c:2030 [inline]
> SyS_sendmsg+0x2d/0x50 net/socket.c:2026
> entry_SYSCALL_64_fastpath+0x1f/0xc2
>
> -> #1 (crypto_alg_sem){++++++}:
> validate_chain kernel/locking/lockdep.c:2267 [inline]
> __lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3340
> lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3755
> down_read+0x9b/0x150 kernel/locking/rwsem.c:23
> crypto_alg_lookup+0x23/0x50 crypto/api.c:199
> crypto_larval_lookup.part.10+0x9a/0x3b0 crypto/api.c:217
> crypto_larval_lookup crypto/api.c:211 [inline]
> crypto_alg_mod_lookup+0x77/0x1b0 crypto/api.c:270
> crypto_find_alg crypto/api.c:500 [inline]
> crypto_alloc_tfm+0x101/0x2e0 crypto/api.c:533
> crypto_alloc_shash+0x2c/0x40 crypto/shash.c:433
> sctp_listen_start net/sctp/socket.c:6969 [inline]
> sctp_inet_listen+0x5b7/0x7e0 net/sctp/socket.c:7054
> SYSC_listen net/socket.c:1440 [inline]
> SyS_listen+0x2c9/0x390 net/socket.c:1426
> entry_SYSCALL_64_fastpath+0x1f/0xc2
>
> -> #0 (sk_lock-AF_INET6){+.+.+.}:
> check_prev_add kernel/locking/lockdep.c:1830 [inline]
> check_prevs_add+0xa8f/0x19f0 kernel/locking/lockdep.c:1940
> validate_chain kernel/locking/lockdep.c:2267 [inline]
> __lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3340
> lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3755
> lock_sock_nested+0xcb/0x120 net/core/sock.c:2536
> lock_sock include/net/sock.h:1460 [inline]
> do_ipv6_setsockopt.isra.11+0x229/0x36e0 net/ipv6/ipv6_sockglue.c:167
> ipv6_setsockopt+0x9b/0x140 net/ipv6/ipv6_sockglue.c:919
> tcp_setsockopt+0x82/0xd0 net/ipv4/tcp.c:2731
> sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2731
> SYSC_setsockopt net/socket.c:1786 [inline]
> SyS_setsockopt+0x25c/0x390 net/socket.c:1765
> entry_SYSCALL_64_fastpath+0x1f/0xc2
>
> other info that might help us debug this:
>
> Chain exists of:
> sk_lock-AF_INET6 --> genl_mutex --> rtnl_mutex
>
> Possible unsafe locking scenario:
>
> CPU0 CPU1
> ---- ----
> lock(rtnl_mutex);
> lock(genl_mutex);
> lock(rtnl_mutex);
> lock(sk_lock-AF_INET6);
>
> *** DEADLOCK ***
>
> 1 lock held by syz-executor8/3613:
> #0: (rtnl_mutex){+.+.+.}, at: [<ffffffff8370a197>]
> rtnl_lock+0x17/0x20 net/core/rtnetlink.c:70
>
> stack backtrace:
> CPU: 1 PID: 3613 Comm: syz-executor8 Not tainted 4.10.0+ #6
> Hardware name: Google Google Compute Engine/Google Compute Engine,
> BIOS Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:16 [inline]
> dump_stack+0x2ee/0x3ef lib/dump_stack.c:52
> print_circular_bug+0x307/0x3b0 kernel/locking/lockdep.c:1204
> check_prev_add kernel/locking/lockdep.c:1830 [inline]
> check_prevs_add+0xa8f/0x19f0 kernel/locking/lockdep.c:1940
> validate_chain kernel/locking/lockdep.c:2267 [inline]
> __lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3340
> lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3755
> lock_sock_nested+0xcb/0x120 net/core/sock.c:2536
> lock_sock include/net/sock.h:1460 [inline]
> do_ipv6_setsockopt.isra.11+0x229/0x36e0 net/ipv6/ipv6_sockglue.c:167
> ipv6_setsockopt+0x9b/0x140 net/ipv6/ipv6_sockglue.c:919
> tcp_setsockopt+0x82/0xd0 net/ipv4/tcp.c:2731
> sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2731
> SYSC_setsockopt net/socket.c:1786 [inline]
> SyS_setsockopt+0x25c/0x390 net/socket.c:1765
Another one now involving rds_tcp_listen_stop (on net-next
3e3eec09311a48c64104cafa193984cc807ab9e0):
[ INFO: possible circular locking dependency detected ]
4.10.0+ #26 Not tainted
-------------------------------------------------------
kworker/u4:1/19 is trying to acquire lock:
(sk_lock-AF_INET){+.+.+.}, at: [<ffffffff8409a6ec>] lock_sock
include/net/sock.h:1460 [inline]
(sk_lock-AF_INET){+.+.+.}, at: [<ffffffff8409a6ec>]
rds_tcp_listen_stop+0x5c/0x150 net/rds/tcp_listen.c:288
but task is already holding lock:
(rtnl_mutex){+.+.+.}, at: [<ffffffff8370b057>] rtnl_lock+0x17/0x20
net/core/rtnetlink.c:70
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #4 (rtnl_mutex){+.+.+.}:
validate_chain kernel/locking/lockdep.c:2267 [inline]
__lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3340
lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3755
__mutex_lock_common kernel/locking/mutex.c:756 [inline]
__mutex_lock+0x172/0x1730 kernel/locking/mutex.c:893
mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:908
rtnl_lock+0x17/0x20 net/core/rtnetlink.c:70
nl80211_prepare_vendor_dump net/wireless/nl80211.c:11511 [inline]
nl80211_vendor_cmd_dump+0xda/0x1ab0 net/wireless/nl80211.c:11616
genl_lock_dumpit+0x68/0x90 net/netlink/genetlink.c:479
netlink_dump+0x54d/0xd40 net/netlink/af_netlink.c:2127
__netlink_dump_start+0x4e5/0x760 net/netlink/af_netlink.c:2217
genl_family_rcv_msg+0xd9d/0x1040 net/netlink/genetlink.c:546
genl_rcv_msg+0xa6/0x140 net/netlink/genetlink.c:620
netlink_rcv_skb+0x2ab/0x390 net/netlink/af_netlink.c:2298
genl_rcv+0x28/0x40 net/netlink/genetlink.c:631
netlink_unicast_kernel net/netlink/af_netlink.c:1231 [inline]
netlink_unicast+0x514/0x730 net/netlink/af_netlink.c:1257
netlink_sendmsg+0xa9f/0xe50 net/netlink/af_netlink.c:1803
sock_sendmsg_nosec net/socket.c:633 [inline]
sock_sendmsg+0xca/0x110 net/socket.c:643
___sys_sendmsg+0x8fa/0x9f0 net/socket.c:1985
__sys_sendmsg+0x138/0x300 net/socket.c:2019
SYSC_sendmsg net/socket.c:2030 [inline]
SyS_sendmsg+0x2d/0x50 net/socket.c:2026
entry_SYSCALL_64_fastpath+0x1f/0xc2
-> #3 (genl_mutex){+.+.+.}:
validate_chain kernel/locking/lockdep.c:2267 [inline]
__lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3340
lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3755
__mutex_lock_common kernel/locking/mutex.c:756 [inline]
__mutex_lock+0x172/0x1730 kernel/locking/mutex.c:893
mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:908
genl_lock net/netlink/genetlink.c:32 [inline]
genl_lock_dumpit+0x41/0x90 net/netlink/genetlink.c:478
netlink_dump+0x54d/0xd40 net/netlink/af_netlink.c:2127
__netlink_dump_start+0x4e5/0x760 net/netlink/af_netlink.c:2217
genl_family_rcv_msg+0xd9d/0x1040 net/netlink/genetlink.c:546
genl_rcv_msg+0xa6/0x140 net/netlink/genetlink.c:620
netlink_rcv_skb+0x2ab/0x390 net/netlink/af_netlink.c:2298
genl_rcv+0x28/0x40 net/netlink/genetlink.c:631
netlink_unicast_kernel net/netlink/af_netlink.c:1231 [inline]
netlink_unicast+0x514/0x730 net/netlink/af_netlink.c:1257
netlink_sendmsg+0xa9f/0xe50 net/netlink/af_netlink.c:1803
sock_sendmsg_nosec net/socket.c:633 [inline]
sock_sendmsg+0xca/0x110 net/socket.c:643
___sys_sendmsg+0x8fa/0x9f0 net/socket.c:1985
__sys_sendmsg+0x138/0x300 net/socket.c:2019
SYSC_sendmsg net/socket.c:2030 [inline]
SyS_sendmsg+0x2d/0x50 net/socket.c:2026
entry_SYSCALL_64_fastpath+0x1f/0xc2
-> #2 (nlk->cb_mutex){+.+.+.}:
validate_chain kernel/locking/lockdep.c:2267 [inline]
__lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3340
lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3755
__mutex_lock_common kernel/locking/mutex.c:756 [inline]
__mutex_lock+0x172/0x1730 kernel/locking/mutex.c:893
mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:908
__netlink_dump_start+0xf4/0x760 net/netlink/af_netlink.c:2187
netlink_dump_start include/linux/netlink.h:165 [inline]
crypto_user_rcv_msg+0x2ad/0x4f0 crypto/crypto_user.c:517
netlink_rcv_skb+0x2ab/0x390 net/netlink/af_netlink.c:2298
crypto_netlink_rcv+0x2a/0x40 crypto/crypto_user.c:538
netlink_unicast_kernel net/netlink/af_netlink.c:1231 [inline]
netlink_unicast+0x514/0x730 net/netlink/af_netlink.c:1257
netlink_sendmsg+0xa9f/0xe50 net/netlink/af_netlink.c:1803
sock_sendmsg_nosec net/socket.c:633 [inline]
sock_sendmsg+0xca/0x110 net/socket.c:643
___sys_sendmsg+0x8fa/0x9f0 net/socket.c:1985
__sys_sendmsg+0x138/0x300 net/socket.c:2019
SYSC_sendmsg net/socket.c:2030 [inline]
SyS_sendmsg+0x2d/0x50 net/socket.c:2026
entry_SYSCALL_64_fastpath+0x1f/0xc2
-> #1 (crypto_alg_sem){++++++}:
validate_chain kernel/locking/lockdep.c:2267 [inline]
__lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3340
lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3755
down_read+0x9b/0x150 kernel/locking/rwsem.c:23
crypto_alg_lookup+0x23/0x50 crypto/api.c:199
crypto_larval_lookup.part.10+0x9a/0x3b0 crypto/api.c:217
crypto_larval_lookup crypto/api.c:211 [inline]
crypto_alg_mod_lookup+0x77/0x1b0 crypto/api.c:270
crypto_find_alg crypto/api.c:500 [inline]
crypto_alloc_tfm+0x101/0x2e0 crypto/api.c:533
crypto_alloc_shash+0x2c/0x40 crypto/shash.c:433
sctp_listen_start net/sctp/socket.c:7050 [inline]
sctp_inet_listen+0x5b7/0x7e0 net/sctp/socket.c:7135
SYSC_listen net/socket.c:1440 [inline]
SyS_listen+0x2c9/0x390 net/socket.c:1426
entry_SYSCALL_64_fastpath+0x1f/0xc2
-> #0 (sk_lock-AF_INET){+.+.+.}:
check_prev_add kernel/locking/lockdep.c:1830 [inline]
check_prevs_add+0xa8f/0x19f0 kernel/locking/lockdep.c:1940
validate_chain kernel/locking/lockdep.c:2267 [inline]
__lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3340
lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3755
lock_sock_nested+0xcb/0x120 net/core/sock.c:2596
lock_sock include/net/sock.h:1460 [inline]
rds_tcp_listen_stop+0x5c/0x150 net/rds/tcp_listen.c:288
rds_tcp_kill_sock net/rds/tcp.c:532 [inline]
rds_tcp_dev_event+0x38e/0xc20 net/rds/tcp.c:573
notifier_call_chain+0x1b5/0x2b0 kernel/notifier.c:93
__raw_notifier_call_chain kernel/notifier.c:394 [inline]
raw_notifier_call_chain+0x2d/0x40 kernel/notifier.c:401
call_netdevice_notifiers_info+0x51/0x90 net/core/dev.c:1646
call_netdevice_notifiers net/core/dev.c:1662 [inline]
netdev_run_todo+0x3b2/0xa30 net/core/dev.c:7530
rtnl_unlock+0xe/0x10 net/core/rtnetlink.c:104
default_device_exit_batch+0x504/0x620 net/core/dev.c:8334
ops_exit_list.isra.6+0x100/0x150 net/core/net_namespace.c:144
cleanup_net+0x551/0xa90 net/core/net_namespace.c:463
process_one_work+0xbd0/0x1c10 kernel/workqueue.c:2096
worker_thread+0x223/0x1990 kernel/workqueue.c:2230
kthread+0x326/0x3f0 kernel/kthread.c:229
ret_from_fork+0x31/0x40 arch/x86/entry/entry_64.S:430
other info that might help us debug this:
Chain exists of:
sk_lock-AF_INET --> genl_mutex --> rtnl_mutex
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(rtnl_mutex);
lock(genl_mutex);
lock(rtnl_mutex);
lock(sk_lock-AF_INET);
*** DEADLOCK ***
4 locks held by kworker/u4:1/19:
#0: ("%s""netns"){.+.+.+}, at: [<ffffffff81497943>]
__write_once_size include/linux/compiler.h:283 [inline]
#0: ("%s""netns"){.+.+.+}, at: [<ffffffff81497943>] atomic64_set
arch/x86/include/asm/atomic64_64.h:33 [inline]
#0: ("%s""netns"){.+.+.+}, at: [<ffffffff81497943>] atomic_long_set
include/asm-generic/atomic-long.h:56 [inline]
#0: ("%s""netns"){.+.+.+}, at: [<ffffffff81497943>] set_work_data
kernel/workqueue.c:617 [inline]
#0: ("%s""netns"){.+.+.+}, at: [<ffffffff81497943>]
set_work_pool_and_clear_pending kernel/workqueue.c:644 [inline]
#0: ("%s""netns"){.+.+.+}, at: [<ffffffff81497943>]
process_one_work+0xab3/0x1c10 kernel/workqueue.c:2089
#1: (net_cleanup_work){+.+.+.}, at: [<ffffffff81497997>]
process_one_work+0xb07/0x1c10 kernel/workqueue.c:2093
#2: (net_mutex){+.+.+.}, at: [<ffffffff836965cb>]
cleanup_net+0x22b/0xa90 net/core/net_namespace.c:429
#3: (rtnl_mutex){+.+.+.}, at: [<ffffffff8370b057>]
rtnl_lock+0x17/0x20 net/core/rtnetlink.c:70
stack backtrace:
CPU: 0 PID: 19 Comm: kworker/u4:1 Not tainted 4.10.0+ #26
Hardware name: Google Google Compute Engine/Google Compute Engine,
BIOS Google 01/01/2011
Workqueue: netns cleanup_net
Call Trace:
__dump_stack lib/dump_stack.c:16 [inline]
dump_stack+0x2ee/0x3ef lib/dump_stack.c:52
print_circular_bug+0x307/0x3b0 kernel/locking/lockdep.c:1204
check_prev_add kernel/locking/lockdep.c:1830 [inline]
check_prevs_add+0xa8f/0x19f0 kernel/locking/lockdep.c:1940
validate_chain kernel/locking/lockdep.c:2267 [inline]
__lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3340
lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3755
lock_sock_nested+0xcb/0x120 net/core/sock.c:2596
lock_sock include/net/sock.h:1460 [inline]
rds_tcp_listen_stop+0x5c/0x150 net/rds/tcp_listen.c:288
rds_tcp_kill_sock net/rds/tcp.c:532 [inline]
rds_tcp_dev_event+0x38e/0xc20 net/rds/tcp.c:573
notifier_call_chain+0x1b5/0x2b0 kernel/notifier.c:93
__raw_notifier_call_chain kernel/notifier.c:394 [inline]
raw_notifier_call_chain+0x2d/0x40 kernel/notifier.c:401
call_netdevice_notifiers_info+0x51/0x90 net/core/dev.c:1646
call_netdevice_notifiers net/core/dev.c:1662 [inline]
netdev_run_todo+0x3b2/0xa30 net/core/dev.c:7530
rtnl_unlock+0xe/0x10 net/core/rtnetlink.c:104
default_device_exit_batch+0x504/0x620 net/core/dev.c:8334
ops_exit_list.isra.6+0x100/0x150 net/core/net_namespace.c:144
cleanup_net+0x551/0xa90 net/core/net_namespace.c:463
process_one_work+0xbd0/0x1c10 kernel/workqueue.c:2096
worker_thread+0x223/0x1990 kernel/workqueue.c:2230
kthread+0x326/0x3f0 kernel/kthread.c:229
ret_from_fork+0x31/0x40 arch/x86/entry/entry_64.S:430
^ permalink raw reply
* Re: [PATCH] crypto: ccp - Assign DMA commands to the channel's CCP
From: Stephan Müller @ 2017-03-14 7:17 UTC (permalink / raw)
To: Gary R Hook; +Cc: linux-crypto@vger.kernel.org
In-Reply-To: <c50f3dd1-ba28-bc67-4a19-e608d223251f@amd.com>
Am Montag, 13. März 2017, 20:35:07 CET schrieb Gary R Hook:
Hi Gary,
> On 03/03/2017 7:15 AM, Stephan Mueller wrote:
> > Am Donnerstag, 2. März 2017, 22:26:54 CET schrieb Gary R Hook:
> >
> > Hi Gary,
>
> Thanks for your comments, Stephan.
>
> > > A version 5 device provides the primitive commands
> > > required for AES GCM. This patch adds support for
> > > en/decryption.
> > >
> > > Signed-off-by: Gary R Hook <gary.hook@amd.com>
> > > ---
> > >
> > > drivers/crypto/ccp/Makefile | 1
> > > drivers/crypto/ccp/ccp-crypto-aes-galois.c | 257
> > >
> > > ++++++++++++++++++++++++++++ drivers/crypto/ccp/ccp-crypto-main.c
> > > |
> > > 12 +
> > >
> > > drivers/crypto/ccp/ccp-crypto.h | 14 ++
> > > drivers/crypto/ccp/ccp-dev-v5.c | 2
> > > drivers/crypto/ccp/ccp-dev.h | 1
> > > drivers/crypto/ccp/ccp-ops.c | 252
> > >
> > > +++++++++++++++++++++++++++ include/linux/ccp.h |
> > > 9 +
> > >
> > > 8 files changed, 548 insertions(+)
> > > create mode 100644 drivers/crypto/ccp/ccp-crypto-aes-galois.c
> > >
> > > diff --git a/drivers/crypto/ccp/ccp-crypto-aes-galois.c
> > > b/drivers/crypto/ccp/ccp-crypto-aes-galois.c new file mode 100644
> > > index 0000000..8bc18c9
> > > --- /dev/null
> > > +++ b/drivers/crypto/ccp/ccp-crypto-aes-galois.c
> > > @@ -0,0 +1,257 @@
> > > +/*
> > > + * AMD Cryptographic Coprocessor (CCP) AES GCM crypto API support
> > > + *
> > > + * Copyright (C) 2016 Advanced Micro Devices, Inc.
> > > + *
> > > + * Author: Gary R Hook <gary.hook@amd.com>
> > > + *
> > > + * This program is free software; you can redistribute it and/or modify
> > > + * it under the terms of the GNU General Public License version 2 as
> > > + * published by the Free Software Foundation.
> > > + */
> > > +
> > > +#include <linux/module.h>
> > > +#include <linux/sched.h>
> > > +#include <linux/delay.h>
> > > +#include <linux/scatterlist.h>
> > > +#include <linux/crypto.h>
> > > +#include <crypto/internal/aead.h>
> > > +#include <crypto/algapi.h>
> > > +#include <crypto/aes.h>
> > > +#include <crypto/ctr.h>
> > > +#include <crypto/scatterwalk.h>
> > > +#include <linux/delay.h>
> > > +
> > > +#include "ccp-crypto.h"
> > > +
> > > +#define AES_GCM_IVSIZE 12
> > > +
> > > +static int ccp_aes_gcm_complete(struct crypto_async_request *async_req,
> > > int ret) +{
> > > + return ret;
> > > +}
> > > +
> > > +static int ccp_aes_gcm_setkey(struct crypto_aead *tfm, const u8 *key,
> > > + unsigned int key_len)
> > > +{
> > > + struct ccp_ctx *ctx = crypto_aead_ctx(tfm);
> > > +
> > > + switch (key_len) {
> > > + case AES_KEYSIZE_128:
> > > + ctx->u.aes.type = CCP_AES_TYPE_128;
> > > + break;
> > > + case AES_KEYSIZE_192:
> > > + ctx->u.aes.type = CCP_AES_TYPE_192;
> > > + break;
> > > + case AES_KEYSIZE_256:
> > > + ctx->u.aes.type = CCP_AES_TYPE_256;
> > > + break;
> > > + default:
> > > + crypto_aead_set_flags(tfm, CRYPTO_TFM_RES_BAD_KEY_LEN);
> > > + return -EINVAL;
> > > + }
> > > +
> > > + ctx->u.aes.mode = CCP_AES_MODE_GCM;
> > > + ctx->u.aes.key_len = key_len;
> > > +
> > > + memcpy(ctx->u.aes.key, key, key_len);
> > > + sg_init_one(&ctx->u.aes.key_sg, ctx->u.aes.key, key_len);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int ccp_aes_gcm_setauthsize(struct crypto_aead *tfm,
> > > + unsigned int authsize)
> > > +{
> > > + return 0;
> > > +}
> > > +
> > > +static int ccp_aes_gcm_crypt(struct aead_request *req, bool encrypt)
> > > +{
> > > + struct crypto_aead *tfm = crypto_aead_reqtfm(req);
> > > + struct ccp_ctx *ctx = crypto_aead_ctx(tfm);
> > > + struct ccp_aes_req_ctx *rctx = aead_request_ctx(req);
> > > + struct scatterlist *iv_sg = NULL;
> > > + unsigned int iv_len = 0;
> > > + int i;
> > > + int ret = 0;
> > > +
> > > + if (!ctx->u.aes.key_len)
> > > + return -EINVAL;
> > > +
> > > + if (ctx->u.aes.mode != CCP_AES_MODE_GCM)
> > > + return -EINVAL;
> > > +
> > > + if (!req->iv)
> > > + return -EINVAL;
> > > +
> > > + /*
> > > + * 5 parts:
> > > + * plaintext/ciphertext input
> > > + * AAD
> > > + * key
> > > + * IV
> > > + * Destination+tag buffer
> > > + */
> > > +
> > > + /* According to the way AES GCM has been implemented here,
> > > + * per RFC 4106 it seems, the provided IV is fixed at 12 bytes,
> >
> > When you have that restriction, should the cipher be called
> > rfc4106(gcm(aes))?
> >
> > But then, the key is 4 bytes longer than a normal AES key as it contains
> > the leading 32 bits of the IV.
>
> I had my wires crossed due to an incomplete understanding of an AEAD cipher
> in general, and GCM in particular. I'm hopeful that someone can help me
> understand:
>
> For the AES GCM encryption tests in testmgr.h, where there is an IV,
> they're all
> 12 bytes in length. As I understand AES GCM the IV can be anywhere from
> 1 to 2^64
> bits in length; the value of 96 makes for convenience and efficiency.
> But it's
> neither a requirement nor restriction.
That is correct. For longer IVs, you would need to use Ghash to compress it to
96 bits. The remaining 32 bits to get to one AES block is the counter that is
used for the CTR AES mode in GCM.
>
> There are no tests (in testmgr.h) that use an IV length other than 0 or 96.
See aes_gcm_rfc4106_enc_tv_template for other types of IV.
> My comment about RFC4106 has to do with requiring an IV 0f 96 bits + a word
> that
> is incremented for each block (making every nonce unique, per the
> requirement).
> But let's ignore that, please.
>
> It looks as if:
>
> What seems to be missing is the ability to register a (GCM) transform
> that can
> handle an IV of arbitrary (allowable) length. I have to specify the
> length (ivsize)
> when I register an algorithm, and everything I see in the existing code
> appears
> to expect a GCM ivsize to be 96 bits, period (or zero). This is what I
> meant when
> I referenced RFC4106: I perceive restrictions not in my code, but n the
> way GCM seems
> to be supported in the crypto AEAD framework. A complete GCM
> implementation would not
> seem to have a restriction to a specific IV length (rather, a range of
> allowed
> values).
96 bits is the use case in IPSEC. As the kernel crypto API transforms are used
for IPSEC. Nobody would prevent you from supporting other IV sizes. But then
you would need to add a Ghash operation to compress it to the right length. No
other GCM implementation has that and hence the limitation.
But 96 bits is not the common case. See the 4106 implementations, you see the
ivsize being 8. This is correct because setkey requires AES keysize + 4 bytes
in length (see crypto_rfc4106_setkey for an example). The trailing 4 bytes of
the key are the initial 4 bytes of the GCM IV.
My comment was about your comment to refer to RFC4106. I just wanted to
understand your code and and make sense of your comments. :-)
>
> Is my reading of the GCM description in error? Do we need/want the ability
> to have a flexible IV length for GCM? What am I not understanding?
In your case, just change the wording in the comment slightly and we are all
good.
>
> For reference, I'm working from the NIST doc:
> http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/gcm/gcm-s
> pec.pdf
>
> > > + rctx->cmd.u.aes.key = &ctx->u.aes.key_sg;
> > > + rctx->cmd.u.aes.key_len = ctx->u.aes.key_len;
> > > + rctx->cmd.u.aes.iv = iv_sg;
> > > + rctx->cmd.u.aes.iv_len = iv_len;
> > > + rctx->cmd.u.aes.src = req->src;
> > > + rctx->cmd.u.aes.src_len = req->cryptlen;
> > > + rctx->cmd.u.aes.aad_len = req->assoclen;
> >
> > Just to be on the safe side: is the implementation good when cryptlen or
> > assoclen is 0?
>
> The engine has been designed to handle those two conditions. I've been
> watching the discussions around these issues.
>
> The first encryption test in testmgr.h has no input data nor IV. This
> implementation passes that test.
>
> The second encryption test in testmgr.h has input data but no IV, and this
> implementation passes.
>
> Is that an acceptable validation, or do we need more?
I would recommend at least a private test with no input and no AAD (i.e.
authentication only).
Maybe you can add a patch to testmgr for this case. An example is found at
[1]. Here, tag and exp is the expected result of the operation.
[1] https://github.com/smuellerDD/libkcapi/blob/master/test/test.sh#L330
>
> Thanks,
> Gary
Ciao
Stephan
^ permalink raw reply
* Re: [RFC PATCH v2 06/32] x86/pci: Use memremap when walking setup data
From: Tom Lendacky @ 2017-03-13 20:08 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Brijesh Singh, simon.guinot, linux-efi, kvm, rkrcmar, matt,
linux-pci, linus.walleij, gary.hook, linux-mm, paul.gortmaker,
hpa, cl, dan.j.williams, aarcange, sfr, andriy.shevchenko,
herbert, bhe, xemul, joro, x86, peterz, piotr.luc, mingo, msalter,
ross.zwisler, bp, dyoung, jroedel, keescook, arnd, toshi.kani,
mathieu.desnoyers, luto, devel, <bhe
In-Reply-To: <20170307000349.GC5305@bhelgaas-glaptop.roam.corp.google.com>
On 3/6/2017 6:03 PM, Bjorn Helgaas wrote:
> On Fri, Mar 03, 2017 at 03:15:34PM -0600, Tom Lendacky wrote:
>> On 3/3/2017 2:42 PM, Bjorn Helgaas wrote:
>>> On Thu, Mar 02, 2017 at 10:13:10AM -0500, Brijesh Singh wrote:
>>>> From: Tom Lendacky <thomas.lendacky@amd.com>
>>>>
>>>> The use of ioremap will force the setup data to be mapped decrypted even
>>>> though setup data is encrypted. Switch to using memremap which will be
>>>> able to perform the proper mapping.
>>>
>>> How should callers decide whether to use ioremap() or memremap()?
>>>
>>> memremap() existed before SME and SEV, and this code is used even if
>>> SME and SEV aren't supported, so the rationale for this change should
>>> not need the decryption argument.
>>
>> When SME or SEV is active an ioremap() will remove the encryption bit
>> from the pagetable entry when it is mapped. This allows MMIO, which
>> doesn't support SME/SEV, to be performed successfully. So my take is
>> that ioremap() should be used for MMIO and memremap() for pages in RAM.
>
> OK, thanks. The commit message should say something like "this is
> RAM, not MMIO, so we should map it with memremap(), not ioremap()".
> That's the part that determines whether the change is correct.
>
> You can mention the encryption part, too, but it's definitely
> secondary because the change has to make sense on its own, without
> SME/SEV.
>
Ok, that makes sense, will do.
> The following commits (from https://github.com/codomania/tip/branches)
> all do basically the same thing so the changelogs (and summaries)
> should all be basically the same:
>
> cb0d0d1eb0a6 x86: Change early_ioremap to early_memremap for BOOT data
> 91acb68b8333 x86/pci: Use memremap when walking setup data
> 4f687503e23f x86: Access the setup data through sysfs decrypted
> e90246b8c229 x86: Access the setup data through debugfs decrypted
>
> I would collect them all together and move them to the beginning of
> your series, since they don't depend on anything else.
I'll do that.
>
> Also, change "x86/pci: " to "x86/PCI" so it matches the previous
> convention.
Will do.
Thanks,
Tom
>
>>>> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
>
> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
>
>>>> ---
>>>> arch/x86/pci/common.c | 4 ++--
>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
>>>> index a4fdfa7..0b06670 100644
>>>> --- a/arch/x86/pci/common.c
>>>> +++ b/arch/x86/pci/common.c
>>>> @@ -691,7 +691,7 @@ int pcibios_add_device(struct pci_dev *dev)
>>>>
>>>> pa_data = boot_params.hdr.setup_data;
>>>> while (pa_data) {
>>>> - data = ioremap(pa_data, sizeof(*rom));
>>>> + data = memremap(pa_data, sizeof(*rom), MEMREMAP_WB);
>>>
>>> I can't quite connect the dots here. ioremap() on x86 would do
>>> ioremap_nocache(). memremap(MEMREMAP_WB) would do arch_memremap_wb(),
>>> which is ioremap_cache(). Is making a cacheable mapping the important
>>> difference?
>>
>> The memremap(MEMREMAP_WB) will actually check to see if it can perform
>> a __va(pa_data) in try_ram_remap() and then fallback to the
>> arch_memremap_wb(). So it's actually the __va() vs the ioremap_cache()
>> that is the difference.
>>
>> Thanks,
>> Tom
>>
>>>
>>>> if (!data)
>>>> return -ENOMEM;
>>>>
>>>> @@ -710,7 +710,7 @@ int pcibios_add_device(struct pci_dev *dev)
>>>> }
>>>> }
>>>> pa_data = data->next;
>>>> - iounmap(data);
>>>> + memunmap(data);
>>>> }
>>>> set_dma_domain_ops(dev);
>>>> set_dev_domain_options(dev);
>>>>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH] crypto: ccp - Assign DMA commands to the channel's CCP
From: Gary R Hook @ 2017-03-13 19:35 UTC (permalink / raw)
To: linux-crypto@vger.kernel.org; +Cc: Stephan Müller
In-Reply-To: <20170310180341.21062.82465.stgit@taos>
On 03/03/2017 7:15 AM, Stephan Mueller wrote:
> Am Donnerstag, 2. März 2017, 22:26:54 CET schrieb Gary R Hook:
>
> Hi Gary,
Thanks for your comments, Stephan.
>
> > A version 5 device provides the primitive commands
> > required for AES GCM. This patch adds support for
> > en/decryption.
> >
> > Signed-off-by: Gary R Hook <gary.hook@amd.com>
> > ---
> > drivers/crypto/ccp/Makefile | 1
> > drivers/crypto/ccp/ccp-crypto-aes-galois.c | 257
> > ++++++++++++++++++++++++++++ drivers/crypto/ccp/ccp-crypto-main.c |
> > 12 +
> > drivers/crypto/ccp/ccp-crypto.h | 14 ++
> > drivers/crypto/ccp/ccp-dev-v5.c | 2
> > drivers/crypto/ccp/ccp-dev.h | 1
> > drivers/crypto/ccp/ccp-ops.c | 252
> > +++++++++++++++++++++++++++ include/linux/ccp.h |
> > 9 +
> > 8 files changed, 548 insertions(+)
> > create mode 100644 drivers/crypto/ccp/ccp-crypto-aes-galois.c
> >
> > diff --git a/drivers/crypto/ccp/ccp-crypto-aes-galois.c
> > b/drivers/crypto/ccp/ccp-crypto-aes-galois.c new file mode 100644
> > index 0000000..8bc18c9
> > --- /dev/null
> > +++ b/drivers/crypto/ccp/ccp-crypto-aes-galois.c
> > @@ -0,0 +1,257 @@
> > +/*
> > + * AMD Cryptographic Coprocessor (CCP) AES GCM crypto API support
> > + *
> > + * Copyright (C) 2016 Advanced Micro Devices, Inc.
> > + *
> > + * Author: Gary R Hook <gary.hook@amd.com>
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + */
> > +
> > +#include <linux/module.h>
> > +#include <linux/sched.h>
> > +#include <linux/delay.h>
> > +#include <linux/scatterlist.h>
> > +#include <linux/crypto.h>
> > +#include <crypto/internal/aead.h>
> > +#include <crypto/algapi.h>
> > +#include <crypto/aes.h>
> > +#include <crypto/ctr.h>
> > +#include <crypto/scatterwalk.h>
> > +#include <linux/delay.h>
> > +
> > +#include "ccp-crypto.h"
> > +
> > +#define AES_GCM_IVSIZE 12
> > +
> > +static int ccp_aes_gcm_complete(struct crypto_async_request *async_req, int
> > ret) +{
> > + return ret;
> > +}
> > +
> > +static int ccp_aes_gcm_setkey(struct crypto_aead *tfm, const u8 *key,
> > + unsigned int key_len)
> > +{
> > + struct ccp_ctx *ctx = crypto_aead_ctx(tfm);
> > +
> > + switch (key_len) {
> > + case AES_KEYSIZE_128:
> > + ctx->u.aes.type = CCP_AES_TYPE_128;
> > + break;
> > + case AES_KEYSIZE_192:
> > + ctx->u.aes.type = CCP_AES_TYPE_192;
> > + break;
> > + case AES_KEYSIZE_256:
> > + ctx->u.aes.type = CCP_AES_TYPE_256;
> > + break;
> > + default:
> > + crypto_aead_set_flags(tfm, CRYPTO_TFM_RES_BAD_KEY_LEN);
> > + return -EINVAL;
> > + }
> > +
> > + ctx->u.aes.mode = CCP_AES_MODE_GCM;
> > + ctx->u.aes.key_len = key_len;
> > +
> > + memcpy(ctx->u.aes.key, key, key_len);
> > + sg_init_one(&ctx->u.aes.key_sg, ctx->u.aes.key, key_len);
> > +
> > + return 0;
> > +}
> > +
> > +static int ccp_aes_gcm_setauthsize(struct crypto_aead *tfm,
> > + unsigned int authsize)
> > +{
> > + return 0;
> > +}
> > +
> > +static int ccp_aes_gcm_crypt(struct aead_request *req, bool encrypt)
> > +{
> > + struct crypto_aead *tfm = crypto_aead_reqtfm(req);
> > + struct ccp_ctx *ctx = crypto_aead_ctx(tfm);
> > + struct ccp_aes_req_ctx *rctx = aead_request_ctx(req);
> > + struct scatterlist *iv_sg = NULL;
> > + unsigned int iv_len = 0;
> > + int i;
> > + int ret = 0;
> > +
> > + if (!ctx->u.aes.key_len)
> > + return -EINVAL;
> > +
> > + if (ctx->u.aes.mode != CCP_AES_MODE_GCM)
> > + return -EINVAL;
> > +
> > + if (!req->iv)
> > + return -EINVAL;
> > +
> > + /*
> > + * 5 parts:
> > + * plaintext/ciphertext input
> > + * AAD
> > + * key
> > + * IV
> > + * Destination+tag buffer
> > + */
> > +
> > + /* According to the way AES GCM has been implemented here,
> > + * per RFC 4106 it seems, the provided IV is fixed at 12 bytes,
>
> When you have that restriction, should the cipher be called rfc4106(gcm(aes))?
>
> But then, the key is 4 bytes longer than a normal AES key as it contains the
> leading 32 bits of the IV.
I had my wires crossed due to an incomplete understanding of an AEAD cipher
in general, and GCM in particular. I'm hopeful that someone can help me
understand:
For the AES GCM encryption tests in testmgr.h, where there is an IV,
they're all
12 bytes in length. As I understand AES GCM the IV can be anywhere from
1 to 2^64
bits in length; the value of 96 makes for convenience and efficiency.
But it's
neither a requirement nor restriction.
There are no tests (in testmgr.h) that use an IV length other than 0 or 96.
My comment about RFC4106 has to do with requiring an IV 0f 96 bits + a
word that
is incremented for each block (making every nonce unique, per the
requirement).
But let's ignore that, please.
It looks as if:
What seems to be missing is the ability to register a (GCM) transform
that can
handle an IV of arbitrary (allowable) length. I have to specify the
length (ivsize)
when I register an algorithm, and everything I see in the existing code
appears
to expect a GCM ivsize to be 96 bits, period (or zero). This is what I
meant when
I referenced RFC4106: I perceive restrictions not in my code, but n the
way GCM seems
to be supported in the crypto AEAD framework. A complete GCM
implementation would not
seem to have a restriction to a specific IV length (rather, a range of
allowed
values).
Is my reading of the GCM description in error? Do we need/want the ability
to have a flexible IV length for GCM? What am I not understanding?
For reference, I'm working from the NIST doc:
http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/gcm/gcm-spec.pdf
>
> > + * occupies the beginning of the IV array. Write a 32-bit
> > + * integer after that (bytes 13-16) with a value of "1".
> > + */
> > + memcpy(rctx->iv, req->iv, AES_GCM_IVSIZE);
> > + for (i = 0; i < 3; i++)
> > + rctx->iv[i + AES_GCM_IVSIZE] = 0;
> > + rctx->iv[AES_BLOCK_SIZE - 1] = 1;
> > +
> > + /* Set up a scatterlist for the IV */
> > + iv_sg = &rctx->iv_sg;
> > + iv_len = AES_BLOCK_SIZE;
> > + sg_init_one(iv_sg, rctx->iv, iv_len);
> > +
> > + /* The AAD + plaintext are concatenated in the src buffer */
> > + memset(&rctx->cmd, 0, sizeof(rctx->cmd));
> > + INIT_LIST_HEAD(&rctx->cmd.entry);
> > + rctx->cmd.engine = CCP_ENGINE_AES;
> > + rctx->cmd.u.aes.type = ctx->u.aes.type;
> > + rctx->cmd.u.aes.mode = ctx->u.aes.mode;
> > + rctx->cmd.u.aes.action =
> > + (encrypt) ? CCP_AES_ACTION_ENCRYPT : CCP_AES_ACTION_DECRYPT;
>
> Instead of this condition, why not changing the encrypt/decrypt function to
> directly provide the enc/dec variables?
Our existing code that uses this construct doesn't do that, but I
have no problem with the idea. Done.
> > + rctx->cmd.u.aes.key = &ctx->u.aes.key_sg;
> > + rctx->cmd.u.aes.key_len = ctx->u.aes.key_len;
> > + rctx->cmd.u.aes.iv = iv_sg;
> > + rctx->cmd.u.aes.iv_len = iv_len;
> > + rctx->cmd.u.aes.src = req->src;
> > + rctx->cmd.u.aes.src_len = req->cryptlen;
> > + rctx->cmd.u.aes.aad_len = req->assoclen;
>
> Just to be on the safe side: is the implementation good when cryptlen or
> assoclen is 0?
The engine has been designed to handle those two conditions. I've been
watching the discussions around these issues.
The first encryption test in testmgr.h has no input data nor IV. This
implementation passes that test.
The second encryption test in testmgr.h has input data but no IV, and this
implementation passes.
Is that an acceptable validation, or do we need more?
Thanks,
Gary
--
This is my day job. Follow me at:
IG/Twitter/Facebook: @grhookphoto
IG/Twitter/Facebook: @grhphotographer
^ permalink raw reply
* Re: dm-crypt IV generation (summary)
From: Mike Snitzer @ 2017-03-13 18:23 UTC (permalink / raw)
To: Ondrej Mosnacek
Cc: Milan Broz, linux-crypto, dm-devel, Alasdair Kergon,
Mikulas Patocka, Herbert Xu, Binoy Jayan, Gilad Ben-Yossef
In-Reply-To: <CAFqZXNs0=6+PvpGq3weRwCJkUOfSn06i_fD6ZuvXo_0rms9zeA@mail.gmail.com>
On Fri, Mar 10 2017 at 8:44am -0500,
Ondrej Mosnacek <omosnace@redhat.com> wrote:
> Hi all,
>
> I was tasked to post a summary the whole dm-crypt IV generation
> problem and all the suggested solutions along with their drawbacks, so
> here it goes...
Thanks for the summary.
...
> 2. Restrict the keycount parameter to allow only reasonable
> combinations and then move IV generators to crypto API.
> In Loop-AES, the multi-key mode always uses exactly 64 keys and
> there is no reasonable scenario where someone would like to use
> keycount != 1 with other IV mode than LMK. Thus it might be acceptable
> to only work with multiple keys in LMK (and only allow keycount == 64
> for it) and work with just one key in all other modes (and only allow
> keycount == 1 for them). I.e., the cipher format would remain the
> same, just with more restricted values.
>
> Note that this would be basically a breaking change (the keycount
> parameter is documented [4], so there may be users somewhere that use
> it in some unusual combination...). Still, such combinations would
> have to be used explicitly, as they are never used with common
> LUKS/Loop-AES/TrueCrypt partitions (something like cryptsetup --type
> plain ... or dmsetup would have to be used directly).
>
> Applying this change would allow implementing the IV generators as
> simple crypto algorithms that honor the usual interface (without
> setkey hacks and passing of special structures via IV).
>
> ISSUES:
> a) Backward incompatibility (see above).
> b) Again need to somehow handle the new 'random' IV generator.
...
>
> QUESTIONS:
> @Mike/dm-devel: Do you think it would be feasible to apply solution 2
> (thus introducing the small incompatibility)?
Of all the proposals I think 2 is the best. But I'm not in a position
to _know_ how problematic such an incompatible change would be. As such
I unfortunately would need to defer to Milan, Herbert and others to say
how risky such a change would be. If the real-world risk is very
limited then I think it would enable the most effective solution (moving
the IV generators to crypto without carrying excess dm-crypt baggage).
The other part mentioned ("need to somehow handle the new 'random' IV
generator"): Milan or others, do you have ideas for this? Presummably
that is a prereq to moving forward with restricting keycount.
Mike
^ permalink raw reply
* Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
From: Krzysztof Kozlowski @ 2017-03-13 17:06 UTC (permalink / raw)
To: Nathan Royce, Herbert Xu
Cc: davem, linux-crypto, linux-kernel, Marek Szyprowski
In-Reply-To: <20170312191322.bbux5nrkqf5klznq@kozik-lap>
On Sun, Mar 12, 2017 at 09:13:22PM +0200, Krzysztof Kozlowski wrote:
> On Fri, Mar 10, 2017 at 03:44:45PM -0600, Nathan Royce wrote:
> > Sure, I went ahead and rebuilt it just using the bare exynos_defconfig
> > and adding XTS and ECB and no other changes.
> >
> > No flags were used. No patches were used other than the 2 you
> > provided. Just the barest of bears, the barest of bones, the barest of
> > deserts, the barest of hairless cats.
> >
>
> Okay, I reproduced it. Beside enabling crypto tests, ECB and XTS, the
> important step is to disable the "ARM Accelerated Cryptographic
> Algorithms" so S5P-SSS will be used with XTS. The xts(ecb-aes-s5p))
> itself passes TCRYPT tests but oopses on cryptswap.
Hi Herbert,
I bisected this to commit f1c131b45410 ("crypto: xts - Convert to
skcipher"). The s5p-sss driver stays the same... but the xts changes and
as a result we have a NULL pointer dereference (actually of value
00000004):
[ 18.930195] Unable to handle kernel NULL pointer dereference at virtual address 00000004
...
[ 18.972325] [<c0313c98>] (post_crypt) from [<c031408c>] (decrypt_done+0x4c/0x54)
[ 18.972343] [<c031408c>] (decrypt_done) from [<c056309c>] (s5p_aes_interrupt+0x1bc/0x208)
[ 18.972360] [<c056309c>] (s5p_aes_interrupt) from [<c0164930>] (irq_thread_fn+0x1c/0x54)
Any hints?
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] Constantly reseed nonblocking_pool during initialization
From: Stephan Müller @ 2017-03-13 10:28 UTC (permalink / raw)
To: Ted Tso; +Cc: Pascal de Bruijn, linux-kernel, linux-crypto
Hi Ted,
The issue fixed by the patch below is visible in all kernels between 3.13 and 4.7. The patch is developed against 4.7.0. It is tested against 4.4.53.
If you concur, I would recommend to send it to stable.
---8<---
The nonblocking_pool is reseeded after the expiry of
random_min_urandom_seed seconds since last reseed. This approach is not
suitable during early boot time of user space due to the following: When
user space starts an entropy gathering daemon (like the rngd or other
daemons) very early during the boot cycle before cryptographic services
are started to provide entropy to the input_pool, the entropy will not
reach the nonblocking_pool immediately even though this is the intention.
This can be illustrated with the following log where a user space
entropy gathering daemon is started around 6.1 seconds after start and
it is guaranteed that it will inject 256 bits of entropy via the
RNDADDENTROPY IOCTL at that time. Thus, the complaint about an
insufficiently seeded nonblocking_pool should be gone after that
event. Further, at the time of the IOCTL, the "nonblocking pool is
initialized" statement should appear. Yet, the log shows that even
after 34 seconds after boot there is still insufficient entropy
in the nonblocking pool.
[ 6.072296] random: udevd: uninitialized urandom read (16 bytes read, 4 bits of entropy available)
[ 6.072346] random: udevd: uninitialized urandom read (16 bytes read, 4 bits of entropy available)
[ 6.072358] random: udevd: uninitialized urandom read (16 bytes read, 4 bits of entropy available)
[ 6.072369] random: udevd: uninitialized urandom read (16 bytes read, 4 bits of entropy available)
[ 6.083754] random: udevd: uninitialized urandom read (16 bytes read, 4 bits of entropy available)
[ 6.083766] random: udevd: uninitialized urandom read (16 bytes read, 4 bits of entropy available)
[ 6.085852] random: udevd: uninitialized urandom read (16 bytes read, 4 bits of entropy available)
[ 34.602241] random: ssh-keygen: uninitialized urandom read (32 bytes read, 103 bits of entropy available)
[ 34.606645] random: sshd: uninitialized urandom read (32 bytes read, 103 bits of entropy available)
[ 34.711321] random: nrpe: uninitialized urandom read (32 bytes read, 103 bits of entropy available)
[ 53.337494] random: nonblocking pool is initialized
Reported-by: Pascal de Bruijn <p.debruijn@unilogic.nl>
Signed-off-by: Stephan Mueller <smueller@chronox.de>
Tested-by: Pascal de Bruijn <p.debruijn@unilogic.nl>
---
drivers/char/random.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 0158d3b..58d9b7f 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -984,7 +984,8 @@ static void xfer_secondary_pool(struct entropy_store *r, size_t nbytes)
if (r->limit == 0 && random_min_urandom_seed) {
unsigned long now = jiffies;
- if (time_before(now,
+ if (r->initialized &&
+ time_before(now,
r->last_pulled + random_min_urandom_seed * HZ))
return;
r->last_pulled = now;
--
2.9.3
^ permalink raw reply related
* Announce loop-AES-v3.7k file/swap crypto package
From: Jari Ruusu @ 2017-03-13 8:29 UTC (permalink / raw)
To: linux-crypto; +Cc: linux-kernel
loop-AES changes since previous release:
- Worked around kernel interface changes on 4.10 and 4.11-rc kernels.
bzip2 compressed tarball is here:
http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7k.tar.bz2
md5sum 942bff99a0361f209ce8de66404b64b3
http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7k.tar.bz2.sign
--
Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189
^ permalink raw reply
* Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
From: Krzysztof Kozlowski @ 2017-03-12 19:13 UTC (permalink / raw)
To: Nathan Royce
Cc: Herbert Xu, davem, linux-crypto, linux-kernel, Marek Szyprowski
In-Reply-To: <CALaQ_hqomXaZs0z-S3YX6d-hS_giqgBqBSvumwsMm=BzrgZz7Q@mail.gmail.com>
On Fri, Mar 10, 2017 at 03:44:45PM -0600, Nathan Royce wrote:
> Sure, I went ahead and rebuilt it just using the bare exynos_defconfig
> and adding XTS and ECB and no other changes.
>
> No flags were used. No patches were used other than the 2 you
> provided. Just the barest of bears, the barest of bones, the barest of
> deserts, the barest of hairless cats.
>
Okay, I reproduced it. Beside enabling crypto tests, ECB and XTS, the
important step is to disable the "ARM Accelerated Cryptographic
Algorithms" so S5P-SSS will be used with XTS. The xts(ecb-aes-s5p))
itself passes TCRYPT tests but oopses on cryptswap.
Best regards,
Krzysztof
^ permalink raw reply
* 50546 linux-crypto
From: delaware.orders @ 2017-03-12 17:03 UTC (permalink / raw)
To: linux-crypto
[-- Attachment #1: 19647745632966.zip --]
[-- Type: application/zip, Size: 6053 bytes --]
^ permalink raw reply
* Re: [PATCH v2] MAINTAINERS: Add maintianer entry for crypto/s5p-sss
From: Vladimir Zapolskiy @ 2017-03-12 6:51 UTC (permalink / raw)
To: Krzysztof Kozlowski, Herbert Xu, David S. Miller, linux-crypto,
linux-kernel
In-Reply-To: <20170311061100.4659-1-krzk@kernel.org>
On 03/11/2017 08:11 AM, Krzysztof Kozlowski wrote:
> Add Krzysztof Kozlowski and Vladimir Zapolskiy as maintainers of s5p-sss
> driver for handling reviews, testing and getting bug reports from the
> users.
>
> Cc: Vladimir Zapolskiy <vz@mleia.com>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
>
Acked-by: Vladimir Zapolskiy <vz@mleia.com>
--
With best wishes,
Vladimir
^ permalink raw reply
* 11859 linux-crypto
From: e.camilla.johansson @ 2017-03-12 0:54 UTC (permalink / raw)
To: linux-crypto
[-- Attachment #1: 245663.zip --]
[-- Type: application/zip, Size: 3944 bytes --]
^ 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