On Mon, Oct 10, 2022 at 9:44 AM Edgecombe, Rick P <rick.p.edgecombe@xxxxxxxxx> wrote: > > On Mon, 2022-10-10 at 14:19 +0200, Florian Weimer wrote: > > Uhm, I think we are using binutils 2.30 with extra fixes. I hope > > that > > these binaries are still valid. > > Yea, you're right. Andrew Cooper pointed out it has been supported > since 2.29, so 2.30 should be fine. > > > > > More importantly, glibc needs to be configured with --enable-cet > > explicitly (unless the compiler defaults to CET). The default glibc > > build with a default GCC will produce dynamically-linked executables > > that disable CET (when running on later/differently configured glibc > > builds). The statically linked object files are not marked up for > > CET > > in that case. > > Thanks, that's a good point. I'll add a blurb about glibc needs to be > compiled with CET support. > > > > > I think the goal is to support the new kernel interface for actually > > switching on SHSTK in glibc 2.37. But at that point, hopefully all > > those existing binaries can start enjoying the STSTK benefits. > > Can you share more about this plan? HJ was previously planning to wait > until the kernel support was upstream before making any more glibc > changes. Hopefully this will be in time for that, but I'd really rather > not repeat what happened last time where we had to design the kernel > interface around not breaking old glibc's with mismatched CET > enablement. > > What did you think of the proposal to disable existing binaries and > start from scratch? Elaborated in the coverletter in the section > "Compatibility of Existing Binaries/Enabling Interface". My current glibc plan is that kernel won't enable CET automatically and glibc will issue syscall to enable CET at early startup time. All existing CET enabled dynamic executables will have CET enabled under the CET kernel and the updated CET glibc. -- H.J.
