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

[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?

I suggest to try to reproduce the underlying issue on Leon. You can use the
reproducer in tbe bugzilla item as starting point, but you likely have to
remove the SPARC64_STACK_BIAS stuff from it, and furthermore adjust the
wasteamount calculation, as it currently contains the Sparc64 page size minus 1
in the bit mask 0x1FFF, and the size of a void pointer in the constant 8.

Also, the value 1024 that appears in the increment of the for loop and the
printf call later is the page size divided by the size of a void pointer, and
might also need adjustment for "optimal experience" with that reproducer.

If I understand it correctly, you can run Sparc32 programs on Sparc64 systems,
and it already is established that the Sparc64 kernel does need the flushw
before invoking clone(), even on 32-bit userspace. If we expect the leon-compatible
libc to ever be executed on Sparc64 systems, I don't think just diabling the
work-around is a proper solution. If using "ta 3" works with 64-bit kernels
as well (but it is likely slower than flushw), using ta3 if we can't be sure
the binary will run on v9, and flushw if we can seems like the correct strategy
forwards.

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.

Do we have a physical leon3-based system at hand to test whether the workaround
is required at all for leon, and whether "ta 3" works?

Kind regards,
   Michael Karcher