GRUB2 Build on Mac OS X

GRUB2 Build on Mac OS X

[Andre Smith]

The GRUB2 build fails on Mac OS X, due to non-support of nested  
functions in GCC on OS X. The reasoning behind this, the GCC  
implementation of nested functions uses stack based execution.  
Hackers use buffer overflows, along with stack based execution, to  
exploit weaknesses in poorly written code. Apple has decided to  
disable nested function support until a volunteer has patched GCC  
with a non-stack based implementation of nested functions.

I would like to see the PowerPC port of Open Solaris build on Mac  
hardware. I have been working on patches for the code that uses  
nested functions in the GRUB2 project and I would like get some  
feedback from the list. I would also like to solicit help in testing  
the patches against the official tree for regression testing.

Thanks,
Andre

Re: GRUB2 Build on Mac OS X

[Marco Gerards]

Andre Smith <andre-smith@speakeasy.net> writes:

Hi Andre,

> The GRUB2 build fails on Mac OS X, due to non-support of nested
> functions in GCC on OS X. The reasoning behind this, the GCC
> implementation of nested functions uses stack based execution.
> Hackers use buffer overflows, along with stack based execution, to
> exploit weaknesses in poorly written code. Apple has decided to
> disable nested function support until a volunteer has patched GCC
> with a non-stack based implementation of nested functions.

Right, there has been a discussion about this on the list.

> I would like to see the PowerPC port of Open Solaris build on Mac
> hardware. I have been working on patches for the code that uses
> nested functions in the GRUB2 project and I would like get some
> feedback from the list. I would also like to solicit help in testing
> the patches against the official tree for regression testing.

It's not acceptable to me to just remove the nested functions because
someone broke some unofficial build of gcc.  When an executable stack
is not available, there are the following options (as I see them):

Enable the executable stack using:
1) Set some bit in the ELF file so the OS knows we want this
  (that's what linux does).
2) Enable it using some function.
3) Creating our own stack.

So on the apple nested functions should not cause an error.  Perhaps a
serious warning that the stack is not available and a runtime error.
In that case we can use the fixes above.

So on the apple the right thing to do would be:

1) Fix gcc so nested functions are not fatal.
2) fix GRUB using the methods I described above.

What kind of restrictions does opensolaris have on nested functions?
If it doesn't cause an error, the problem for opensolaris is not that
big.

Thanks,
Marco

Re: GRUB2 Build on Mac OS X

[Andrei Warkentin]

I think the best solution would be to entirely avoid Apple's bundled  
OS X-specific GCC. An powerpc-elf -targetted GCC cross-compiler  
hosted on OS X should be perfect for both OpenSolaris and for GRUB2.

On Dec 8, 2005, at 12:10 AM, Andre Smith wrote:

> The GRUB2 build fails on Mac OS X, due to non-support of nested  
> functions in GCC on OS X. The reasoning behind this, the GCC  
> implementation of nested functions uses stack based execution.  
> Hackers use buffer overflows, along with stack based execution, to  
> exploit weaknesses in poorly written code. Apple has decided to  
> disable nested function support until a volunteer has patched GCC  
> with a non-stack based implementation of nested functions.
>
> I would like to see the PowerPC port of Open Solaris build on Mac  
> hardware. I have been working on patches for the code that uses  
> nested functions in the GRUB2 project and I would like get some  
> feedback from the list. I would also like to solicit help in  
> testing the patches against the official tree for regression testing.
>
> Thanks,
> Andre
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel

Re: GRUB2 Build on Mac OS X

[Peter Jones]

On Thu, 2005-12-08 at 13:26 +0100, Marco Gerards wrote:

> It's not acceptable to me to just remove the nested functions because
> someone broke some unofficial build of gcc.  When an executable stack
> is not available, there are the following options (as I see them):

I could be wrong, but GCC appears not to have official builds.  For any
platform.

That being said, what's the reasoning for using this uncommon and
lossely defined extension in the first place?  The way GRUB (both 2 and
Legacy) uses nested functions, it's no better than just having a method
vector, and certainly not easier to read.   Not only that, but the trend
going forward is towards *less* support of executable stacks, not more.
I wouldn't expect that to stop with us and for Apple, especially now
that there's widespread support for non-executable pages on Intel
hardware.

For that matter, is there a specific intent to use GNU C rather than
ANSI/ISO C?  I haven't extensively read the list archives, so feel free
to point me at them if this has been widely discussed.

Are you saying you don't want Would you be amicable to patches which
change code from using nested functions to a more C-like implementation?
(I don't mean like the patch in my current GRUB Legacy package;
something cleaner than that hacky approach.)

> Enable the executable stack using:
> 1) Set some bit in the ELF file so the OS knows we want this
>   (that's what linux does).
> 2) Enable it using some function.
> 3) Creating our own stack.

There's a major point of contention being ignored here.  OS vendors
don't want to ship executables which require an executable stack.  Full
stop.

> So on the apple the right thing to do would be:
> 
> 1) Fix gcc so nested functions are not fatal.

From many points of view, this would not be "fixing" GCC.

> 2) fix GRUB using the methods I described above.

Likewise.

Currently in RHEL and Fedora Core, we (somewhat kludgedly) fix GRUB not
to need an executable stack for the normal operations that happen during
grub-install.  If we're ever to move to GRUB 2, it'll either need to not
use nested functions, or I'm going to wind up doing the same
modifications to it.

I really hope you're willing to entertain patches that remove use of
nested functions.  If so, I'll certainly put some effort that direction
when next I look at moving RHEL and Fedora to GRUB 2.

-- 
  Peter

Re: GRUB2 Build on Mac OS X

[Yoshinori K. Okuji]

On Thursday 08 December 2005 05:27 pm, Peter Jones wrote:
> That being said, what's the reasoning for using this uncommon and
> lossely defined extension in the first place?

Because it is documented very well in the manual and it makes our development 
easier. If you don't use nested functions, you must pass many arguments 
explicitly. This just bloats the code, and makes code less readable, since 
you often have to pass arguments which are not necessary at the first glance. 
I can say that this is a deficiency in ANSI C.

As you may know, most languages support nested definitions. GCC fixes such a 
bad design. So why not using it?

> For that matter, is there a specific intent to use GNU C rather than
> ANSI/ISO C?  I haven't extensively read the list archives, so feel free
> to point me at them if this has been widely discussed.

