Is there any more information about the __rseq_table convention available?

[Carrotman42]

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.

[compudj]

The __rseq_table is indeed meant to be there for use by debuggers. We should document this as a user-space requirement, but I don't see why the kernel should mandate it.

I would like to design an ABI for efficient registration/unregistration of rseq critical sections by JIT. This also would be a user-space only convention (no reason to involve the kernel there AFAIU).

I'd be interested to discuss this further. You can reach me by email at [email protected] so we could setup a phone meeting on this topic if you are available.

Thanks,

Mathieu

[Carrotman42]

DynamoRIO's aim is to transparently execute any arbitrary binary in the same way that the underlying OS would. From that perspective, requiring this metadata makes handling adversarial programs easier (since omitting this section would result in an invalid program to the kernel and DR wouldn't have to handle them). gdb has a similar mission, and this would help them as well by basically guaranteeing the table's existence for any arbitrary program. Admittedly I agree the existence of the __rseq_table is not needed from the perspective of the kernel/application, but adding it as a requirement would help adoption of the precise table format throughout various compiler communities and encourage better debugging of this low-level feature in practice.

But no worries, I expected the answer would be "no, it's much simpler to not require the table," given the existing constraints.