[PATCH] nptl: add RSEQ_SIG for RISC-V

[Palmer Dabbelt]

On Mon, 09 Dec 2024 08:26:52 PST (-0800), mjeanson@efficios.com wrote:
> 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].

Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>
Acked-by: Palmer Dabbelt <palmer@rivosinc.com>

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