Anyway, we need a lot of code specific to GCC besides nested functions. For 
example, how do you define that a structure must be packed? Some extensions 
are necessary for low level programming, because the C standard is too poor.

> There's a major point of contention being ignored here.  OS vendors
> don't want to ship executables which require an executable stack.  Full
> stop.

I'd like to hear your opinion as a distributor about the trend of prohibiting 
executable stacks. For me, it sounds just like a paranoid. I can understand 
it when a program takes input from a different user. However, in the context 
of GRUB, what is the benefit? I haven't heard any good reason behind it so 
far.

Okuji

Re: GRUB2 Build on Mac OS X

[Marco Gerards]

Peter Jones <pjones@redhat.com> writes:

> On Thu, 2005-12-08 at 13:26 +0100, Marco Gerards wrote:
>
>> It's not acceptable to me to just remove the nested functions because
>> someone broke some unofficial build of gcc.  When an executable stack
>> is not available, there are the following options (as I see them):
>
> I could be wrong, but GCC appears not to have official builds.  For any
> platform.

Right, what I meant to say is an official release.  A documented
feature from gcc was simply discarded.

> That being said, what's the reasoning for using this uncommon and
> lossely defined extension in the first place?  The way GRUB (both 2 and
> Legacy) uses nested functions, it's no better than just having a method
> vector, and certainly not easier to read.   Not only that, but the trend
> going forward is towards *less* support of executable stacks, not more.
> I wouldn't expect that to stop with us and for Apple, especially now
> that there's widespread support for non-executable pages on Intel
> hardware.
>
> For that matter, is there a specific intent to use GNU C rather than
> ANSI/ISO C?  I haven't extensively read the list archives, so feel free
> to point me at them if this has been widely discussed.

It's a GNU feature, GRUB is a GNU project.  And it is widely used in
GRUB 2, we like GNU99 (or at least I do).  So if you are looking at
this from that perspective, it is not that uncommon or weird at all.

> Are you saying you don't want Would you be amicable to patches which
> change code from using nested functions to a more C-like implementation?
> (I don't mean like the patch in my current GRUB Legacy package;
> something cleaner than that hacky approach.)

Right.  If there is no good reason for such thing (some random gcc
hack isn't a good reason for me), I see no reason to change it.

>> Enable the executable stack using:
>> 1) Set some bit in the ELF file so the OS knows we want this
>>   (that's what linux does).
>> 2) Enable it using some function.
>> 3) Creating our own stack.
>
> There's a major point of contention being ignored here.  OS vendors
> don't want to ship executables which require an executable stack.  Full
> stop.

Please give me one good reason why GRUB shouldn't use an executable
stack.  I don't see a good reason besides the more general "We don't
want to have executable stacks at all".

>> So on the apple the right thing to do would be:
>> 
>> 1) Fix gcc so nested functions are not fatal.
>
>>From many points of view, this would not be "fixing" GCC.
>
>> 2) fix GRUB using the methods I described above.
>
> Likewise.

Why wouldn't it be?

Anyways, it would be nice if gcc could support nested functions by
using something else than an executable stack.

Thanks,
Marco

Re: GRUB2 Build on Mac OS X

[Andrei Warkentin]

Hello,

There is another issue with GRUB2 on OS X which I am not sure has  
been brought up yet.
Right now, AFAIK (but I haven't tested it), GRUB2 (the part that runs  
from OpenFrimware) can be built
with a bootstrap powerpc-elf-targetted GCC hosted on OS X. However,  
the local GRUB2 binary (one that can run
from OS X and perform installation and some such) needs to be  
compiled with the OS X compiler. Why? OS X doesn't use ELF -
it uses Mach-O. If you want to be able to build GRUB2 in OS X with  
purely the OS X GCC, then the build procedure must take into account  
the Mach-O
output format. AFAIK, new OpenFirmware versions (3.x) can boot Mach-O  
binaries but I haven't had a chance to experiment with this yet.

On Dec 8, 2005, at 10:27 AM, Peter Jones wrote:

> On Thu, 2005-12-08 at 13:26 +0100, Marco Gerards wrote:
>
>> It's not acceptable to me to just remove the nested functions because
>> someone broke some unofficial build of gcc.  When an executable stack
>> is not available, there are the following options (as I see them):
>
> I could be wrong, but GCC appears not to have official builds.  For  
> any
> platform.
>
> That being said, what's the reasoning for using this uncommon and
> lossely defined extension in the first place?  The way GRUB (both 2  
> and
> Legacy) uses nested functions, it's no better than just having a  
> method
> vector, and certainly not easier to read.   Not only that, but the  
> trend
> going forward is towards *less* support of executable stacks, not  
> more.
> I wouldn't expect that to stop with us and for Apple, especially now
> that there's widespread support for non-executable pages on Intel
> hardware.
>
> For that matter, is there a specific intent to use GNU C rather than
> ANSI/ISO C?  I haven't extensively read the list archives, so feel  
> free
> to point me at them if this has been widely discussed.
>
> Are you saying you don't want Would you be amicable to patches which
> change code from using nested functions to a more C-like  
> implementation?
> (I don't mean like the patch in my current GRUB Legacy package;
> something cleaner than that hacky approach.)
>
>> Enable the executable stack using:
>> 1) Set some bit in the ELF file so the OS knows we want this
>>   (that's what linux does).
>> 2) Enable it using some function.
>> 3) Creating our own stack.
>
> There's a major point of contention being ignored here.  OS vendors
> don't want to ship executables which require an executable stack.   
> Full
> stop.
>
>> So on the apple the right thing to do would be:
>>
>> 1) Fix gcc so nested functions are not fatal.
>
>> From many points of view, this would not be "fixing" GCC.
>
>> 2) fix GRUB using the methods I described above.
>
> Likewise.
>
> Currently in RHEL and Fedora Core, we (somewhat kludgedly) fix GRUB  
> not
> to need an executable stack for the normal operations that happen  
> during
> grub-install.  If we're ever to move to GRUB 2, it'll either need  
> to not
> use nested functions, or I'm going to wind up doing the same
> modifications to it.
>
> I really hope you're willing to entertain patches that remove use of
> nested functions.  If so, I'll certainly put some effort that  
> direction
> when next I look at moving RHEL and Fedora to GRUB 2.
>
> -- 
>   Peter
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel

Re: GRUB2 Build on Mac OS X

[Marco Gerards]

Andrei Warkentin <andrey.warkentin@gmail.com> writes:

