Re: GRUB2 Build on Mac OS X
Yoshinori K. Okuji [EMAIL PROTECTED] 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 ___ 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 [EMAIL PROTECTED] writes: On Dec 8, 2005, at 4:01 PM, [EMAIL PROTECTED] 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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB2 Build on Mac OS X
[EMAIL PROTECTED] 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 ___ 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 [EMAIL PROTECTED] 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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB2 Build on Mac OS X
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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB2 Build on Mac OS X
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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB2 Build on Mac OS X
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 ___ 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 [EMAIL PROTECTED] 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
Andrei Warkentin [EMAIL PROTECTED] 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
Re: GRUB2 Build on Mac OS X
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.0checking host system type... powerpc-unknown-linux-gnuchecking for powerpc-linux-gcc... powerpc-linux-gccchecking for C compiler default output file name... configure: error: C compiler cannot create executablesSee `config.log' for more details.With config log:hostname = Uruz.localuname -m = Power Macintoshuname -r = 8.3.0uname -s = Darwinuname -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 = unknownhostinfo = 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_PPCKernel configured for a single processor only.1 processor is physically available.Processor type: ppc7450 (PowerPC 7450)Processor active: 0Primary memory available: 512.00 megabytesDefault processor set: 58 tasks, 181 threads, 1 processorsLoad average: 1.73, Mach factor: 0.45/bin/machine = unknown/usr/bin/oslevel = unknown/bin/universe = unknownPATH: .PATH: /sw/binPATH: /sw/sbinPATH: /Users/andreywarkentin/crossdev/i686-linux/binPATH: /Users/andreywarkentin/crossdev/powerpc-linux/binPATH: /binPATH: /sbinPATH: /usr/binPATH: /usr/sbinPATH: /usr/X11R6/bin## --- Core tests. --- ##configure:1348: checking build system typeconfigure:1366: result: powerpc-apple-darwin8.3.0configure:1374: checking host system typeconfigure:1388: result: powerpc-unknown-linux-gnuconfigure:1432: checking for powerpc-linux-gccconfigure:1448: found /Users/andreywarkentin/crossdev/powerpc-linux/bin/powerpc-linux-gccconfigure:1458: result: powerpc-linux-gccconfigure:1740: checking for C compiler versionconfigure:1743: powerpc-linux-gcc --version /dev/null 5powerpc-linux-gcc (GCC) 4.0.2Copyright (C) 2005 Free Software Foundation, Inc.This is free software; see the source for copying conditions. There is NOwarranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.configure:1746: $? = 0configure:1748: powerpc-linux-gcc -v /dev/null 5Using built-in specs.Target: powerpc-linuxConfigured with: ../gcc-4.0.2/configure --target=powerpc-linux --prefix=/Users/andreywarkentin/crossdev/powerpc-linux --disable-shared --disable-threads --enable-languages=c,c++ --with-newlibThread model: singlegcc version 4.0.2configure:1751: $? = 0configure:1753: powerpc-linux-gcc -V /dev/null 5powerpc-linux-gcc: '-V' option must have argumentconfigure:1756: $? = 1configure:1779: checking for C compiler default output file nameconfigure: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 directorycollect2: ld returned 1 exit statusconfigure:1785: $? = 1configure: 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 executablesSee `config.log' for more details.## Cache variables. ##ac_cv_build=powerpc-apple-darwin8.3.0ac_cv_build_alias=powerpc-apple-darwin8.3.0ac_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=setac_cv_env_host_alias_value=powerpc-linuxac_cv_env_target_alias_set=ac_cv_env_target_alias_value=ac_cv_host=powerpc-unknown-linux-gnuac_cv_host_alias=powerpc-linuxac_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
Re: GRUB2 Build on Mac OS X
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:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
On Dec 8, 2005, at 4:01 PM, [EMAIL PROTECTED] 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:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB2 Build on Mac OS X
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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
