From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4555F3B1014 for ; Tue, 12 May 2026 15:27:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778599652; cv=none; b=JvTeCmLI5boACDVV1Fm/iJ1AI5fpwK+E1Y0oIcpMasd5P3shxcoyu1HjjmcmIIIASzN4wvIrkj/7Xrm8WnN+eS3IE+9v/68T6AhIxBdkePaqsjfcBzJtJOiYh1L03KA8Ax10iYrnKZIJyJM7sxgjIsI4piE1JXdUndssex9Cppk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778599652; c=relaxed/simple; bh=FPazZEp6GA5Hmo+4/6qfbStOMmXopx//Q6AmtwPstsc=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=KITF8x2SdDvFBw1/4YFQn4V0m2tgVLBgGqxnpxOIrtn3MkOd/Ay7/UgzCdl8Dh71Il53+4t18HISD+8nH7gr3MsAkoy91OQD9wVl7fRAatPPWJ39dmPLT+rl5gs6y4ceeDMaUEB8T24NOzzZg5wpENAbGJhc0q9AzwkaZL6z7Ew= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=NbOawvG5; arc=none smtp.client-ip=209.85.128.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="NbOawvG5" Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-488b3f8fa2bso64204015e9.1 for ; Tue, 12 May 2026 08:27:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778599650; x=1779204450; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=NM+uE6jwM63o6mhwLABZspTdPrtPWxx1VtWOVwLXmwk=; b=NbOawvG5xmfWjJk3zuoZrpd5Ec0iMkdS/lEGY5R4nUUlXMzRRBVxXnA/gdWkaUSr2R Fv74iFQB0YRQKAkpcqjBJKj0ZiT/587A6Uzz+VvU8cm2OdOUaOQZSeT1czmglkZVJmbI +YBPdxMatdM45+s+xKLcezzw9fsX9xfusPu3ZGfcZLCYcZZqQ+ADmugNpSo5vp2Z2fpV sV5un/U5IEJS3d/pc8dXiwVKSgc7Z1eSOWXalgaVYga8P92EwkIPsqPSm+ZW+QqJ0hYg ctrTBos3WOeCBlbT0Kh9oARlj7flkQbPZsEwhclVzcHG7RuxnszIvsN8pzdjMZ0J1sqP mSmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778599650; x=1779204450; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=NM+uE6jwM63o6mhwLABZspTdPrtPWxx1VtWOVwLXmwk=; b=ajm4hLZnB4nDf0+OLPUWmzKPD55igOvkpKKz7kfhvlRZbLK7B/CF4xwAEYyW/keLiO C9Q+zQTDgzV2nP0Jge07wKAhlLxKljuVNMJuJ5afL3hgMA+Mc7lyvLJPmaP6sOGzJsXa cwcP4EEgkmh/CmY5viua01J2j8rVcYoZg8Dn0aZqDc3TX9jph3FbbXu59s90YQ+Ufamh 0GvYvXk7kW05v0buH+gf+Idi1mDs7z0EbAmqE5Ae4zjBvPeDmP9ijBQK3mejorl7Y3kD qm5InL8tYzn5u2NFCa2insdS0OheLZvUPqT3xUfgLGjYD3MuESzyTlDZ8TBjg748sgqA FwxA== X-Forwarded-Encrypted: i=1; AFNElJ+3qdskiXAiJ3oLGcXJtK05gPVtpM7H3HUHRkpYpxYY81DEA7crWib/hWZastDVYZ8agI2Hbt7ejqX2xKA=@vger.kernel.org X-Gm-Message-State: AOJu0YwjTnYD9rQXHq15OwpaBm+ZlOoVvYluqGXCdQ7d9ovzjHwA1JVJ yWKzeLlCDDVmjEq13YMWeJu2rKCfq9RKEscZaP8RLienPJp9RFeS2bUq X-Gm-Gg: Acq92OEFxhFNdmRqjlT6fkZhB8xGzRc5EUpYzStFVJX/WzS/cNdwH1HDh/Nhw0O6/p7 I4M3XGfJhz/rF179GeWlrJTTalwZcLF97Sb0YRK+KQwDhRYeA9TjEn/gLaqDJ59hTIggda3CGk2 b0Dm82oL8r+ABeCRUu9zJyvuJhk6htHZJZPoFvDvAhB3Azi7HVRNS6pMKvX4TplSS9RU4Ds7UD7 pC+vEDr227+KWVqpJeEY0+hl/w9NGPhL6Kzry5CZ1JGrI8BFdSZ4SUm97RvkR9NpefJGBsWmrhw /NemP+eKHSc1cnAKM074snbEwgIX10HX6Kf18okDVjItcdZT4a+B/J1+cGp62nBnpjAouPSdJvn xjK7Le0DeVYBn1FYToHuASe7RiHXmeHQg1OSDizLmYtKPrZYyiT4XrgCDYUOMfxZrgc5446kDd6 YnWrat3WYRevLHBSpoB3I4l6tdKFpqyTrdIdEuMM1+nPA9NhXY4YhBcBltoz92 X-Received: by 2002:a05:600c:3488:b0:488:aa33:dc8f with SMTP id 5b1f17b1804b1-48e8decf95amr61589075e9.0.1778599649462; Tue, 12 May 2026 08:27:29 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48fc8cccf90sm5334695e9.0.2026.05.12.08.27.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 May 2026 08:27:29 -0700 (PDT) Date: Tue, 12 May 2026 16:27:26 +0100 From: David Laight To: Lukas Wunner Cc: Anastasia Tishchenko , Ignat Korchagin , Stefan Berger , Herbert Xu , "David S . Miller" , linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] crypto : ecc - Fix carry overflow in vli multiplication Message-ID: <20260512162726.5a7a1b52@pumpkin> In-Reply-To: References: <20260508114844.29694-1-sv3iry@gmail.com> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, 12 May 2026 15:48:11 +0200 Lukas Wunner wrote: > On Fri, May 08, 2026 at 02:48:44PM +0300, Anastasia Tishchenko wrote: > > The carry flag calculation fails when r01.m_high is saturated > > (0xFFFFFFFFFFFFFFFF) and addition of lower bits overflows. > >=20 > > The condition (r01.m_high < product.m_high) doesn't handle the case > > where r01.m_high =3D=3D product.m_high and an additional carry exists > > from lower-bit overflow. > >=20 > > Add proper handling for this boundary by accounting for the carry > > from the lower addition. =20 > [...] > > +++ b/crypto/ecc.c > > @@ -427,7 +427,10 @@ static void vli_mult(u64 *result, const u64 *left,= const u64 *right, > > product =3D mul_64_64(left[i], right[k - i]); > > =20 > > r01 =3D add_128_128(r01, product); > > - r2 +=3D (r01.m_high < product.m_high); > > + if (r01.m_high !=3D product.m_high) > > + r2 +=3D (r01.m_high < product.m_high); > > + else > > + r2 +=3D (r01.m_low < product.m_low); > > } > > =20 > > result[k] =3D r01.m_low; =20 >=20 > ICYMI, sashiko's AI-generated review alleges that the if-else condition > may cause a timing side channel vis-=C3=A0-vis binary arithmetic: >=20 > https://sashiko.dev/#/patchset/20260508114844.29694-1-sv3iry%40gmail.com >=20 > You may want to address this if/when respinning your patch. If you do, > a code comment is probably merited to explain this subtlety. Something like:=09 r2 +=3D (r01.m_high < product.m_high); r2 +=3D (r01.m_high =3D=3D product.m_high) & (r01.m_low < product.m_low); would be constant time - but the compiler is very unlikely to generate the object code you want on all (any?) architectures. On x86 you want something like (pardon the pigeon assembler): xor %rax,%rax cmp r01.m_high, product.m_high setc %al lea r2, (r2, %rax) sete %al cmp r01.m_low, product.m_low cmovnc %al, %ah add r2, %rax but I bet (two beers) you can't get it. -- David >=20 > Thanks, >=20 > Lukas >=20