Hi Andrei,

> There is another issue with GRUB2 on OS X which I am not sure has
> been brought up yet.
> Right now, AFAIK (but I haven't tested it), GRUB2 (the part that runs
> from OpenFrimware) can be built
> with a bootstrap powerpc-elf-targetted GCC hosted on OS X. However,
> the local GRUB2 binary (one that can run
> from OS X and perform installation and some such) needs to be
> compiled with the OS X compiler. Why? OS X doesn't use ELF -
> it uses Mach-O. If you want to be able to build GRUB2 in OS X with
> purely the OS X GCC, then the build procedure must take into account
> the Mach-O
> output format. AFAIK, new OpenFirmware versions (3.x) can boot Mach-O
> binaries but I haven't had a chance to experiment with this yet.

You mean the utilities like grub-setup, grub-mkimage, grub-emu, etc?
They should be able to run on macos, right?  Of perhaps I am missing
your point.

If those utilities can be build in a better way so nothing breaks and
it will work on macos, I am quite interested in hearing how to solve
that.

Mach-O binaries for booting is a different subject.  We rely on ELF
files, grub-mkimage even creates ELF files and uses ELF load
segments.  Without it GRUB just won't work, unless grub-mkimage is
changed intensively.  So it seems easier just to use ELFs in any case.

--
Marco

Re: GRUB2 Build on Mac OS X

[Andrei Warkentin]

I understand (still had my mind on GRUB 1 :)) - then looks like two  
GCC installations will be
required to construct GRUB2 on OS X - one to generate OS X-hosted  
GRUB utilities (which will
be Mach-O files), and one to generate ELF files  that will be used in  
the booting process.

On Dec 8, 2005, at 2:00 PM, Marco Gerards wrote:

> Andrei Warkentin <andrey.warkentin@gmail.com> writes:
>
> Hi Andrei,
>
>> There is another issue with GRUB2 on OS X which I am not sure has
>> been brought up yet.
>> Right now, AFAIK (but I haven't tested it), GRUB2 (the part that runs
>> from OpenFrimware) can be built
>> with a bootstrap powerpc-elf-targetted GCC hosted on OS X. However,
>> the local GRUB2 binary (one that can run
>> from OS X and perform installation and some such) needs to be
>> compiled with the OS X compiler. Why? OS X doesn't use ELF -
>> it uses Mach-O. If you want to be able to build GRUB2 in OS X with
>> purely the OS X GCC, then the build procedure must take into account
>> the Mach-O
>> output format. AFAIK, new OpenFirmware versions (3.x) can boot Mach-O
>> binaries but I haven't had a chance to experiment with this yet.
>
> You mean the utilities like grub-setup, grub-mkimage, grub-emu, etc?
> They should be able to run on macos, right?  Of perhaps I am missing
> your point.
>
> If those utilities can be build in a better way so nothing breaks and
> it will work on macos, I am quite interested in hearing how to solve
> that.
>
> Mach-O binaries for booting is a different subject.  We rely on ELF
> files, grub-mkimage even creates ELF files and uses ELF load
> segments.  Without it GRUB just won't work, unless grub-mkimage is
> changed intensively.  So it seems easier just to use ELFs in any case.
>
> --
> Marco
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel

Re: GRUB2 Build on Mac OS X

[Marco Gerards]

Andrei Warkentin <andrey.warkentin@gmail.com> writes:

> I understand (still had my mind on GRUB 1 :)) - then looks like two
> GCC installations will be
> required to construct GRUB2 on OS X - one to generate OS X-hosted
> GRUB utilities (which will
> be Mach-O files), and one to generate ELF files  that will be used in
> the booting process.

I think it would be possible to do both in one time.  Which parameters
did you pass to configure?

--
Marco

Re: GRUB2 Build on Mac OS X

[Andrei Warkentin]

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

Hmm, I just tried ./configure-ing.

I have my powerpc-linux crosscompiler tools as powerpc-linux-{gcc,  
ld, ar, objcopy, etc}.
It seems the configuration utility makes no distinction between  
compiler toolchain to make system utilities and compiler chain to  
make bootable executables.
Naturally, this being OS X, the powerpc-linux-gcc is a simple  
bootstrap compiler and cannot make "normal" executables (not that  
Linux PowerPC-ELF would be of any use on OS X).

./configure --host powerpc-linux resulted in -
configure: WARNING: If you wanted to set the --build type, don't use  
--host.
     If a cross compiler is detected then cross compile mode will be  
used.
checking build system type... powerpc-apple-darwin8.3.0
checking host system type... powerpc-unknown-linux-gnu
checking for powerpc-linux-gcc... powerpc-linux-gcc
checking for C compiler default output file name... configure: error:  
C compiler cannot create executables
See `config.log' for more details.

With config log:
hostname = Uruz.local
uname -m = Power Macintosh
uname -r = 8.3.0
uname -s = Darwin
uname -v = Darwin Kernel Version 8.3.0: Mon Oct  3 20:04:04 PDT 2005;  
root:xnu-792.6.22.obj~2/RELEASE_PPC

/usr/bin/uname -p = powerpc
/bin/uname -X     = unknown

/bin/arch              = unknown
/usr/bin/arch -k       = unknown
/usr/convex/getsysinfo = unknown
hostinfo               = Mach kernel version:
          Darwin Kernel Version 8.3.0: Mon Oct  3 20:04:04 PDT 2005;  
root:xnu-792.6.22.obj~2/RELEASE_PPC
Kernel configured for a single processor only.
1 processor is physically available.
Processor type: ppc7450 (PowerPC 7450)
Processor active: 0
Primary memory available: 512.00 megabytes
Default processor set: 58 tasks, 181 threads, 1 processors
Load average: 1.73, Mach factor: 0.45
/bin/machine           = unknown
/usr/bin/oslevel       = unknown
/bin/universe          = unknown

PATH: .
PATH: /sw/bin
PATH: /sw/sbin
PATH: /Users/andreywarkentin/crossdev/i686-linux/bin
PATH: /Users/andreywarkentin/crossdev/powerpc-linux/bin
PATH: /bin
PATH: /sbin
PATH: /usr/bin
PATH: /usr/sbin
PATH: /usr/X11R6/bin


## ----------- ##
## Core tests. ##
## ----------- ##

configure:1348: checking build system type
configure:1366: result: powerpc-apple-darwin8.3.0
configure:1374: checking host system type
configure:1388: result: powerpc-unknown-linux-gnu
configure:1432: checking for powerpc-linux-gcc
configure:1448: found /Users/andreywarkentin/crossdev/powerpc-linux/ 
bin/powerpc-linux-gcc
configure:1458: result: powerpc-linux-gcc
configure:1740: checking for C compiler version
configure:1743: powerpc-linux-gcc --version </dev/null >&5
powerpc-linux-gcc (GCC) 4.0.2
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There  
is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR  
PURPOSE.

configure:1746: $? = 0
configure:1748: powerpc-linux-gcc -v </dev/null >&5
Using built-in specs.
Target: powerpc-linux
Configured with: ../gcc-4.0.2/configure --target=powerpc-linux -- 
prefix=/Users/andreywarkentin/crossdev/powerpc-linux --disable-shared  
--disable-threads --enable-languages=c,c++ --with-newlib
Thread model: single
gcc version 4.0.2
configure:1751: $? = 0
configure:1753: powerpc-linux-gcc -V </dev/null >&5
powerpc-linux-gcc: '-V' option must have argument
configure:1756: $? = 1
configure:1779: checking for C compiler default output file name
configure:1782: powerpc-linux-gcc    conftest.c  >&5
/Users/andreywarkentin/crossdev/powerpc-linux/lib/gcc/powerpc-linux/ 
4.0.2/../../../../powerpc-linux/bin/ld: crt1.o: No such file: No such  
file or directory
collect2: ld returned 1 exit status
configure:1785: $? = 1
configure: failed program was:
| /* confdefs.h.  */
|
| #define PACKAGE_NAME "GRUB"
| #define PACKAGE_TARNAME "grub"
| #define PACKAGE_VERSION "1.91"
| #define PACKAGE_STRING "GRUB 1.91"
| #define PACKAGE_BUGREPORT "bug-grub@gnu.org"
| /* end confdefs.h.  */
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }
configure:1824: error: C compiler cannot create executables
See `config.log' for more details.

