lkml.org 
[lkml]   [2020]   [Jul]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC PATCH 0/4] rseq: Introduce extensible struct rseq
    From
    Date
    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?

    --
    Cheers,
    Carlos.

    \
     
     \ /
      Last update: 2020-07-14 22:56    [W:3.140 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site