Date:   Wed, 20 Feb 2019 12:42:08 +0100
From:   Steffen Klassert <steffen.klassert@secunet.com>
To:     Herbert Xu <herbert@gondor.apana.org.au>
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
Message-ID: <20190220114208.GD3087@gauss3.secunet.de>
References: <20171230083744.vuclnbs677tj7pi2@gauss3.secunet.de>
 <20180310232231.19191-1-ebiggers3@gmail.com>
 <20180323002152.GA30497@gondor.apana.org.au>
 <20180408225528.GH685@sol.localdomain>
 <20180409085807.2cwvr5cocz6gfbmv@gauss3.secunet.de>
 <20180409190739.GC203367@gmail.com>
 <20180418053533.wuo6bj2okqdu2hrf@gauss3.secunet.de>
 <20190220040628.673rc2ffs7dxepu2@gondor.apana.org.au>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20190220040628.673rc2ffs7dxepu2@gondor.apana.org.au>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-G-Data-MailSecurity-for-Exchange-Sender: 23
X-G-Data-MailSecurity-for-Exchange-Server: d65e63f7-5c15-413f-8f63-c0d707471c93
X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10
X-G-Data-MailSecurity-for-Exchange-Guid: FD6684C0-7348-4FE6-BD15-5F195D739C50
X-G-Data-MailSecurity-for-Exchange-ProcessedOnRouted: True
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-crypto.vger.kernel.org>
X-Mailing-List: linux-crypto@vger.kernel.org

On Wed, Feb 20, 2019 at 12:06:28PM +0800, Herbert Xu wrote:
> On Wed, Apr 18, 2018 at 07:35:33AM +0200, Steffen Klassert wrote:
> > 
> > Yes sure, I just wanted to know if it is worth to think about
> > preventing template recursions. If there is a valid usecase,
> > then we don't even need to think in this direction.
> > 
> > While I think each pcrypt instance should have it's own
> > padata instance on the long run, it would be good to have
> > a not so intrusive fix that can be backported to the stable
> > trees.
> 
> Steffen, has there been any progress on this work?

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.

> 
> 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?

If I see this correct, only crypto algorithms used by
HW crypto accelerators need a fallback to software
crypto. HW crypto can't benefit from pcrypt anyway,
so it would be no loss to disable pcrypt in that case.

We could use the initial fix from Eric in combination
with disableing pcrypt for algorithms that need a fallback.