linux-kernel - Re: [EXTERNAL] Re: [PATCH v2 0/6] Add support for Texas Instruments MCRC64 engine

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: <87h6owen39.fsf@kamlesh.i-did-not-set--mail-host-address--so-tickle-me>
Date:   Fri, 18 Aug 2023 14:36:34 +0530
From:   Kamlesh Gurudasani <kamlesh@...com>
To:     Eric Biggers <ebiggers@...nel.org>
CC:     Herbert Xu <herbert@...dor.apana.org.au>,
        "David S. Miller" <davem@...emloft.net>,
        Rob Herring <robh+dt@...nel.org>,
        "Krzysztof Kozlowski" <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>, Nishanth Menon <nm@...com>,
        Vignesh Raghavendra <vigneshr@...com>,
        Tero Kristo <kristo@...nel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        Alexandre Torgue <alexandre.torgue@...s.st.com>,
        <linux-crypto@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <devicetree@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-stm32@...md-mailman.stormreply.com>
Subject: Re: [EXTERNAL] Re: [PATCH v2 0/6] Add support for Texas Instruments
 MCRC64 engine

Eric Biggers <ebiggers@...nel.org> writes:

> On Fri, Aug 11, 2023 at 12:58:47AM +0530, Kamlesh Gurudasani wrote:
>> Add support for MCRC64 engine to calculate 64-bit CRC in Full-CPU mode
>> 
>> MCRC64 engine calculates 64-bit cyclic redundancy checks (CRC)
>> according to the ISO 3309 standard.
>> 
>> The ISO 3309 64-bit CRC model parameters are as follows:
>>     Generator Polynomial: x^64 + x^4 + x^3 + x + 1
>>     Polynomial Value: 0x000000000000001B
>>     Initial value: 0x0000000000000000
>>     Reflected Input: False
>>     Reflected Output: False
>>     Xor Final: 0x0000000000000000
>> 
>> Tested with
>> CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set
>> CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=y
>> 
>> and tcrypt,
>> sudo modprobe tcrypt mode=329 sec=1
>> 
>> User space application implemented using algif_hash,
>> https://gist.github.com/ti-kamlesh/73abfcc1a33318bb3b199d36b6209e59
>> 
>> Signed-off-by: Kamlesh Gurudasani <kamlesh@...com>
>
> I do not see any in-kernel user of this CRC variant being introduced, which
> leaves algif_hash as the only use case.
>
> Can you elaborate on the benefit this brings to your application?  Yes, it
> allows you to use your hardware CRC engine.  But, that comes with all the
> overhead from the syscalls, algif_hash, and the driver.  How does performance
> compare to a properly optimized software CRC implementation on your platform,
> i.e. an implementation using carryless multiplication instructions (e.g. ARMv8
> CE) if available on your platform, otherwise an implementation using the
> slice-by-8 or slice-by-16 method?
>
> - Eric
Hi Eric,

We are more interested in offload than performance, with splice system
call and DMA mode in driver(will be implemented after this series gets
merged), good amount of cpu cycles will be saved.

There is one more mode(auto mode) in mcrc64 which helps to verify crc64
values against pre calculated crc64, saving the efforts of comparing in
userspace.

Current generic implementation of crc64-iso(part of this series)
gives 173 Mb/s of speed as opposed to mcrc64 which gives speed of 812
Mb/s when tested with tcrypt.

Regard,
Kamlesh