## ---------------- ##
## Cache variables. ##
## ---------------- ##

ac_cv_build=powerpc-apple-darwin8.3.0
ac_cv_build_alias=powerpc-apple-darwin8.3.0
ac_cv_env_CC_set=
ac_cv_env_CC_value=
ac_cv_env_CFLAGS_set=
ac_cv_env_CFLAGS_value=
ac_cv_env_CPPFLAGS_set=
ac_cv_env_CPPFLAGS_value=
ac_cv_env_CPP_set=
ac_cv_env_CPP_value=
ac_cv_env_LDFLAGS_set=
ac_cv_env_LDFLAGS_value=
ac_cv_env_build_alias_set=
ac_cv_env_build_alias_value=
ac_cv_env_host_alias_set=set
ac_cv_env_host_alias_value=powerpc-linux
ac_cv_env_target_alias_set=
ac_cv_env_target_alias_value=
ac_cv_host=powerpc-unknown-linux-gnu
ac_cv_host_alias=powerpc-linux
ac_cv_prog_CC=powerpc-linux-gcc

## ----------------- ##
## Output variables. ##
## ----------------- ##

BUILD_CC=''
CC='powerpc-linux-gcc'
CFLAGS=''
CPP=''
CPPFLAGS=''
DEFS=''
ECHO_C=''
ECHO_N='-n'
ECHO_T=''
EGREP=''
EXEEXT=''
INSTALL_DATA=''
INSTALL_PROGRAM=''
INSTALL_SCRIPT=''
LD=''
LDFLAGS=''
LIBCURSES=''
LIBLZO=''
LIBOBJS=''
LIBS=''
LTLIBOBJS=''
NM=''
OBJCOPY=''
OBJEXT=''
PACKAGE_BUGREPORT='bug-grub@gnu.org'
PACKAGE_NAME='GRUB'
PACKAGE_STRING='GRUB 1.91'
PACKAGE_TARNAME='grub'
PACKAGE_VERSION='1.91'
PATH_SEPARATOR=':'
RUBY=''
SET_MAKE=''
SHELL='/bin/sh'
STRIP=''
YACC=''
ac_ct_CC=''
ac_ct_LD=''
ac_ct_NM=''
ac_ct_OBJCOPY=''
ac_ct_STRIP=''
bindir='${exec_prefix}/bin'
build='powerpc-apple-darwin8.3.0'
build_alias=''
build_cpu='powerpc'
build_os='darwin8.3.0'
build_vendor='apple'
datadir='${prefix}/share'
exec_prefix='NONE'
host='powerpc-unknown-linux-gnu'
host_alias='powerpc-linux'
host_cpu='powerpc'
host_os='linux-gnu'
host_vendor='ieee1275'
includedir='${prefix}/include'
infodir='${prefix}/info'
libdir='${exec_prefix}/lib'
libexecdir='${exec_prefix}/libexec'
localstatedir='${prefix}/var'
mandir='${prefix}/man'
oldincludedir='/usr/include'
prefix='NONE'
program_transform_name='s,x,x,'
sbindir='${exec_prefix}/sbin'
sharedstatedir='${prefix}/com'
sysconfdir='${prefix}/etc'
target_alias=''

## ----------- ##
## confdefs.h. ##
## ----------- ##

#define PACKAGE_BUGREPORT "bug-grub@gnu.org"
#define PACKAGE_NAME "GRUB"
#define PACKAGE_STRING "GRUB 1.91"
#define PACKAGE_TARNAME "grub"
#define PACKAGE_VERSION "1.91"

configure: exit 77


On Dec 8, 2005, at 2:14 PM, Marco Gerards wrote:

> Andrei Warkentin <andrey.warkentin@gmail.com> writes:
>
>> I understand (still had my mind on GRUB 1 :)) - then looks like two
>> GCC installations will be
>> required to construct GRUB2 on OS X - one to generate OS X-hosted
>> GRUB utilities (which will
>> be Mach-O files), and one to generate ELF files  that will be used in
>> the booting process.
>
> I think it would be possible to do both in one time.  Which parameters
> did you pass to configure?
>
> --
> Marco
>
>
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel


