On Tue, Oct 31, 2017 at 09:41:24AM +, Ilya Lesokhin wrote:
>
> Are you sure supporting ASYNC crypto for fallback is worth the trouble?
It is not just for fallback, I plan to support the IPsec GSO codepath
for software crypto too. In this case we should be able to handle all
algorithms, includ
On Tuesday, October 31, 2017 11:14 AM Steffen Klassert wrote:
> I think Ilya talks about the case where the TLS crypto is intended to be
> offloaded
> to a NIC. In this case we need a software crypto fallback e.g. if a packet got
> rerouted to a device that does not support crypto offloading.
Yo
On Tue, Oct 31, 2017 at 03:44:38PM +0800, Herbert Xu wrote:
> On Tue, Oct 31, 2017 at 07:39:08AM +, Ilya Lesokhin wrote:
> >
> > I think we should consider having a synchronous implementation that falls
> > back
> > to integer implementation when the FPU is not available.
> > This would spare
On Tuesday, October 31, 2017 9:45 AM, Herbert Xu wrote:
>
> For your intended use case I think async processing should work just fine as
> it
> does for IPsec.
>
I haven't dived into the async IPSEC fallback code yet, but it seems
complicated.
I'm not sure it make the correct performance/compl
On Tue, Oct 31, 2017 at 07:39:08AM +, Ilya Lesokhin wrote:
>
> I think we should consider having a synchronous implementation that falls back
> to integer implementation when the FPU is not available.
> This would spare the users from having to handle the asynchronous case.
>
> Hopefully the
On Tuesday, October 31, 2017 9:33 AM, Herbert Xu wrote:
> You are right. generic-gcm-aesni is completely broken.
>
> It needs to be rewritten to use a wrapper as is done with rfc4106.
I think we should consider having a synchronous implementation that falls back
to integer implementation when th
On Tue, Oct 31, 2017 at 07:23:35AM +, Ilya Lesokhin wrote:
> On Tuesday, October 31, 2017 9:17 AM, Herbert Xu wrote:
> >
> > Users of the crypto API shouldn't need to check irq_fpu_usable().
> > The crypto API should work regardless of what context you're in.
>
> I agree, I'm just saying that
On Tuesday, October 31, 2017 9:17 AM, Herbert Xu wrote:
>
> Users of the crypto API shouldn't need to check irq_fpu_usable().
> The crypto API should work regardless of what context you're in.
>
I agree, I'm just saying that as far as I can tell that's not true
for the aesni generic gcm(aes) aea
On Tue, Oct 31, 2017 at 07:14:12AM +, Ilya Lesokhin wrote:
>
> However I'm still concerned about the lack of irq_fpu_usable() check.
> and I don't really want to do the check myself outside of the crypto code as
> it is
> arch specific.
Users of the crypto API shouldn't need to check irq_fpu_
On Mon Tuesday, October 31, 2017 6:10 AM, Herbert Xu wrote:
>
> Are you allocating the tfm from atomic context? That is not allowed.
>
> Normally you would allocate the tfm in process context, e.g., when the
> connection is setup.
>
I call crypto_alloc_aead("gcm(aes)", 0, flags) in process cont
On Mon, Oct 30, 2017 at 03:18:21PM +, Ilya Lesokhin wrote:
> Hi,
> I've tried using the aesni generic gcm(aes) aead to implement TLS SW fallback
> and
> I'm getting
> [ 3356.839506] BUG: sleeping function called from invalid context at
> ./include/crypto/algapi.h:417
>
> The warning is comi
11 matches
Mail list logo
