Received-SPF: pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20191220190218.28884-1-cotequeiroz@gmail.com> <CAKv+Gu9ZXCK41xOavw+2KEhhsZq9BFH6mxXKPNomzB6q+DP_FQ@mail.gmail.com>
 <CAPxccB2LGANG8DcmF4nwUDOzDzf2RHX4S-4w9z6TcO9csu4xSw@mail.gmail.com>
In-Reply-To: <CAPxccB2LGANG8DcmF4nwUDOzDzf2RHX4S-4w9z6TcO9csu4xSw@mail.gmail.com>
From:   Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date:   Fri, 3 Jan 2020 15:33:35 +0100
Message-ID: <CAKv+Gu9fUs_xOZgUw5smrJf7+jrovkPL+1fF4fRcNhRieYSwhA@mail.gmail.com>
Subject: Re: QCE hw-crypto DMA issues
To:     Eneas Queiroz <cotequeiroz@gmail.com>
Cc:     "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" 
        <linux-crypto@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk

On Thu, 2 Jan 2020 at 22:09, Eneas Queiroz <cotequeiroz@gmail.com> wrote:
>
> I'm changing the subject title, as the original series has been merged.
>
> On Mon, Dec 23, 2019 at 6:46 AM Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>>
>> On Fri, 20 Dec 2019 at 20:02, Eneas U de Queiroz <cotequeiroz@gmail.com> wrote:
>> >
>> > I've been trying to make the Qualcomm Crypto Engine work with GCM-mode
>> > AES.  I fixed some bugs, and added an option to build only hashes or
>> > skciphers, as the VPN performance increases if you leave some of that to
>> > the CPU.
>> >
>> > A discussion about this can be found here:
>> > https://github.com/openwrt/openwrt/pull/2518
>> >
>> > I'm using openwrt to test this, and there's no support for kernel 5.x
>> > yet.  So I have backported the recent skcipher updates, and tested this
>> > with 4.19. I don't have the hardware with me, but I have run-tested
>> > everything, working remotely.
>> >
>> > All of the skciphers directly implemented by the driver work.  They pass
>> > the tcrypt tests, and also some tests from userspace using AF_ALG:
>> > https://github.com/cotequeiroz/afalg_tests
>> >
>> > However, I can't get gcm(aes) to work.  When setting the gcm-mode key,
>> > it sets the ctr(aes) key, then encrypt a block of zeroes, and uses that
>> > as the ghash key.  The driver fails to perform that encryption.  I've
>> > dumped the input and output data, and they apparently are not touched by
>> > the QCE.  The IV, which written to a buffer appended to the results sg
>> > list gets updated, but the results themselves are not.  I'm not sure
>> > what goes wrong, if it is a DMA/cache problem, memory alignment, or
>> > whatever.
>> >
>>
>> This does sound like a DMA problem. I assume the accelerator is not
>> cache coherent?
>>
>> In any case, it is dubious whether the round trip to the accelerator
>> is worth it when encrypting the GHASH key. Just call aes_encrypt()
>> instead, and do it in software.
>
>
> ipsec still fails, even if I use software for every single-block operation. I can perhaps leave that as an optimization, but it won't fix the main issue.
>
>> > If I take 'be128 hash' out of the 'data' struct, and kzalloc them
>> > separately in crypto_gcm_setkey (crypto/gcm.c), it encrypts the data
>> > just fine--perhaps the payload and the request struct can't be in the
>> > same page?
>> >
>>
>> Non-cache coherent DMA involves cache invalidation on inbound data. So
>> if both the device and the CPU write to the same cacheline while the
>> buffer is mapped for DMA from device to memory, one of the updates
>> gets lost.
>
>
>  Can you give me any pointers/examples of how I can make this work?
>

You could have a look at commit ed527b13d800dd515a9e6c582f0a73eca65b2e1b