[PATCH] nptl: add RSEQ_SIG for RISC-V

[Michael Jeanson]

On 2024-10-02 07:58, Florian Weimer wrote:
>>>> +
>>>> +/* RSEQ_SIG is a signature required before each abort handler code.
>>>> +
>>>> +   It is a 32-bit value that maps to actual architecture code compiled
>>>> +   into applications and libraries.  It needs to be defined for each
>>>> +   architecture.  When choosing this value, it needs to be taken into
>>>> +   account that generating invalid instructions may have ill effects on
>>>> +   tools like objdump, and may also have impact on the CPU speculative
>>>> +   execution efficiency in some cases.
>>>> +
>>>> +   Select the instruction "csrw mhartid, x0" as the RSEQ_SIG. Unlike
>>>> +   other architectures, the ebreak instruction has no immediate field for
>>>> +   distinguishing purposes. Hence, ebreak is not suitable as RSEQ_SIG.
>>>> +   "csrw mhartid, x0" can also satisfy the RSEQ requirement because it
>>>> +   is an uncommon instruction and will raise an illegal instruction
>>>> +   exception when executed in all modes.  */
>>>> +
>>>> +#if __BYTE_ORDER == __LITTLE_ENDIAN
>>>> +#define RSEQ_SIG	0xf1401073
>>>> +#else
>>>> +/* RSEQ is currently only supported on Little-Endian.  */
>>>> +#endif
>>>
>>> Jeff, Kito,
>>>
>>> would you be able to verify that the choice of instruction is
>>> appropriate for this purpose? It should be something that never appears
>>> among compiler-generated instructions (or anything else in the .text
>>> segment).  It does not necessarily have to trap because it is never
>>> executed.
>>
>> The compiler won't generate these.  There's no rules there or
>> anything, it's just not a useful instruction for compilers to generate
>> and thus there's no reason to do so.  If it's going to end up as a
>> defacto ABI we should write that down somewhere, and I guess we could
>> go scrub through a bunch of binaries to make sure that's true.
> 
> It's a glibc-specific ABI.  We tell the kernel which value to use.
> Applications targeting glibc need to use RSEQ_SIG from <sys/rseq.h>.  In
> this regard, it's no different from the size of pthread_key_t, or the
> value of the RTLD_NODELETE constant.  For those, applications need to be
> consistent with glibc, too.
> 
> Scanning binaries might be a reasonable thing to do, but I currently do
> not have a good way to do that.
> 
>> For semihosting we avoided those issues by using some of the NOP space
>> to wrap the ebreak with magic values.  That results in a 3-instruction
>> sequence, but it's made up of much more common instructions and thus
>> less likely to trip up these sorts of edge cases.  Is something like
>> that possible for rseq?
> 
> The kernel only checks the preceding four bytes.  Trapping is not
> required.

Any objections to using this instruction? It's what is currently used in
the kernel selftests [1].


[1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/tools/testing/selftests/rseq/rseq-riscv.h#n13