linux-kernel - Re: [PATCH 9/9] crypto: qce

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: <CAMRc=MetohPUcxRLO0qS-LYyzZhiAMAHzLm0xqX8_TXdTgBnVA@mail.gmail.com>
Date: Thu, 20 Feb 2025 10:14:20 +0100
From: Bartosz Golaszewski <brgl@...ev.pl>
To: Eric Biggers <ebiggers@...nel.org>
Cc: neil.armstrong@...aro.org, linux-crypto@...r.kernel.org, 
	linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Bartosz Golaszewski <bartosz.golaszewski@...aro.org>, Thara Gopinath <thara.gopinath@...il.com>, 
	Herbert Xu <herbert@...dor.apana.org.au>, "David S. Miller" <davem@...emloft.net>, 
	Stanimir Varbanov <svarbanov@...sol.com>
Subject: Re: [PATCH 9/9] crypto: qce - switch to using a mutex

On Mon, Jan 20, 2025 at 2:46 PM Bartosz Golaszewski <brgl@...ev.pl> wrote:
>
> On Sat, Jan 18, 2025 at 6:55 PM Eric Biggers <ebiggers@...nel.org> wrote:
> >
> > On Sat, Jan 18, 2025 at 10:28:26AM +0100, Bartosz Golaszewski wrote:
> > > I was testing with kcapi-speed and cryptsetup benchmark. I've never
> > > seen any errors.
> > >
> > > Is this after my changes only or did it exist before? You're testing
> > > with the tcrypt module? How are you inserting it exactly? What params?
> >
> > Those are all benchmarks, not tests.  The tests run at registration time if you
> > just enable the kconfig options for them:
> >
> >     # CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set
> >     CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=y
> >
> > The test failures and KASAN error occur on mainline too, so yes they occur
> > before your patchset too.
> >
> > > >
> > > > I personally still struggle to understand how this driver could plausibly be
> > > > useful when the software crypto has no issues, is much faster, and is much
> > > > better tested.  What is motivating having this driver in the kernel?
> > >
> > > We want to use it in conjunction with the upcoming scminvoke (for
> > > loading TAs and invoking objects - used to program the keys into the
> > > QCE) to support the DRM use-case for decrypting streaming data inside
> > > secure buffers upstream.
> >
> > Notably lacking is any claim that any of the current features of the driver are
> > actually useful.
> >
>
> Noted. I'm still quite early into working on the upstream-bound code
> supporting the streaming use-case but I will consider a proposal to
> remove existing features that are better provided by ARM CE.
>
> Thanks,
> Bartosz

Just an FYI, I was informed by Qualcomm that upcoming platforms will
contain an upgrade to this IP and it will be up to 3x faster than ARM
CE. In this case we'll keep this driver around and I will focus on
fixing existing issues.

Bart