[-- Attachment #2: Type: text/html, Size: 12806 bytes --]

Re: GRUB2 Build on Mac OS X

[andre-smith]

The Mac OS X GCC compiler will not build GRUB2, due static linking at address 0x2000; this error can be confirmed during the configure process. If I could build GRUB2 using the Mac OS X GCC, I would be able to build GRUB2 images from Mac OS X.

The binary I attempted the build using the cross compiler tool chain powerpc-elf, would have executed on PowerPC Linux, but I would not build due to the nested function support being disabled in the Apple GCC.

Since the GRUB2 tools built using a Linux GCC compiler will suffice at the moment, I can see why the team is not overly concerned with this issue. If GRUB2 is going to be portable(Mac OS X), then some changes will be needed to accomplish this goal.

If stack execution support is disabled in future releases of other operating systems, it will become an issue of nested functions implemented with stack execution, and less of an Apple GCC compiler issue.

I do agree that more arguments will be needed on function calls if nested functions are not going to be used, if the list is willing to accept patches to address this issue.

As far as the GRUB2 tools, binaries executed on the PowerPC platform only need to be pure ELF. I am not sure if creating Mach-O boot binaries will yield any benefits for bringing up a kernel. If GRUB2 is to be used on the Mac OS X operating system, the tools need to be Mach-O based.

Andre

> -----Original Message-----
> From: Andrei Warkentin [mailto:andrey.warkentin@gmail.com]
> Sent: Thursday, December 8, 2005 08:10 PM
> To: 'The development of GRUB 2'
> Subject: Re: GRUB2 Build on Mac OS X
>
> I understand (still had my mind on GRUB 1 :)) - then looks like two
> GCC installations will be
> required to construct GRUB2 on OS X - one to generate OS X-hosted
> GRUB utilities (which will
> be Mach-O files), and one to generate ELF files  that will be used in  
> the booting process.
>
> On Dec 8, 2005, at 2:00 PM, Marco Gerards wrote:
>
> > Andrei Warkentin <andrey.warkentin@gmail.com> writes:
> >
> > Hi Andrei,
> >
> >> There is another issue with GRUB2 on OS X which I am not sure has
> >> been brought up yet.
> >> Right now, AFAIK (but I haven't tested it), GRUB2 (the part that runs
> >> from OpenFrimware) can be built
> >> with a bootstrap powerpc-elf-targetted GCC hosted on OS X. However,
> >> the local GRUB2 binary (one that can run
> >> from OS X and perform installation and some such) needs to be
> >> compiled with the OS X compiler. Why? OS X doesn't use ELF -
> >> it uses Mach-O. If you want to be able to build GRUB2 in OS X with
> >> purely the OS X GCC, then the build procedure must take into account
> >> the Mach-O
> >> output format. AFAIK, new OpenFirmware versions (3.x) can boot Mach-O
> >> binaries but I haven't had a chance to experiment with this yet.
> >
> > You mean the utilities like grub-setup, grub-mkimage, grub-emu, etc?
> > They should be able to run on macos, right?  Of perhaps I am missing
> > your point.
> >
> > If those utilities can be build in a better way so nothing breaks and
> > it will work on macos, I am quite interested in hearing how to solve
> > that.
> >
> > Mach-O binaries for booting is a different subject.  We rely on ELF
> > files, grub-mkimage even creates ELF files and uses ELF load
> > segments.  Without it GRUB just won't work, unless grub-mkimage is
> > changed intensively.  So it seems easier just to use ELFs in any case.
> >
> > --
> > Marco
> >
> >
> >
> > _______________________________________________
> > Grub-devel mailing list
> > Grub-devel@gnu.org
> > http://lists.gnu.org/mailman/listinfo/grub-devel
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>

Re: GRUB2 Build on Mac OS X

[Andrei Warkentin]

On Dec 8, 2005, at 4:01 PM, andre-smith@speakeasy.net wrote:

> The Mac OS X GCC compiler will not build GRUB2, due static linking  
> at address 0x2000; this error can be confirmed during the configure  
> process. If I could build GRUB2 using the Mac OS X GCC, I would be  
> able to build GRUB2 images from Mac OS X.

The OS X ld is not the GNU linker - so sure it can't link at 0x2000,  
it doesn't know what -T means. You would probably use some  
permutation of the -segaddr option. Moreover, OS X uses the Mach-O  
binary format, not ELF...

>
> The binary I attempted the build using the cross compiler tool  
> chain powerpc-elf, would have executed on PowerPC Linux, but I  
> would not build due to the nested function support being disabled  
> in the Apple GCC

I don't think I understand - you can build a bootstrap GCC targetted  
at powerpc-linux, from the sources obtained via official GNU ftp.  
There would not be any restrictions there... This would allow you to  
build powerpc-elf binaries needed by OF.

>
> Since the GRUB2 tools built using a Linux GCC compiler will suffice  
> at the moment, I can see why the team is not overly concerned with  
> this issue. If GRUB2 is going to be portable(Mac OS X), then some  
> changes will be needed to accomplish this goal.

I think it would be an interesting idea to allow the use of different  
toolsets to produce the boot-time files and the system utilities.  
This way, the boot-time stuff can be build as powerpc-elf, while the  
OS X system utilities can be built as Mach-O (well, not 'can' -  
should, there is no other way here).

