netdev - Re: Advertise maximum number of sg supported by driver in single request

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAOtvUMdfxx=-XQMv=aFFjzSnLCL3b5UuvVOMzJVc2odSCZGtXg@mail.gmail.com>
Date:   Tue, 21 Jan 2020 14:03:16 +0200
From:   Gilad Ben-Yossef <gilad@...yossef.com>
To:     Ayush Sawal <ayush.sawal@...cdesigners.com>
Cc:     Steffen Klassert <steffen.klassert@...unet.com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        manojmalviya@...lsio.com, Ayush Sawal <ayush.sawal@...lsio.com>,
        netdev@...r.kernel.org
Subject: Re: Advertise maximum number of sg supported by driver in single request

On Mon, Jan 20, 2020 at 2:35 PM Ayush Sawal
<ayush.sawal@...cdesigners.com> wrote:

> As we have a crypto accelarator as device when the request is send to
> the crypto driver from esp_output ,
> the aead_request has all the fragments in its src sg and the problem
> which we are facing is when this
> src sg nents becomes greater than 15 ,15 is our crypto driver's max sg
> limit to handle the request in one shot.
>
> Does it make sense for a crypto driver to advertise the maximum amount
> of sg it can handle for a single
> request and then handling this in crypto framework while forming the
> crypto request?
>

As I maintain the driver of another crypto accelerator I sympathize
with the need but I question the proposed solution.
Consider: your specific driver is limited by the number of
scattergather entries. Another implementation might be limited
by something else such as the total overall size of the request buffer
and probably half a dozen other considerations.
Should we now be passing all this capability information to the crypto
API core? and what happens if a new driver
has a limitation in a different quality?

So no, the solution to advertise the specific capability limitation of
each implementation does not seem to be a good one.
We already have a solution to the problem - initiate a fallback TFM
request and use it if you cannot fulfill the request on your own.

I do agree however that having each implementation registering and
keeping their own fallback tfm request just for these cases has some
overhead and a redundancy.

Maybe a better solution would be to allow implementation to return to
the Crypto API core a special return value (maybe -EAGAIN?) that tells
it that although the request is a valid one, this specific
implementation cannot fulfil it and let the crypto API core do the
fallback?

It sounds like it can be simpler to the implementation providers AND
save some redundant code...

-- 
Gilad Ben-Yossef
Chief Coffee Drinker

values of β will give rise to dom!