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

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

Message-ID: <alpine.DEB.2.21.2502041508520.41663@angie.orcam.me.uk>
Date: Tue, 4 Feb 2025 16:44:36 +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 Mon, 3 Feb 2025, Jessica Clarke wrote:

> > 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.
> 
> No it’s not. The calling convention is there so that each side of the
> call know how the data is being passed between them. When inlining
> occurs there is no such call and compilers can do whatever they like.

 Right, I guess I got influenced too much by my MIPS experience here.

 The contract here is to pass a 32-bit integer as an argument through a 
function call boundary and with the RISC-V ISA saying the upper 32-bits of 
an input hardware register are don't-cares for 32-bit integer operations 
this contract is still met if inlining discards the sign-extension madated 
by the psABI.  And consequently a piece of inline assembly cannot expect 
an incoming 32-bit integer in a register to be correctly interpreted as a 
64-bit integer of equal value instead.

 Although I find it odd in these circumstances that the psABI mandates 
sign-extension here.  And honestly I think an explicit cast ought to be 
added to the relevant assembly input operands (or a temporary variable of 
the appropriate type added and used to convert between the incoming value 
and the input operands); it will be a no-op for an optimising compiler 
when it knows the value has been sign-extended already and will carry the 
semantics information for a human code reader even if sign-extension has 
been implicitly ensured by the psABI despite the data type itself not 
making it evident.

 Thanks for correcting me overall.

  Maciej