>
> If stack execution support is disabled in future releases of other  
> operating systems, it will become an issue of nested functions  
> implemented with stack execution, and less of an Apple GCC compiler  
> issue.
>
> I do agree that more arguments will be needed on function calls if  
> nested functions are not going to be used, if the list is willing  
> to accept patches to address this issue.
>
> As far as the GRUB2 tools, binaries executed on the PowerPC  
> platform only need to be pure ELF. I am not sure if creating Mach-O  
> boot binaries will yield any benefits for bringing up a kernel. If  
> GRUB2 is to be used on the Mac OS X operating system, the tools  
> need to be Mach-O based.
>
> Andre
>
>> -----Original Message-----
>> From: Andrei Warkentin [mailto:andrey.warkentin@gmail.com]
>> Sent: Thursday, December 8, 2005 08:10 PM
>> To: 'The development of GRUB 2'
>> Subject: Re: GRUB2 Build on Mac OS X
>>
>> I understand (still had my mind on GRUB 1 :)) - then looks like two
>> GCC installations will be
>> required to construct GRUB2 on OS X - one to generate OS X-hosted
>> GRUB utilities (which will
>> be Mach-O files), and one to generate ELF files  that will be used in
>> the booting process.
>>
>> On Dec 8, 2005, at 2:00 PM, Marco Gerards wrote:
>>
>>> Andrei Warkentin <andrey.warkentin@gmail.com> writes:
>>>
>>> Hi Andrei,
>>>
>>>> There is another issue with GRUB2 on OS X which I am not sure has
>>>> been brought up yet.
>>>> Right now, AFAIK (but I haven't tested it), GRUB2 (the part that  
>>>> runs
>>>> from OpenFrimware) can be built
>>>> with a bootstrap powerpc-elf-targetted GCC hosted on OS X. However,
>>>> the local GRUB2 binary (one that can run
>>>> from OS X and perform installation and some such) needs to be
>>>> compiled with the OS X compiler. Why? OS X doesn't use ELF -
>>>> it uses Mach-O. If you want to be able to build GRUB2 in OS X with
>>>> purely the OS X GCC, then the build procedure must take into  
>>>> account
>>>> the Mach-O
>>>> output format. AFAIK, new OpenFirmware versions (3.x) can boot  
>>>> Mach-O
>>>> binaries but I haven't had a chance to experiment with this yet.
>>>
>>> You mean the utilities like grub-setup, grub-mkimage, grub-emu, etc?
>>> They should be able to run on macos, right?  Of perhaps I am missing
>>> your point.
>>>
>>> If those utilities can be build in a better way so nothing breaks  
>>> and
>>> it will work on macos, I am quite interested in hearing how to solve
>>> that.
>>>
>>> Mach-O binaries for booting is a different subject.  We rely on ELF
>>> files, grub-mkimage even creates ELF files and uses ELF load
>>> segments.  Without it GRUB just won't work, unless grub-mkimage is
>>> changed intensively.  So it seems easier just to use ELFs in any  
>>> case.
>>>
>>> --
>>> Marco
>>>
>>>
>>>
>>> _______________________________________________
>>> Grub-devel mailing list
>>> Grub-devel@gnu.org
>>> http://lists.gnu.org/mailman/listinfo/grub-devel
>>
>>
>>
>> _______________________________________________
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> http://lists.gnu.org/mailman/listinfo/grub-devel
>>
>
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel

Re: GRUB2 Build on Mac OS X

[Andrei Warkentin]

Aside from compiling/linking issues, there is another thing to keep  
in mind should there ever be a port of bootable GRUB2 parts to OF/ 
Mach-O. OS X uses a different calling convention, so any assembly  
bits would have to be properly adjusted.

I still think the best solution here would be to compile the bootable  
parts with a crosscompiler as PowerPC ELF, while compiling the system  
utilities with the stock Apple GCC and native LD (and associate  
frameworks) as Mach-O. 

Re: GRUB2 Build on Mac OS X

[Peter Jones]

On Thu, 2005-12-08 at 19:25 +0100, Yoshinori K. Okuji wrote:

> > There's a major point of contention being ignored here.  OS vendors
> > don't want to ship executables which require an executable stack.  Full
> > stop.
> 
> I'd like to hear your opinion as a distributor about the trend of prohibiting 
> executable stacks. For me, it sounds just like a paranoid. I can understand 
> it when a program takes input from a different user. However, in the context 
> of GRUB, what is the benefit? I haven't heard any good reason behind it so 
> far.

It used to be that everybody assumed all their programs were well
behaved, and that we could simply fix bugs when we found them, and
that's good enough.  That's the approach you're taking here, although it
is somewhat implicit.  What you're saying is that grub isn't setuid, so
if there are bugs in it which would be exploitable in a setuid program,
we don't need to worry.

Everybody used to take that approach.  As a vendor, we've done a lot of
work on security in the kernel, the compilers, libc, and elsewhere, and
the conclusion we've come to is that in several ways this approach is
outright wrong.  What happens is that some program which is setuid calls
your program, and it inadvertently passes some used specified data along
that it shouldn't, or accidentally picks up some data from a side
channel that the user has access to.  Then, some sysadmin has a really
bad day, because his boxes get rooted.

Now, obviously, we can't plan on getting rid of all bugs before anybody
notices them, though we'll remain diligent and trying to do so.  But
what we *can* do, which is actually significantly more effective, is to
identify classes of bugs that can be transformed from being showstoppers
to being relatively innocuous -- not necessarily that they can't cause
harm, but that it's very difficult for somebody to plan on what that
harm would be.  You no doubt get where I'm going with this.  The vast
majority of exploits these days are buffer overruns.  It's hard to find
all of the problem code, and it'll probably never happen (though we've
added some tools to gcc to identify some).  But making it so that if
somebody finds a buffer that's not checked properly, they can't *do*
anything with it is now *easy*.

Since widespread hardware support for non-executable pages has started
to occur, we've started fixing any programs we ship that have executable
stacks.  And the result is pretty massive.  On machines with the
capability to enforce it, RHEL has been vulnerable to an overwhelmingly
smaller number of attacks.  We're sure there are more lurking that are
very hard to find, because the programs that directly accept input
aren't necessarily the vulnerable ones.

Now, the obvious retort to this is that no setuid programs are calling
grub, so it's not even one of those cases.  That's not a good answer
either.  I've got one I'd really *like* to call grub from, and it is
pm-hibernate, through consolehelper, and they both accept some degree of
user input from whoever's logged in on the console.

I'd really like to make it so that if somebody has 2 kernels installed,
boots the non-default one, hibernates their laptop, and unsuspends
without paying attention, it doesn't die a horrible death.  The most
obvious way to do that is to make pm-hibernate set the next-boot device
to the currently running one.

From our point of view, if grub has an executable stack, we can't do
that, because we'd be introducing the type of scenario which we already
know has an extremely large number of unpredictable security
implications.

Sorry about replying with a small novel.
-- 
  Peter

Re: GRUB2 Build on Mac OS X

[Marco Gerards]

Andrei Warkentin <andrey.warkentin@gmail.com> writes:

> On Dec 8, 2005, at 4:01 PM, andre-smith@speakeasy.net wrote:
>
>> The Mac OS X GCC compiler will not build GRUB2, due static linking
>> at address 0x2000; this error can be confirmed during the configure
>> process. If I could build GRUB2 using the Mac OS X GCC, I would be
>> able to build GRUB2 images from Mac OS X.
>
> The OS X ld is not the GNU linker - so sure it can't link at 0x2000,
> it doesn't know what -T means. You would probably use some
> permutation of the -segaddr option. Moreover, OS X uses the Mach-O
> binary format, not ELF...

As I explained before only ELF can be used.

