linux-kernel - Re: [PATCH v11 3/3] crypto: Add Inside Secure SafeXcel EIP-93 crypto engine support

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+_ehUxCD1+CUJ_6rXa8ra=tZ1Nr1LCZVYQ0X9RhDndJ33F=ug@mail.gmail.com>
Date: Tue, 1 Apr 2025 13:20:44 +0200
From: "Christian Marangi (Ansuel)" <ansuelsmth@...il.com>
To: Herbert Xu <herbert@...dor.apana.org.au>
Cc: "David S. Miller" <davem@...emloft.net>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Antoine Tenart <atenart@...nel.org>, Peter Zijlstra <peterz@...radead.org>, 
	Ingo Molnar <mingo@...hat.com>, Will Deacon <will@...nel.org>, Waiman Long <longman@...hat.com>, 
	Boqun Feng <boqun.feng@...il.com>, Nathan Chancellor <nathan@...nel.org>, 
	Nick Desaulniers <ndesaulniers@...gle.com>, Bill Wendling <morbo@...gle.com>, 
	Justin Stitt <justinstitt@...gle.com>, linux-crypto@...r.kernel.org, 
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, 
	llvm@...ts.linux.dev, upstream@...oha.com, 
	Richard van Schagen <vschagen@...oud.com>
Subject: Re: [PATCH v11 3/3] crypto: Add Inside Secure SafeXcel EIP-93 crypto
 engine support

Il giorno mar 1 apr 2025 alle ore 12:57 Herbert Xu
<herbert@...dor.apana.org.au> ha scritto:
>
> On Tue, Apr 01, 2025 at 12:54:05PM +0200, Christian Marangi (Ansuel) wrote:
> > Il giorno mar 1 apr 2025 alle ore 12:08 Herbert Xu
> > <herbert@...dor.apana.org.au> ha scritto:
> > >
> > > On Tue, Jan 14, 2025 at 01:36:36PM +0100, Christian Marangi wrote:
> > > >
> > > > +static int eip93_send_hash_req(struct crypto_async_request *async, u8 *data,
> > > > +                            dma_addr_t *data_dma, u32 len, bool last)
> > > > +{
> > >
> > > ...
> > >
> > > > +again:
> > > > +     ret = eip93_put_descriptor(eip93, &cdesc);
> > > > +     if (ret) {
> > > > +             usleep_range(EIP93_RING_BUSY_DELAY,
> > > > +                          EIP93_RING_BUSY_DELAY * 2);
> > > > +             goto again;
> > > > +     }
> > > > +
> > > > +     /* Writing new descriptor count starts DMA action */
> > > > +     writel(1, eip93->base + EIP93_REG_PE_CD_COUNT);
> > >
> > > Why is there no locking here? Shouldn't this be under ring->write_lock?
> > >
> >
> > Hi Herbert,
> > this is really to tell DMA that there is new packet to process and
> > gets decreased instantly.
> > The lock is used to track what descriptor index should be used in the
> > ring in the put and get
> > functions.
>
> AFAICS it's not safe to call eip93_put_descriptor simultaneously
> since it doesn't use atomics.  Without locking in eip93_send_hash_req
> two threads hashing into two separate eip93 requests will be calling
> eip93_put_descriptor at the same time.
>

Sorry but isn't it enough to acquire lock before eip93_put_descriptor to
prevent 2 thread?

Or you are suggesting that also

writel(1, eip93->base + EIP93_REG_PE_CD_COUNT);

should be done atomically?

Maybe I can better handle that writel(1) by using atomic_t
value and atomic_inc/dec?