compudj / librseq

Library for Restartable Sequences

Library for Restartable Sequences

by Mathieu Desnoyers

Building

Prerequisites

This source tree is based on the Autotools suite from GNU to simplify portability. Here are some things you should have on your system in order to compile the Git repository tree:

• GNU Autotools (Automake >= 1.12, Autoconf >= 2.69, Autoheader >= 2.69; make sure your system-wide automake points to a recent version!)
• GNU Libtool >= 2.2
• Linux kernel headers from kernel >= 4.18 to build on x86, arm, ppc, and mips and from kernel >= 4.19 to build on s390.

Building steps

If you get the tree from the Git repository, you will need to run

./bootstrap

in its root. It calls all the GNU tools needed to prepare the tree configuration.

To build and install, do:

./configure
make
sudo make install
sudo ldconfig

Note: the configure script sets /usr/local as the default prefix for files it installs. However, this path is not part of most distributions' default library path, which will cause builds depending on librseq to fail unless -L/usr/local/lib is added to LDFLAGS. You may provide a custom prefix to configure by using the --prefix switch (e.g., --prefix=/usr).

Building against a local version of the kernel headers

cd /path/to/kernel/sources
make headers_install
cd /path/to/librseq
CPPFLAGS=-I/path/to/kernel/sources/usr/include ./configure
make
sudo make install
sudo ldconfig

librseq's Issues

error: duplicate 'inline'

In file included from /usr/include/features.h:503,
from /usr/include/bits/libc-header-start.h:33,
from /usr/include/stdint.h:26,
from /usr/lib64/gcc/riscv64-suse-linux/13/include/stdint.h:9,
from ../../../tests/unit/arch-mo.c:5,
from ../../../tests/unit/arch-mo-cxx.cpp:5:
../../../include/rseq/rseq-riscv-bits.h:9:15: error: duplicate 'inline'
9 | static inline __always_inline
| ^~~~~~~~~~~~~~~

LGPL license for the initialization code

While almost all of the logic for librseq implementation lives in header files, small pieces responsible for the initialization live in src/rseq.c, which remains LGPL-licensed.

Could you, please, clarify if this licensing schema was intentional?
It is possible to change rseq.c license to a dual-license / LGPG AND MIT?

Concurrency id support

Hi there,

I've 2 questions regarding mm_cid (since the kernel 6.3.0 added support for the concurrency id):

1. Are there currently plans to add also functionality (i.e., rseq_current_mm_cid) for supporting this kernel feature in librseq?

2. When I use the mm_cid to index into per-CPU data structures, do i need to check inside the critical section whether mm_cid matches (or just the cpu_id via RSEQ_ASM_CMP_CPU_ID)?

Thanks!

Questions: Writing critical sections using librseq

Hi,
I've a few general questions regrading implementing own rseq critical sections (CS) using the macros & rseq registration mechanism of librseq (and would be grateful for answers).

(1) I'm currently comparing the expected cpu and -mm_cid w/ the current values (in the rseq struct) using the macro RSEQ_ASM_CMP_CPU_ID as follows:

/* AssemblerTemplate */
RSEQ_ASM_CMP_CPU_ID(cpu_id, RSEQ_ASM_TP_SEGMENT:RSEQ_CPU_ID_OFFSET(%[rseq_offset]), 4f)   // 4f = abort_ip
RSEQ_ASM_CMP_CPU_ID(c_id, RSEQ_ASM_TP_SEGMENT:RSEQ_MM_CID_OFFSET(%[rseq_offset]), 4f)
// ...

/* InputOperands */
: [cpu_id]                                     "r"   (cpu_expected),
  [c_id]                                       "r"   (cid_expected)

Is this correct?
Also, if I'm not mistaken, the asm helpers of librseq don't seem to check for the mm_cid atm?

(2) Instruction reordering (by the CPU):
Assuming a ringbuffer implementation which uses rseqs:

// Prepatory phase
Read current write pointer
Copy new data starting @ current write pointer

// <<<   Is a fence here required  ????   >>>

// Commit phase
Update write pointer

Does the CS above need a fence instruction (like mfence) to prevent reordering (of the 'Copy' from the prepatory phase w/ the 'Update' of the commit phase)?

(3) What's the significance of .byte 0x0f, 0xb9, 0x3d in RSEQ_ASM_DEFINE_ABORT?
( The following RSEQ_SIG appears to be a safe-guard against attacks, but what's the purpose of the signature above? )

Thanks!

Provide a way to detect non-libc-based rseq registration

We at userver (https://github.com/userver-framework/userver) are trying to use rseq for some of our synchronization primitives.

Our thread-migrating coroutines model makes it hard to impossible to dynamically register threads in rseq safely by calling rseq_register_current_thread.

However, if glibc automatically registers threads for us, then this is fine. So:

1. If there is no rseq support, then we obviously don't want to use rseq, allocate any buffers for it
2. If there is rseq support, but without libc, then we don't want to use rseq for the reasons above
3. If there is libc-based rseq support, then we do want to use rseq

librseq has the internal flag rseq_ownership, which, coupled with rseq_available(), will provide us the required info.

So librseq could expose rseq_ownership, or provide an additional function like rseq_available_libc_based(), which would be even more handy for us.

Is there any more information about the __rseq_table convention available?

Looking through various mailing lists (and code in this repo) there are references to an __rseq_table section which would ideally contain useful metadata about the restartable sequences in the program. Unfortunately I can't find a canonical source of what this table should look like, nor discussions related to how (or whether) to handle dynamically generated restartable sequences (e.g. in JIT compilation). Is there a place where I can find this information?

Further, from what I can gather, it appears that this section is simply a convention rather than something the kernel implementation requires for use of the feature; is that accurate? As discussed elsewhere, this sort of table is needed gdb and other types of execution emulators for efficient and correct execution of a program which contains restartable sequences. Was there any thought about making this table semantically required by the kernel in some way? (sidestepping the JIT question again here ;) )

Background: I am from the DynamoRIO Project (github), a dynamic binary translation framework, and we would like to handle restartable sequences correctly. We have similar requirements and problems to debuggers, so the __rseq_table looked like it would solve some of the problems we expect to encounter.