>> The binary I attempted the build using the cross compiler tool
>> chain powerpc-elf, would have executed on PowerPC Linux, but I
>> would not build due to the nested function support being disabled
>> in the Apple GCC
>
> I don't think I understand - you can build a bootstrap GCC targetted
> at powerpc-linux, from the sources obtained via official GNU ftp.
> There would not be any restrictions there... This would allow you to
> build powerpc-elf binaries needed by OF.
>
>>
>> Since the GRUB2 tools built using a Linux GCC compiler will suffice
>> at the moment, I can see why the team is not overly concerned with
>> this issue. If GRUB2 is going to be portable(Mac OS X), then some
>> changes will be needed to accomplish this goal.
>
> I think it would be an interesting idea to allow the use of different
> toolsets to produce the boot-time files and the system utilities.
> This way, the boot-time stuff can be build as powerpc-elf, while the
> OS X system utilities can be built as Mach-O (well, not 'can' -
> should, there is no other way here).

This is possible already.  For example when I crosscompile GRUB on my
x86 I get grub-mkimage as x86 tools and grubof as a PPC ELF.  Perhaps
it doesn't build Mach-O yet, but that is something that can be fixed.

--
Marco

Re: GRUB2 Build on Mac OS X

[Marco Gerards]

andre-smith@speakeasy.net writes:

> Since the GRUB2 tools built using a Linux GCC compiler will suffice at
> the moment, I can see why the team is not overly concerned with this
> issue. If GRUB2 is going to be portable(Mac OS X), then some changes
> will be needed to accomplish this goal.

GCC is a GNU project, not a Linux project...

Hopefully you understand we can't always fix things other people
deliberately break.  And what is more important to me is that we need
a solid and stable codebase first, one that most regular contributors
are happy with.

> If stack execution support is disabled in future releases of other
> operating systems, it will become an issue of nested functions
> implemented with stack execution, and less of an Apple GCC compiler
> issue.

In that case we should figure out how to fix this.  But apple didn't
just disable the execution on the stack, they fucked up the compiler.

--
Marco

Re: GRUB2 Build on Mac OS X

[Hollis Blanchard]

On Thursday 08 December 2005 10:27, Peter Jones wrote:
>
> That being said, what's the reasoning for using this uncommon and
> lossely defined extension in the first place?  The way GRUB (both 2 and
> Legacy) uses nested functions, it's no better than just having a method
> vector, and certainly not easier to read.

I do find nested functions very easy to read...

What do you mean by "method vector"?

> Not only that, but the trend 
> going forward is towards *less* support of executable stacks, not more.
> I wouldn't expect that to stop with us and for Apple, especially now
> that there's widespread support for non-executable pages on Intel
> hardware.

Yes, this is definitely a problem.

> Would you be amicable to patches which
> change code from using nested functions to a more C-like implementation?
> (I don't mean like the patch in my current GRUB Legacy package;
> something cleaner than that hacky approach.)

Do you have any specific ideas? I'm very interested, but I honestly don't know 
how it could be done (other than the method you described of creating custom 
structs and passing pointers to those).

> > Enable the executable stack using:
> > 1) Set some bit in the ELF file so the OS knows we want this
> >   (that's what linux does).
> > 2) Enable it using some function.
> > 3) Creating our own stack.
>
> There's a major point of contention being ignored here.  OS vendors
> don't want to ship executables which require an executable stack.  Full
> stop.

Would be alright if we could enable execute permission only on the specific 
pages needed (as known by GCC)? GCC provides an ENABLE_EXECUTE_STACK macro, 
but it seems that is not currently used on Linux. It is used on the various 
BSDs.

> Currently in RHEL and Fedora Core, we (somewhat kludgedly) fix GRUB not
> to need an executable stack for the normal operations that happen during
> grub-install.  If we're ever to move to GRUB 2, it'll either need to not
> use nested functions, or I'm going to wind up doing the same
> modifications to it.
>
> I really hope you're willing to entertain patches that remove use of
> nested functions.  If so, I'll certainly put some effort that direction
> when next I look at moving RHEL and Fedora to GRUB 2.

I am willing to entertain them.

Marco found a nice description from Roland McGrath on this subject: 
https://www.redhat.com/archives/fedora-devel-list/2003-November/msg00838.html

His only suggestions for nested functions were a) do not use function pointers 
with them, or b) rewrite them entirely.

-Hollis

Re: GRUB2 Build on Mac OS X

[Peter Jones]

On Fri, 2005-12-09 at 16:49 -0600, Hollis Blanchard wrote:
> On Thursday 08 December 2005 10:27, Peter Jones wrote:
> >
> > That being said, what's the reasoning for using this uncommon and
> > lossely defined extension in the first place?  The way GRUB (both 2 and
> > Legacy) uses nested functions, it's no better than just having a method
> > vector, and certainly not easier to read.
> 
> I do find nested functions very easy to read...
> 
> What do you mean by "method vector"?

Something along the lines of linux's "struct file_operations".

> > Would you be amicable to patches which
> > change code from using nested functions to a more C-like implementation?
> > (I don't mean like the patch in my current GRUB Legacy package;
> > something cleaner than that hacky approach.)
> 
> Do you have any specific ideas? I'm very interested, but I honestly don't know 
> how it could be done (other than the method you described of creating custom 
> structs and passing pointers to those).

Why other than that?  It works very cleanly in a great many programs...

> > > Enable the executable stack using:
> > > 1) Set some bit in the ELF file so the OS knows we want this
> > >   (that's what linux does).
> > > 2) Enable it using some function.
> > > 3) Creating our own stack.
> >
> > There's a major point of contention being ignored here.  OS vendors
> > don't want to ship executables which require an executable stack.  Full
> > stop.
> 
> Would be alright if we could enable execute permission only on the specific 
> pages needed (as known by GCC)? GCC provides an ENABLE_EXECUTE_STACK macro, 
> but it seems that is not currently used on Linux. It is used on the various 
> BSDs.

It would be functional, but again we'd have security concerns.

Sure, we're maybe being a little paranoid, but "they" really are out to
get us, and being paranoid has worked very well for us so far.

-- 
  Peter

Re: GRUB2 Build on Mac OS X

[Marco Gerards]

Hollis Blanchard <hollis@penguinppc.org> writes:

>> I really hope you're willing to entertain patches that remove use of
>> nested functions.  If so, I'll certainly put some effort that direction
>> when next I look at moving RHEL and Fedora to GRUB 2.
>
> I am willing to entertain them.
>
> Marco found a nice description from Roland McGrath on this subject: 
> https://www.redhat.com/archives/fedora-devel-list/2003-November/msg00838.html
>
> His only suggestions for nested functions were a) do not use function pointers 
> with them, or b) rewrite them entirely.

Entertain them?

Anyways, removing nested functions is not something I want to do.  But
we could have a case to case look if it would be possible to not use
local variables without making the code obscure.  I assume we can find
all of the locations by having a look at some errors or warnings,
perhaps those from the compile log that was sent in.  But I still
prefer having a sane solution to make it work.

The apple specific case won't be fixed this way.  But I can not help
that apple disabled this feature while it doesn't even rely on an
executable stack in all cases.

--
Marco

Re: GRUB2 Build on Mac OS X

[Marco Gerards]

Peter Jones <pjones@redhat.com> writes:

>> Would be alright if we could enable execute permission only on the specific 
>> pages needed (as known by GCC)? GCC provides an ENABLE_EXECUTE_STACK macro, 
>> but it seems that is not currently used on Linux. It is used on the various 
>> BSDs.
>
> It would be functional, but again we'd have security concerns.
>
> Sure, we're maybe being a little paranoid, but "they" really are out to
> get us, and being paranoid has worked very well for us so far.

Wouldn't it be possible to use some other memory than the stack to
implement trampolines?  It's documented quite well:

http://gcc.gnu.org/onlinedocs/gccint/Trampolines.html

Anyways, my primary concerns are making things work and moving
forwards to something that is releasable.  Making GRUB work in a way
so it works like everyone wants is secondary and not possible in
practice.  Paranoid security is secondary to me, but if we can get it
for free without making a mess of the code, that would be great.

--
Marco

Re: GRUB2 Build on Mac OS X

[Yoshinori K. Okuji]

On Friday 09 December 2005 12:40 am, Peter Jones wrote:
> Now, the obvious retort to this is that no setuid programs are calling
> grub, so it's not even one of those cases.  That's not a good answer
> either.  I've got one I'd really *like* to call grub from, and it is
> pm-hibernate, through consolehelper, and they both accept some degree of
> user input from whoever's logged in on the console.
>
> I'd really like to make it so that if somebody has 2 kernels installed,
> boots the non-default one, hibernates their laptop, and unsuspends
> without paying attention, it doesn't die a horrible death.  The most
> obvious way to do that is to make pm-hibernate set the next-boot device
> to the currently running one.

I don't agree. Here what you need to use is grub-setdefault but not grub 
itself. grub-setdefault is just a shell script, so it does not matter whether 
we use nested functions or not in the C code.

I don't see any security concern in GRUB. At least I haven't seen any scenario 
yet. I don't say that it is good that GCC generates code to use a stack for 
executing code, because it is hard to find a bug when buffer overflow happens 
due to a programming mistake. But I don't think executable stacks are bad 
*for security* in GRUB.

Okuji

Re: GRUB2 Build on Mac OS X

[Yoshinori K. Okuji]

On Saturday 10 December 2005 12:32 am, Marco Gerards wrote:
> Wouldn't it be possible to use some other memory than the stack to
> implement trampolines?  It's documented quite well:

By modifying GCC and a dynamic linker, it is possible.

> Anyways, my primary concerns are making things work and moving
> forwards to something that is releasable.  Making GRUB work in a way
> so it works like everyone wants is secondary and not possible in
> practice.  Paranoid security is secondary to me, but if we can get it
> for free without making a mess of the code, that would be great.

Paranoid is called paranoid, because it is a disease. Many people tend to 
forget that things are always based on a tradeoff. If such an attempt as 
prohibiting all executable stacks is merely paranoid, we should not care 
about it.

Okuji

Re: GRUB2 Build on Mac OS X

[Marco Gerards]

"Yoshinori K. Okuji" <okuji@enbug.org> writes:

> On Friday 09 December 2005 12:40 am, Peter Jones wrote:
>> Now, the obvious retort to this is that no setuid programs are calling
>> grub, so it's not even one of those cases.  That's not a good answer
>> either.  I've got one I'd really *like* to call grub from, and it is
>> pm-hibernate, through consolehelper, and they both accept some degree of
>> user input from whoever's logged in on the console.
>>
>> I'd really like to make it so that if somebody has 2 kernels installed,
>> boots the non-default one, hibernates their laptop, and unsuspends
>> without paying attention, it doesn't die a horrible death.  The most
>> obvious way to do that is to make pm-hibernate set the next-boot device
>> to the currently running one.
>
> I don't agree. Here what you need to use is grub-setdefault but not grub 
> itself. grub-setdefault is just a shell script, so it does not matter whether 
> we use nested functions or not in the C code.
>
> I don't see any security concern in GRUB. At least I haven't seen any scenario 
> yet. I don't say that it is good that GCC generates code to use a stack for 
> executing code, because it is hard to find a bug when buffer overflow happens 
> due to a programming mistake. But I don't think executable stacks are bad 
> *for security* in GRUB.

It would be nice if someone could give a less theoretical example of
things that could go wrong.  Until then we shouldn't bother with
something that hypothetically can go wrong just because gcc internally
uses an executable stack to implement trampolines.

--
Marco

Re: GRUB2 Build on Mac OS X

[Peter Jones]

On Sat, 2005-12-10 at 01:23 +0100, Yoshinori K. Okuji wrote:
> On Saturday 10 December 2005 12:32 am, Marco Gerards wrote:
> > Anyways, my primary concerns are making things work and moving
> > forwards to something that is releasable.  Making GRUB work in a way
> > so it works like everyone wants is secondary and not possible in
> > practice.  Paranoid security is secondary to me, but if we can get it
> > for free without making a mess of the code, that would be great.
> 
> Paranoid is called paranoid, because it is a disease. Many people tend to 
> forget that things are always based on a tradeoff. If such an attempt as 
> prohibiting all executable stacks is merely paranoid, we should not care 
> about it.

Except NX isn't just paranoid.  In Fedora Core 3, 43% of our
vulnerabilities did not apply to systems on which the hardware supported
non-executable stacks.

It's not a trivial number, and it wasn't all things that you could
predict without using some "hypothetical" examples.

Anyway, I certainly can't make you change the way you're doing
something.  I can say that if upstream GRUB 2 requires executable stacks
in userland (post-boot) processes, then neither Fedora Core nor RHEL can
ship anything very close to the upstream version of GRUB 2, because we
very seriously consider this practice to be a major security problem.

-- 
  Peter