John Plocher wrote:
> On a related note, the upcoming S10->OpenSolaris Enterprise transition
> is *the* time for such a change.  If you miss this train, you will not
> have the opportunity to easily do so for quite a while.
>
> While I agree that "mapfile version = 2 means nonexec stacks" is a
> poorly overloaded semantic for such a change, I urge you to come up
> with a usable mechanism and deploy it in this release.
>   

It seems, to me at least, like the time to make this change is now.  I 
don't think that the syntax ought to be the trigger though.

New objects built on OpenSolaris ought to use a non-exec stack by 
default.  Without user intervention.  I think executable stacks should 
be an opt-in feature.

The question at hand (IMO), is avoiding breakage for old 
binaries/objects which may rely on executable stacks.

So I guess what I'm talking about is a change in the default, globally.  
I presume its possible to do this so the default is applied at compile 
time, rather than load time?   (That would address the concern of 
breakage of older binaries.)

Btw, I'm of the mind that it may be questionable to retain the old v1 
mapfile syntax for very long.  As indicated, not many people are using 
it, and we really shouldn't have to carry around baggage ~forever.   I 
don't think the mapfile syntax was ever officially part of our source 
compatibility story. :-)

Perhaps a tool (script) to automatically convert a v1 mapfile to a v2 
format would be helpful here?

    - Garrett
>  Ali Bahrami wrote:
>   
>>> I think this stack protection issue is better solved as part of the
>>> solution to
>>>
>>>     6239804 make it easier for ld(1) to do what's best
>>>
>>> which is something we've been thinking about independently of
>>> mapfiles (and of course, something that is not part of this case).
>>>       
>
>
> James Carlson wrote:
>   
>> However, when that solution arrives, won't the implication be that
>> non-executable stacks become the default way of doing things?
>>
>> The question then becomes: what are the steps along that path?
>>     
>
>   -John
>   

Reply via email to