From: David Laight <david.laight.linux@gmail.com>
To: Qingfang Deng <qingfang.deng@linux.dev>
Cc: Anastasia Tishchenko <sv3iry@gmail.com>,
Lukas Wunner <lukas@wunner.de>,
Stefan Berger <stefanb@linux.ibm.com>,
Ignat Korchagin <ignat@linux.win>,
Herbert Xu <herbert@gondor.apana.org.au>,
"David S. Miller" <davem@davemloft.net>,
linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH v2] crypto: ecc - Fix carry overflow in vli multiplication
Date: Wed, 13 May 2026 22:08:25 +0100 [thread overview]
Message-ID: <20260513220825.0d10d80f@pumpkin> (raw)
In-Reply-To: <20260513123948.842-1-qingfang.deng@linux.dev>
On Wed, 13 May 2026 20:39:48 +0800
Qingfang Deng <qingfang.deng@linux.dev> wrote:
> On Wed, 13 May 2026 at 13:57:40 +0300, Anastasia Tishchenko wrote:
> > diff --git a/crypto/ecc.c b/crypto/ecc.c
> > index 43b0def3a225..6eb4d97a5f0d 100644
> > --- a/crypto/ecc.c
> > +++ b/crypto/ecc.c
> > @@ -393,14 +393,26 @@ static uint128_t mul_64_64(u64 left, u64 right)
> > return result;
> > }
> >
> > -static uint128_t add_128_128(uint128_t a, uint128_t b)
> > +/* Calculate addition with overflow checking. Returns true on wrap-around,
> > + * false otherwise.
> > + */
> > +static bool check_add_128_128_overflow(uint128_t *result, uint128_t a,
> > + uint128_t b)
> > {
> > - uint128_t result;
> > + bool carry;
> >
> > - result.m_low = a.m_low + b.m_low;
> > - result.m_high = a.m_high + b.m_high + (result.m_low < a.m_low);
> > + result->m_low = a.m_low + b.m_low;
> > + carry = (result->m_low < a.m_low);
> >
> > - return result;
> > + result->m_high = a.m_high + b.m_high + carry;
>
> If CONFIG_ARCH_SUPPORTS_INT128 is defined, you can convert them to
> "unsigned __int128" as done in mul_64_64(), and use check_add_overflow()
> to get the carry.
Can you guarantee the compiler generates 'constant time' code for
any of this?
If you care then relying on compiler support for anything that might
generate a conditional jump isn't a good idea.
Just writing 'bitwise' arithmetic doesn't mean the compiler won't
use branches.
Even if you don't get one today, someone else might get one tomorrow.
IIRC even on x86 'x += (a < b)' can generate a branch rather than the
obvious 'cmp a, b; adc $0, x', or the longer cmov or setc sequences.
You pretty much have to use asm for anything that isn't trivial arithmetic.
-- David
>
> > +
> > + /* Using constant-time bitwise arithmetic to prevent timing
> > + * side-channels.
> > + */
> > + carry = (result->m_high < a.m_high) |
> > + ((result->m_high == a.m_high) & carry);
> > +
> > + return carry;
> > }
> >
>
> Regards,
> Qingfang
>
next prev parent reply other threads:[~2026-05-13 21:08 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-13 10:57 [PATCH v2] crypto: ecc - Fix carry overflow in vli multiplication Anastasia Tishchenko
2026-05-13 12:39 ` Qingfang Deng
2026-05-13 14:09 ` Lukas Wunner
2026-05-13 21:08 ` David Laight [this message]
2026-05-13 14:31 ` Lukas Wunner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260513220825.0d10d80f@pumpkin \
--to=david.laight.linux@gmail.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=ignat@linux.win \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=qingfang.deng@linux.dev \
--cc=stable@vger.kernel.org \
--cc=stefanb@linux.ibm.com \
--cc=sv3iry@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox