[Top][All Lists]

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

Re: Nested Function Patches

From: Marco Gerards
Subject: Re: Nested Function Patches
Date: Tue, 10 Jan 2006 11:17:37 +0100
User-agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux)

Peter Jones <address@hidden> writes:

> On Mon, 2006-01-09 at 16:06 +0100, Yoshinori K. Okuji wrote:
>> On Wednesday 28 December 2005 09:08 am, Peter Jones wrote:
>> > That's taking the very unrealistic point of view that using nested
>> > functions isn't broken.  It is, in a great many ways which have already
>> > been discussed in depth, and which you've, rather disturbingly, chosen
>> > to ignore.  Using "features" which require an executable stack is still
>> > just a bad idea.
>> >
>> > It's too bad that the grub project has chosen to ignore the pragmatic
>> > implications of code structure and style.
>> I'm sick of your FUD.
> There's no FUD here.  The grub project *has* chosen to ignore the
> implications of this, and you continue to do so.

I have added looking at this issue to the TODO list and written a page
with information about this issue on the wiki.  Why do you call this
ignoring?  Perhaps we do not do exactly what you want us to do, but we
are aware of the situation.  I think it is our business to deal with
in in the way we think is appropriate.

>>  If you are an engineer or programmer, show a technical 
>> reason.
> This is just plain insulting; I've sent you numerous patches for various
> things and tried, on several occasions fairly successfully, to cooperate
> with you.  I've got more patches which could be beneficial as well,
> though mostly they're in a state where they're not suitable for upstream
> yet, and I expect you know this if you're even paying the slightest bit
> of attention to how people are using grub.

Sorry, but what are you talking about?  I haven't seen patches for
GRUB 2 from you.  Perhaps I have missed something and we can work this

Can you explain what you mean with "how people are using grub"?

> The fact that we disagree on this point hardly justifies the insinuation
> that I'm not "an engineer or a programmer".  Above that, I *have* cited
> technical reasons, and you don't seem to be interested in them.

And I would suggest we will keep this discussion technical.  I think
Okuji means that you didn't show us exactly why nested functions
should be removed.  You seem to forget that:

 a) Nested functions don't cause problems in every occasion.

 b) The GCC developers didn't consider removing nested functions.  So
    they are not deprecated or broken like you suggested.  I think
    this is what Okuji referred to when he said FUD.

 c) GRUB is just like GCC a GNU project.

>> - You feel that it is safer
> I haven't said anything about what I "feel", and you're putting it this
> way to try to unrealistically discredit my statements.  It is
> demonstrably safer not to have executable stacks, and I have mentioned
> that and quoted the figures to do so.  Nested functions mandate the use
> of executable stacks.  Thus, it is safer not to use nested functions.

Why don't you send an email describing these problems, or perhaps a
patch, to the GCC developers?  Your opinion how to deal with stacks
conflict with the idea how nested functions are implemented.  So these
implementation issues are a bit off-topic here, I think.  Have you
contacted the GCC developers already?  I did.

>> - Everybody is going to disable executable stacks
> I don't think I've said everybody, but I have said that the trend is
> towards more OSes doing this.  Is this somehow not clearly true.
>> Where is such a discussion in depth? Is this time before renaissance?
> Off the top of my head, this discussion has been pretty constant for the
> last 10 or so years on linux-kernel, and was fairly prominent in the
> last year on the mailing lists for binutils, gcc, and glibc.  It's also
> been a topic of discussion on quite a few other lists, and as far as I'm
> aware no other project has had any serious problem with making their
> stacks non-executable when there was no technical reason for them to be
> executable.  Your like of nested functions isn't a technical reason --
> you think it's pretty, and that's pretty much the end of the reasoning.

It is.

About the discussions on the linux kernel mailinglist.  I have seen
patches in the past that disable executable stacks, but don't break
nested functions.  Why weren't those used instead?  But I am afraid
that is also off-topic here.

> I'm not going to argue about if those aesthetic values are reasonable or
> not, but I will reiterate that there has been no technical reason
> presented, even when very politely without any hint of ridicule or
> chastising, for using any feature which requires an executable stack.
> So don't talk about me spreading FUD when I haven't, or of not citing
> technical reasons.  I have, and you've cited only aesthetic ones.

Those reasons are as good as any other.  If the code is somehow
crippled it will make it hard to maintain.

>> I understand the behavior of Red Hat, since Red Hat is after all a 
>> commercial 
>> entity, so it must make business from marketing point of view.
> You clearly do not.  It isn't *at all* about any marketing point of
> view.  Programs with executable stacks are demonstrably exploited more
> than those without, and that includes programs not foreseen to be run in
> a way where overruns could result in an exploit.  That's the real world,
> which you're ignoring.

You could also say that the people who disabled execution on the stack
ignored existing features.  Instead of changing the way trampolines
are implemented, you just have thrown the switch and disabled all
this.  As you see it is just a matter of perspective.

Too bad this discussion is rapidly heading in the wrong direction.
Perhaps we don't all agree on the direction of GRUB, but I think that
is up to the GRUB maintainers.  But certainly we need to be able and
remain to be able to discuss on issues on a technical level.


reply via email to

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