[PATCH 0/4] Restartable Sequences support for glibc 2.30

[Carlos O'Donell]

On 3/22/19 1:55 PM, Mathieu Desnoyers wrote:
> ----- On Mar 22, 2019, at 1:34 PM, Carlos O'Donell codonell@redhat.com wrote:
> 
>> On 2/12/19 2:42 PM, Mathieu Desnoyers wrote:
>>> The only point that still appears to not reach concensus is whether it's
>>> acceptable to define the RSEQ_SIG code signature for each architecture.
>>> If I missed other points that failed to reach concensus, please let me
>>> know!
>>
>> I have no objection to RSEQ_SIG being a signature that each architecture uses.
>>
>> Can you summarize the previous discussions here?
> 
> The culprit is whether we provide an architecture-agnostic "generic" value
> for RSEQ_SIG for architectures that do not define a specific RSEQ_SIG, or
> leave RSEQ_SIG undefined for architectures that do not define it yet.
> 
> Considering that RSEQ_SIG ends up being a 32-bit value that maps to actual
> architecture code compiled into applications and libraries, it's
> understandable that it needs to be defined for each architecture specifically.
> For instance, 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.
> 
> There has been ideas floating around about having a "generic" value for
> RSEQ_SIG that would apply to all architectures that do not override it.
> However, if we have this, it makes it impossible for those architectures
> to ever define a different value if they ever choose so, because that value
> ends up being an ABI that is built into applications and libraries including
> the glibc rseq header. Changing that value would break applications.
> 
> So I favor _not_ defining any generic RSEQ_SIG, and adding per-architecture
> RSEQ_SIG define gradually. Therefore, user-space can #ifdef on whether
> RSEQ_SIG is defined or not after including the glibc rseq header.

That makes perfect sense.

I was particularly worried about hardware that wasn't designed for
having constant pools and injecting invalid instructions into that
stream can worse speculative execution and break developer tools that
need to know about new instructions (like valgrind).

-- 
Cheers,
Carlos.