Bug 405377

Summary:	Handle new Linux kernel feature: Restartable Sequences ("rseq")
Product:	[Developer tools] valgrind	Reporter:	Derek Bruening <derek.bruening>
Component:	general	Assignee:	Julian Seward <jseward>
Status:	CONFIRMED ---
Severity:	normal	CC:	hgreving, mark, msc
Priority:	NOR
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	unspecified
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Attachments:	implement rseq as ENOSYS

Description Derek Bruening 2019-03-12 00:37:57 UTC

The Linux kernel has introduced a new feature called "Restartable Sequences"
or "rseq".  This raises multiple problems for dynamic binary instrumentation,
including loss of control due to the kernel redirecting the PC and incorrect
application behavior due to failing to preserve the semantics of these
code sequences.

DynamoRIO has looked at and tried to solve these issues for an earlier
version of rseq.  The new version of rseq, the one that went into the
official linux kernel, is more difficult to handle and may require
establishing conventions among software developers who use rseq.  Given that,
it may make sense to collaboratively come up with a solution that works for
all dynamic instrumentation frameworks.

See Kevin's post to the valgrind-developers list:
https://sourceforge.net/p/valgrind/mailman/valgrind-developers/thread/CAB%3DH8NUgjS9Ee7r_VWoBXafAZVYzW1%2BeHPzmA3j-Qeo2n22nmg%40mail.gmail.com/#msg36584233

See a writeup with further details of rseq and ideas for how to handle it here: https://github.com/DynamoRIO/dynamorio/wiki/Restartable-Sequences

The kernel commit adding rseq: https://github.com/torvalds/linux/commit/d82991a8688ad128b46db1b42d5d84396487a508

Comment 1 Derek Bruening 2019-09-17 22:16:27 UTC

Details on DynamoRIO's "run twice" solution and implementation for the rseq feature which is now generally available in recent kernels are at https://github.com/DynamoRIO/dynamorio/wiki/Restartable-Sequences

Comment 2 Mark Wielaard 2021-12-10 17:11:13 UTC

glibc will start using rseq:
https://sourceware.org/pipermail/libc-alpha/2021-December/133656.html

If they get an ENOSYS they will simply not use it.
So I propose that for now we "implement" rseq by just returning ENOSYS and not produce an warning for now.

Comment 3 Mark Wielaard 2021-12-10 17:14:16 UTC

Created attachment 144436 [details]
implement rseq as ENOSYS

Comment 4 Derek Bruening 2021-12-10 17:20:47 UTC

Updated link for the stale wiki page from the first comment above detailing the run-twice solution DynamoRIO has been using successfully for years now: https://dynamorio.org/page_rseq.html

Comment 5 Mark Wielaard 2021-12-15 11:33:29 UTC

For now I pushed the ENOSYS patch to make sure things just work with the new glibc.

commit 1024237358f01009fe233cb1294f3b8211304eaa
Author: Mark Wielaard <mark@klomp.org>
Date:   Fri Dec 10 17:41:59 2021 +0100

    Implement linux rseq syscall as ENOSYS
    
    This implements rseq for amd64, arm, arm64, ppc32, ppc64,
    s390x and x86 linux as ENOSYS (without warning).
    
    glibc will start using rseq to accelerate sched_getcpu, if
    available. This would cause a warning from valgrind every
    time a new thread is started.
    
    Real rseq (restartable sequences) support is pretty hard, so
    for now just explicitly return ENOSYS (just like we do for clone3).
    
    https://sourceware.org/pipermail/libc-alpha/2021-December/133656.html

Leaving this bug open for a real implementation.

Comment 6 Tom Hughes 2022-01-26 14:00:50 UTC

*** Bug 449199 has been marked as a duplicate of this bug. ***