lkml.org 
[lkml]   [2022]   [Oct]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH v2 01/39] Documentation/x86: Add CET description
    Date
    On Wed, 2022-10-12 at 14:29 +0200, Florian Weimer wrote:
    > The ABI was finalized around four years ago, and we have shipped
    > several
    > Fedora and Red Hat Enterprise Linux versions with it. Other
    > distributions did as well. It's a bit late to make changes now, and
    > certainly not for such trivialities. In the case of the IBT ABI, it
    > may
    > be tempting to start over in a less trivial way, to radically reduce
    > the
    > amount of ENDBR instructions. But that doesn't concern SHSTK, and
    > there's no actual implementation anyway.
    >
    > But as H.J. implied, you would have to do rather nasty things in the
    > kernel to prevent us from achieving ABI compatibility in userspace,
    > like
    > parsing property notes on the main executable and disabling the new
    > arch_prctl calls if you see something there that you don't like. 8-)
    > Of course no one is going to implement that.
    >
    > (We are fine with swapping out glibc and its dynamic loader to enable
    > CET with the appropriate kernel mechanism, but we wouldn't want to
    > change the way all other binaries are marked up.)

    So we have these compatibility issues with existing binaries. We know
    some apps are totally broken. It sounds like you are proposing to
    ignore this and let people who hit the issues work through it
    themselves. This was also proposed by other glibc developers as a
    solution for past CET compatibility issues that broke boot on kernel
    upgrade. I have to say, as the person pushing these patches, I’m
    uncomfortable with this approach. I don’t think users will like the
    results. Basically, do they want to upgrade and run a bunch of untested
    integration with known failures? I also don’t want to get this feature
    reverted and I’m not exactly sure how this scenario would be taken.

    But I hear the point about it not being ideal to abandon the existing
    CET userspace. I think there is also a point about how userspace chose
    to do this optimistic and early wide enabling, even if it was a bad
    idea, and so how much should the kernel try to save userspace from
    itself. So what do you think about this instead:

    The current psABI spec talks about the binary being compatible with
    shadow stack. It doesn’t say much about what should happen after the
    loader. Since the greater ecosystem has used this bit with a more
    cavalier attitude, glibc could treat it as a request for a warn and
    continue mode. In the meantime we could have a new bit shstk_strict,
    that requests behavior like these patches implement, and kills the
    process on violation. Glibc/tools could add support for this strict bit
    and anyone that wants to more carefully compile with it could finally
    get shadow stack today. Then the implementation of the warn and
    continue mode could follow that, and glibc could map the original shstk
    bit to that kernel mode. So the old binaries would get there
    eventually, which is better than the continuing nothing they have
    today.

    And speaking of having nothing today, there are people that really want
    to use shadow stack and do not care at all about having CET support for
    existing binaries. Neither glibc or elf bits are required to use kernel
    shadow stack support. So if it comes to it, I don’t want to hold
    support back for other users because the elf note bit enabling path
    grew some issues.

    Please let me know about what you think of that plan.
    \
     
     \ /
      Last update: 2022-10-13 23:29    [W:2.788 / U:0.164 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site