grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GRUB2 Build on Mac OS X


From: Marco Gerards
Subject: Re: GRUB2 Build on Mac OS X
Date: Sat, 10 Dec 2005 15:32:17 +0100
User-agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux)

"Yoshinori K. Okuji" <address@hidden> 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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]