"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