George Koehler <kernigh@gmail.com> wrote:
> On Sun, 29 Oct 2023 16:24:02 +0100
> Otto Moerbeek <otto@drijf.net> wrote:
>
> > On Sun, Oct 29, 2023 at 08:13:43AM -0400, Brad Smith wrote:
> > > The existing Boost::Context diffs do not apply as is, there were some changes there.
> > > Someone more familiar with this neeeds to look at what needs to be done for i386.
> > >
> > > https://github.com/boostorg/context/commit/2f0b5034b72cbb858849bd744ffb06df04521e5a
> >
> > This one is a bit surprising. PowerDNS Recursor has been compiled with
> > -fstack-protector for ages, and has no issues with the existing
> > (patched to conform to out calling conventions) context switch
> > assembly in boost 1.80 on i386.
> >
> > I'm setting up a i386 VM to check things further. I imagine we might
> > be able to take the easy way and continue to use the asm from the 1.80
> > port in boost 1.83.
> >
> > -Otto
>
> The old asm might work. The changes in the new asm seem specific to
> Linux (and maybe Hurd), where gcc -fstack-protector gets its cookie from
> thread-local storage. This cookie is "uintptr_t stack_guard" in
> glibc [1] and "uintptr_t canary" in musl libc [2]. The same offset in
> OpenBSD <tib.h> "struct tib" doesn't have a cookie.
>
> By my guess, the new asm is also useless on Linux. All threads in one
> process share the same cookie [3]. The new asm to save and restore the
> cookie would have no effect. PowerDNS Recursor with -fstack-protector
> should always have worked with old Boost, including on Linux.
As far as I am aware, Linux has not made the same transition we did
(work by Matthew Dempsky) where the stack-protector is per-DSO. This
means in a simple dynamic program, there are 3 stack-protector cookies:
one each for ld.so, libc.so, main program. In a program like chrome there
would be 30+.
Of course nowadays the most relevant architectures use RETGUARD as a
replacement for the stack-protector, which has up to 4096 cookies per
DSO....
1 cookie for the entire runtime? How archaic.
No comments:
Post a Comment