From: Herbert Xu <herbert@gondor.apana.org.au>
To: Steffen Klassert <steffen.klassert@secunet.com>
Cc: Eric Biggers <ebiggers3@gmail.com>,
linux-crypto@vger.kernel.org, syzkaller-bugs@googlegroups.com,
Eric Biggers <ebiggers@google.com>
Subject: Re: [RFC PATCH] crypto: pcrypt - forbid recursive instantiation
Date: Fri, 1 Mar 2019 11:38:02 +0800 [thread overview]
Message-ID: <20190301033802.cm7wjouxq4hwyrji@gondor.apana.org.au> (raw)
In-Reply-To: <20190220114208.GD3087@gauss3.secunet.de>
On Wed, Feb 20, 2019 at 12:42:08PM +0100, Steffen Klassert wrote:
>
> I had a look on what we need to use separate padata
> instances for each pcrypt instance. But that's comlicated
> and will create incompatibilities on the sysfs cpuset
> configuration options. So that's not really a thing that
> could be a fix.
I don't see why it'll create incompatibilities for the cpu mask
configuration. You can just maintain two global configuration
masks as you do now, and read them from each instance. What's
the problem with that?
> > We need to fix this soon or we'll have to disable pcrypt because
> > it is a security issue.
> >
> > It's not just about nested templates either. You can trigger
> > the same issue where a pcrypt instance over an AEAD algorithm
> > that uses a fallback which also happens to be pcrypt.
>
> Would it be possible to forbid pcrypt for algorithms
> that needs a fallback?
This is complicated and not fool-proof. pcrypt itself might
be embedded into some other algorithm directly rather than as
a fallback.
Basically anyone who does a crypto_alloc_aead could end up with
a pcrypt instance unwittingly. If they were then used as part
of another AEAD algorithm's encrypt/decrypt path then we'd have
a dead-lock as we do now.
Granted we may not have this situation right now but relying on
it to never occur is not a good choice IMHO.
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
next prev parent reply other threads:[~2019-03-01 3:38 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <001a1140b8307b0439055ffc7872@google.com>
2017-12-12 16:46 ` INFO: task hung in aead_recvmsg Dmitry Vyukov
2017-12-23 20:29 ` Eric Biggers
2017-12-30 8:37 ` Steffen Klassert
2018-01-05 21:35 ` Eric Biggers
[not found] ` <20180310232231.19191-1-ebiggers3@gmail.com>
[not found] ` <20180323002152.GA30497@gondor.apana.org.au>
[not found] ` <20180408225528.GH685@sol.localdomain>
[not found] ` <20180409085807.2cwvr5cocz6gfbmv@gauss3.secunet.de>
[not found] ` <20180409190739.GC203367@gmail.com>
[not found] ` <20180418053533.wuo6bj2okqdu2hrf@gauss3.secunet.de>
2019-02-20 4:06 ` [RFC PATCH] crypto: pcrypt - forbid recursive instantiation Herbert Xu
2019-02-20 11:42 ` Steffen Klassert
2019-03-01 3:38 ` Herbert Xu [this message]
2018-07-21 12:37 ` INFO: task hung in aead_recvmsg syzbot
2019-12-01 7:58 ` syzbot
2019-12-01 17:58 ` Stephan Müller
2019-12-01 19:22 ` Eric Biggers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190301033802.cm7wjouxq4hwyrji@gondor.apana.org.au \
--to=herbert@gondor.apana.org.au \
--cc=ebiggers3@gmail.com \
--cc=ebiggers@google.com \
--cc=linux-crypto@vger.kernel.org \
--cc=steffen.klassert@secunet.com \
--cc=syzkaller-bugs@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).