linux-kernel - Re: [PATCH v9 03/11] dmaengine: qcom: bam_dma: implement support for BAM locking

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: <CAMRc=McPz+W4GOCbNMx-tpSav3+wuUrLT2CF5FhoV5U29oiK6A@mail.gmail.com>
Date: Fri, 9 Jan 2026 15:15:38 +0100
From: Bartosz Golaszewski <brgl@...nel.org>
To: Vinod Koul <vkoul@...nel.org>
Cc: Jonathan Corbet <corbet@....net>, Thara Gopinath <thara.gopinath@...il.com>, 
	Herbert Xu <herbert@...dor.apana.org.au>, "David S. Miller" <davem@...emloft.net>, 
	Udit Tiwari <quic_utiwari@...cinc.com>, Daniel Perez-Zoghbi <dperezzo@...cinc.com>, 
	Md Sadre Alam <mdalam@....qualcomm.com>, Dmitry Baryshkov <lumag@...nel.org>, dmaengine@...r.kernel.org, 
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-arm-msm@...r.kernel.org, linux-crypto@...r.kernel.org, 
	Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
Subject: Re: [PATCH v9 03/11] dmaengine: qcom: bam_dma: implement support for
 BAM locking

On Fri, Jan 9, 2026 at 3:27 AM Vinod Koul <vkoul@...nel.org> wrote:
>
> >
> > We need an API because we send a locking descriptor, then a regular
> > descriptor (or descriptors) for the actual transaction(s) and then an
> > unlocking descriptor. It's a thing the user of the DMA engine needs to
> > decide on, not the DMA engine itself.
>
> I think downstream sends lock descriptor always. What is the harm in
> doing that every time if we go down that path?

No, in downstream it too depends on the user setting the right bits.
Currently the only user of the BAM locking downstream is the NAND
driver. I don't think the code where the crypto driver uses it is
public yet.

And yes, there is harm - it slightly impacts performance. For QCE it
doesn't really matter as any users wanting to offload skcipher or SHA
are better off using the Arm Crypto Extensions anyway as they are
faster by an order of magnitude (!). It's also the default upstream,
where the priorities are set such that the ARM CEs are preferred over
the QCE. QCE however, is able to coordinate with the TrustZone and
will be used to support the DRM use-cases.

I prefer to avoid impacting any other users of BAM DMA.

> Reg Dmitry question above, this is dma hw capability, how will client
> know if it has to lock on older rev of hardware or not...?
>
> > Also: only the crypto engine needs it for now, not all the other users
> > of the BAM engine.
>

Trying to set the lock/unlock bits will make
dmaengine_desc_attach_metadata() fail if HW does not support it.

> But they might eventually right?
>

Yes, and they will already have the interface to do it - in the form
of descriptor metadata.

Thanks,
Bartosz