----- On Jul 15, 2020, at 11:12 AM, Florian Weimer fwei...@redhat.com wrote:
> * Carlos O'Donell: > >> On 7/13/20 11:03 PM, Mathieu Desnoyers wrote: >>> Recent discussion led to a solution for extending struct rseq. This is >>> an implementation of the proposed solution. >>> >>> Now is a good time to agree on this scheme before the release of glibc >>> 2.32, just in case there are small details to fix on the user-space >>> side in order to allow extending struct rseq. >> >> Adding extensibility to the rseq registration process would be great, >> but we are out of time for the glibc 2.32 release. >> >> Should we revert rseq for glibc 2.32 and spend quality time discussing >> the implications of an extensible design, something that Google already >> says they are doing? >> >> We can, with a clear head, and an agreed upon extension mechanism >> include rseq in glibc 2.33 (release scheduled for Feburary 1st 2021). >> We release time boxed every 6 months, no deviation, so you know when >> your next merge window will be. >> >> We have already done the hard work of fixing the nesting signal >> handler issues, and glibc integration. If we revert today that will >> also give time for Firefox and Chrome to adjust their sandboxes. >> >> Do you wish to go forward with rseq as we have it in glibc 2.32, >> or do you wish to revert rseq from glibc 2.32, discuss the extension >> mechanism, and put it back into glibc 2.33 with adjustments? > > I posted the glibc revert: > > <https://sourceware.org/pipermail/libc-alpha/2020-July/116368.html> > > I do not think we have any other choice at this point. This is indeed the safe course of action. Let's hope the overall interest about rseq will be sufficient to justify integrating extensibility support in the rseq system call ABI, otherwise we have a catch-22 situation where everything is stalled again, due to further progress on rseq kernel features awaiting user feedback on the existing implementation, which will never come because the integration of coordinated use across libraries is awaiting further development at the kernel level. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
