linux-kernel - Re: [PATCH v3 0/6] Add support for MCRC64 engine to calculate 64-bit CRC in Full-CPU mode

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <87cylhm3tn.fsf@kamlesh.i-did-not-set--mail-host-address--so-tickle-me>
Date: Fri, 6 Sep 2024 16:44:44 +0530
From: Kamlesh Gurudasani <kamlesh@...com>
To: Herbert Xu <herbert@...dor.apana.org.au>,
        Eric Biggers
	<ebiggers@...nel.org>
CC: <kristo@...nel.org>, <will@...nel.org>, <akpm@...ux-foundation.org>,
        <davem@...emloft.net>, <mcoquelin.stm32@...il.com>,
        <alexandre.torgue@...s.st.com>, <robh@...nel.org>,
        <krzysztof.kozlowski+dt@...aro.org>, <conor+dt@...nel.org>,
        <vigneshr@...com>, <catalin.marinas@....com>,
        <linux-kernel@...r.kernel.org>, <linux-crypto@...r.kernel.org>,
        <linux-stm32@...md-mailman.stormreply.com>,
        <linux-arm-kernel@...ts.infradead.org>, <devicetree@...r.kernel.org>
Subject: Re: [PATCH v3 0/6] Add support for MCRC64 engine to calculate
 64-bit CRC in Full-CPU mode

Herbert Xu <herbert@...dor.apana.org.au> writes:

> On Mon, Jun 10, 2024 at 08:13:14PM -0700, Eric Biggers wrote:
>>
>> I thought the rule is that there needs to be an in-kernel user to add algorithms
>> to the crypto API?  Is there any precedent for adding new algorithms purely so
>> that accelerators that implement them can be accessed from userspace via AF_ALG?
>
> I agree.  Perhaps this driver could instead be added as a simple
> char device that is then used directly by the intended user without
> going through the Crypto API at all.
>
> That would make it a lot simpler.
Thanks for all the support Herbert, Eric.

Just wanted to confirm, if this is being rejected primarily because
1. there is no in-kernel user for crc64-iso3309
2. or poor performance benefit of using it from userspace

The context for asking is that we have another superset IP known as MCRC
(this one is MCRC64), which supports crc8/16/32/64(iso-3309).

That IP has working DMA and will give good offloading numbers.

We are planning to send drivers for crc8/16/32 for MCRC
1.should I put efforts for crc64-iso3309 as well or
2.drop the crc64-iso3309 and send only for remaining
crc8/16/32(standard algorithms with already in-kernel user).

All our devices either have MCRC or MCRC64.

Thanks,
Kamlesh