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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CA+_ehUy0qHfQseVv4D4BbZa+wHKTCvY9dVNfUtcDF3x7XHss0Q@mail.gmail.com>
Date: Tue, 1 Apr 2025 13:13:21 +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:53 Herbert Xu
<herbert@...dor.apana.org.au> ha scritto:
>
> On Tue, Jan 14, 2025 at 01:36:36PM +0100, Christian Marangi wrote:
> >
> > +static void eip93_hash_export_sa_state(struct ahash_request *req,
> > +                                    struct eip93_hash_export_state *state)
> > +{
> > +     struct eip93_hash_reqctx *rctx = ahash_request_ctx_dma(req);
> > +     struct sa_state *sa_state = &rctx->sa_state;
> > +
> > +     /*
> > +      * EIP93 have special handling for state_byte_cnt in sa_state.
> > +      * Even if a zero packet is passed (and a BADMSG is returned),
> > +      * state_byte_cnt is incremented to the digest handled (with the hash
> > +      * primitive). This is problematic with export/import as EIP93
> > +      * expect 0 state_byte_cnt for the very first iteration.
> > +      */
> > +     if (!rctx->len)
> > +             memset(state->state_len, 0, sizeof(u32) * 2);
>
> I don't understand when this can occur.  As far as I can see,
> zero-length packets are never passed to the hardware for hashing.
>

I did some extra check on this and you are right. This was a leftover
(and discovery) when we were discussing on how to correctly
implement import/export.

My initial idea was to send a zero packet on export to sync and wait
for DMA to finish. But this was scrapped in favor of -EINPROGRESS
in the update function (that wasn't aware of possible)

If you are ok I can send a patch to drop this (and maybe leave the
comment just to document this strange finding)

What do you think?

> > +     else
> > +             memcpy(state->state_len, sa_state->state_byte_cnt,
> > +                    sizeof(u32) * 2);
>
> I need to know the endianness of state_byte_cnt, which I presume
> is the number of bytes that have been hashed into the partial
> hash state.

It's LE.

>
> I need this because I'm changing the export format of all ahash
> algorithms to match that of the generic implementation.  This is
> so that you can seamlessly switch between an async ahash and its
> sync fallback.
>