All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Grégoire Sutre" <gregoire.sutre@labri.fr>
To: The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: Non-static variables and nested function pointers [bug #28392]
Date: Sat, 26 Dec 2009 19:43:45 +0100	[thread overview]
Message-ID: <4B365961.8070005@labri.fr> (raw)
In-Reply-To: <20091224221243.GT12122@thorin>

[-- Attachment #1: Type: text/plain, Size: 2576 bytes --]

Robert Millan wrote:
> 
> The following snippet (kern/misc.c) comes to mind:
> 
> #ifdef NEED_ENABLE_EXECUTE_STACK
> /* Some gcc versions generate a call to this function
>    in trampolines for nested functions.  */
> void __enable_execute_stack (void *addr __attribute__ ((unused)))
> {
> }
> #endif

I was away from my email, sorry for the delay.  I hunted this
segfault down in the meantime, and I came to the same
conclusion.  If I remove `grub_CHECK_ENABLE_EXECUTE_STACK' from
configure.ac then the segfault in grub-probe disappear.


> We added this for NetBSD in fact.  In that platform, GCC generates references
> to this function, which are usually satisfied by libc, but we don't link with
> libc, so we made it happy with an empty stub.

Yes, I realized that this was NetBSD specific from the archives of the 
mailing list -- kind of ironic ;-)

On my NetBSD/i386 5.0 system, if I compile the attached example, the 
symbol __enable_execute_stack does indeed appear in the executable 
(according to nm).  This holds for gcc 4.1.3 (the system's default 
compiler) and for gcc 4.4.1.  And the symbol __enable_execute_stack is 
found in libgcc_s.so.1.


> But this is only supposed to happen when building real GRUB.  For util/
> stuff, we should use the libc facility instead.  Maybe that's not the case?

I guess that it's not the case: util programs that are linked with 
kern/misc.c do not use the libc's __enable_execute_stack (if 
NEED_ENABLE_EXECUTE_STACK is defined in config.h).


In case that helps, and to continue the discussion regarding
executable stack on NetBSD, I made a few experiments on i386 and
amd64 on a simplified example (see below).  From what I could
read, NetBSD implements memory protection with PaX.

* NetBSD/i386:

                  | with dummy __enable_execute_stack |
                  |       no        |       yes       |
-----------------+-----------------+-----------------+
PaX MPROTECT off |       ok        |    segfault     |
-----------------+-----------------+-----------------+
PaX MPROTECT on  |    segfault     |    segfault     |
-----------------+-----------------+-----------------+

However, in all four cases, there is no segfault if the variable
j in main is declared static.  And in that case, the generated 
executable does not contain the symbol __enable_execute_stack (according 
to nm).

* NetBSD/amd64: in all four cases, no segfault.

Also, on NetBSD/amd64, the segfault problem I experienced in grub-probe 
completely disappears.

Grégoire

[-- Attachment #2: nested.c --]
[-- Type: text/x-csrc, Size: 513 bytes --]

#include <stdio.h>

#ifdef BAD
/* Some gcc versions generate a call to this function
   in trampolines for nested functions.  */
void __enable_execute_stack (void *addr __attribute__ ((unused)))
{
}
#endif

int apply(void (*hook) (int *))
{
   int a = 0;
   hook(&a);
   hook(&a);
   return a;
}

int main (int argc, char *argv[])
{
   /* static */ int j = 5;
   int res;

   void hook(int *n)
   {
      *n = *n + j;
      j--;
   }

   res = apply(hook);
   printf("result: %d, j=%d\n", res, j);
   return 0;
}

      reply	other threads:[~2009-12-26 18:43 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-23 20:48 Non-static variables and nested function pointers [bug #28392] Grégoire Sutre
2009-12-23 22:17 ` Seth Goldberg
2009-12-24  1:56   ` Grégoire Sutre
2009-12-24  2:07     ` Seth Goldberg
2009-12-24  3:33       ` Grégoire Sutre
2009-12-24  3:50         ` Seth Goldberg
2009-12-24  3:52         ` Seth Goldberg
2009-12-24 22:12   ` Robert Millan
2009-12-26 18:43     ` Grégoire Sutre [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B365961.8070005@labri.fr \
    --to=gregoire.sutre@labri.fr \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.