This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
| Other format: | [Raw text] | |
On 21 Feb 2016 12:44, Nix wrote:
> On 20 Feb 2016, Mike Frysinger outgrape:
> > On 20 Feb 2016 12:06, Nix wrote:
> >> Magnus Granberg has now pointed me at a much more recent version of this
> >> change, which replaces __chk_fail() to the same end and reimplement
> >> __stack_chk_fail() in terms of it. I'll incorporate that in the next
> >> version. (The only concern is that this has received changes from lots
> >> of people. Maybe I'll have to reimplement it entirely to avoid
> >> copyright-assignment concerns. What a drag...)
> >
> > yes, you will. you (and Oracle) have CLA papers already signed for glibc
> > right ? if not, there isn't much point in following up on this series if
> > you don't plan to.
>
> Oracle has a disclaimer signed, of couse, but I'll need to start the
> copyright papers dance for myself (I have signed papers for other GNU
> projects, but not glibc yet).
a disclaimer is not the same thing as a CLA. what exactly are you
referring to here ?
> > it needs a rewrite anyways to not use INLINE_SYSCALL but INTERNAL_SYSCALL.
> > i had done this locally, stashed it, but then lost it when cleaning up the
> > repo later :(.
>
> Frankly, I was rather hoping that someone could figure out what I
> hadn't yet -- the right way to prevent the intermediate link failing
> when the original __stack_chk_fail() is used.
i haven't looked closely at the loop. i assumed the fail relied on more
printf machinery.
> > all that said, i don't think we want to import the Gentoo one anyways.
> > it changes a lot of behavior that we shouldn't conflate here -- the
> > crash/syslog handling is contentious. maybe something like (untested):
> >
> > void
> > __attribute__ ((noreturn)) internal_function
> > __fortify_fail (const char *msg)
> > {
> > #ifdef __SSP__
> > int fd = -1;
> >
> > const char *on_2 = __libc_secure_getenv ("LIBC_FATAL_STDERR_");
> > if (on_2 == NULL || *on_2 == '\0')
> > fd = open_not_cancel_2 (_PATH_TTY, O_RDWR | O_NOCTTY | O_NDELAY);
>
> I fear this use of open_not_cancel_2() may bring back the same behaviour
> we're trying to avoid :(
if this triggers the loop, then you'll need INTERNAL_SYSCALL. if that
fixes the loop, then we can probably not make it depend on __SSP__ at
all.
-mike
Attachment:
signature.asc
Description: Digital signature
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |