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]

Re: [PATCH 02/12] Make __stack_chk_fail() not use other glibc facilities.


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).

If people were going to laugh this out of the barn there seemed to be no
point, but if people are receptive, I'm happy to sign.

(I'm in the UK, which unfortunately means, I think, that I'm still
condemned to posting off papers made of real paper.)

> 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.

> 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 :(


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]