[PATCH] Mitigation for "clone on sparc might fail with -EFAULT for no valid reason" (bz 31394)

[Michael.Karcher]

Am 03.08.2024 um 13:14 schrieb Michael.Karcher:

> Am 02.08.2024 um 15:16 schrieb Adhemerval Zanella Netto:
>> On 02/08/24 09:10, Florian Weimer wrote:
>>> * Andreas K. Hüttel:
>>>> +    save    %sp,-96,%sp
>>>> +    flushw
>>>> +    restore
>>> This causes sparcv8-linux-gnu-leon3 fail to build with:
>>>
>>> ../sysdeps/unix/sysv/linux/sparc/sparc32/clone.S: Assembler messages:
>>> ../sysdeps/unix/sysv/linux/sparc/sparc32/clone.S:32: Error: Architecture mismatch on "flushw ".
>>> ../sysdeps/unix/sysv/linux/sparc/sparc32/clone.S:32: (Requires v9|v9a|v9b|v9c|v9d|v9e|v9v|v9m|m8; requested architecture is leon.)
>>>
>>> What should we do about it?  Add #ifdef __sparcv9 around the workaround?
>> Maybe use 'ta 3' for pre sparcv9 which seems what gcc uses for flush_register_window?
> John Paul Adrian, would you be able to test whether "ta 3" instead of "flushw" in
> sparc32/clone.s works on the Sparc 64 system we discovered the issue on and
> report back the result? Maybe you/we can also prepare an official 32-bit version
> of the demo tool.

As commented in bugzilla, we tested the behaviour on a Sparc V9 host, and were able
to reproduce the behaviour reliably for both 32-bit and 64-bit binaries if a libc
without workaround was used. Either flushw or ta 3 will fix the issue (but a nop in
that place instead of the flushw or ta 3 instruction) will not work, proving that
it is indeed the flushw/ta 3 that makes clone work reliably.

As a result, I recommend to use flushw on v9 only, and fall back to ta 3 on v8 or
earlier. Thanks to Adhemerval Zanella Netto for the suggestion to use ta 3.

Kind regards,
   Michael Karcher