linux-kernel - Re: [PATCH] riscv/atomic: Do proper sign extension also for unsigned in arch

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: <alpine.DEB.2.21.2502030510390.41663@angie.orcam.me.uk>
Date: Mon, 3 Feb 2025 13:57:30 +0000 (GMT)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: Jessica Clarke <jrtc27@...c27.com>
cc: Andreas Schwab <schwab@...e.de>, Alexandre Ghiti <alex@...ti.fr>, 
    linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] riscv/atomic: Do proper sign extension also for unsigned
 in arch_cmpxchg

On Thu, 30 Jan 2025, Jessica Clarke wrote:

> >> a2 is used as it is passed by the calling function, so we can't be sure a2
> >> is sign extended to me, what am I missing?
> > 
> > 32-bit scalar arguments are guaranteed to be sign extended on entry.
> 
> Firstly, the calling convention is irrelevant if the function is
> inlined, which this almost always will be.

 Umm, that would be a compiler bug then, as inlining is supposed not to 
change language semantics.  IOW the compiler is expected to explicitly 
sign-extend the arguments of an inlined function at their evaluation point 
just as it would at an actual function call unless the compiler is able to 
prove they have come out sign-extended already from previous operations.

  Maciej