From sacadmin Tue Dec 22 12:19:47 2009 Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBMKJlVm026256; Tue, 22 Dec 2009 12:19:47 -0800 (PST) Received: (from ab196087@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id nBMKJlIA026252; Tue, 22 Dec 2009 12:19:47 -0800 (PST) Date: Tue, 22 Dec 2009 12:19:47 -0800 (PST) From: Ali Bahrami Message-Id: <200912222019.nBMKJlIA026252@sac.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Subject: Human readable and extensible ld mapfile syntax [PSARC/2009/688 FastTrack timeout 1/13/2010] Status: RO Content-Length: 583 Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Human readable and extensible ld mapfile syntax 1.2. Name of Document Author/Supplier: Author: Ali Bahrami 1.3 Date of This Document: 22 December, 2009 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: on 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From Ali.Bahrami@sun.com Tue Dec 22 12:29:02 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBMKT2j5026425 for ; Tue, 22 Dec 2009 12:29:02 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id nBMKT14A004737 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 22 Dec 2009 13:29:01 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KV20070TM8D8C00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 22 Dec 2009 12:29:01 -0800 (PST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KV200441M8BV980@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 22 Dec 2009 12:28:59 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nBMKSx27019925 for ; Tue, 22 Dec 2009 20:28:59 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KV200K00LTDVU00@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 22 Dec 2009 13:28:59 -0700 (MST) Received: from [172.20.25.67] ([unknown] [172.20.25.67]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KV200J9QM8A2CD0@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 22 Dec 2009 13:28:58 -0700 (MST) Date: Tue, 22 Dec 2009 13:25:47 -0700 From: Ali Bahrami Subject: PSARC/2009/688 Human readable and extensible ld mapfile syntax Sender: Ali.Bahrami@sun.com To: PSARC-ext@sun.com Message-id: <4B312B4B.3030405@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.23 (X11/20090929) Status: RO Content-Length: 8136 I am sponsoring the following fasttrack for myself. I propose a new mapfile language for the Solaris link-editor (ld). ----- Release Binding: Minor New mapfile syntax: Committed Although I believe this work qualifies for Patch/Micro binding, there is no desire or intent to take this work back to any Solaris release before Nevada/OpenSolaris. Although a new mapfile language may seem a large step, I believe that a fasttrack is appropriate: The link-editor maintains full backward compatibility with existing mapfiles, and the new language is rather evolutionary in nature, as it is based upon the existing syntax for symbol scope/version in the original language. However, given the time of year, the bulk of materials included, and the fact that we are heading into a series of restricted builds during which this work would not integrate, I am setting a longer than usual timeout for this case of three weeks. ----- Within the linker group, we have long believed that it would become necessary to replace the mapfile language used by the Solaris link-editor (ld). The existing mapfile language was not designed to be extended, and yet, has had various features grafted on for 20+ years. It is inconsistent, difficult to document, and has become an impediment to future progress. We believe that it is time to make a fresh start with a syntax that is simple, consistent, and designed to simplify additions. In doing this work, I had the following high level goals: - Full support for existing mapfiles written in the original language (which we now refer to as version 1). Existing mapfiles will "just work", without requiring any end user adjustment. - Human Readable: The original language is extremely terse, and uses "magic characters" such as '=', ':', '|', and '@', to differentiate the various statements in the language, with widespread overloading of characters such as '$' which have different meanings in different contexts. It is generally not possible to read a Solaris mapfile without a copy of the Linker and Libraries manual at hand to decode it. A more readable keyword based syntax is desired. - Extensible: Primarily due to the previous point, the original mapfile has become considerably more difficult to extend and maintain as time has gone by, to the point where few people claim to understand the language, and adding new features has become problematic. The new syntax will use keywords to represent the different available options, which is considerably more mnemonic and which offers very large namespace for additions. It will use a standard underlying abstract syntax for all features, instead of the ad hoc approach taken in the original language, which will also make the system easy to extend. - Simple conditional input: I have observed that multiple mapfiles are sometimes used in the ON code base to express minor per-platform variations (e.g. a symbol may only exist on a specific platform). These extra mapfiles are clutter, and a potential vector for versioning errors to go undetected. A simple mechanism to allow conditional input of mapfile lines would be of value. - Familiarity: I believe that the problems with the original mapfile language are primarily matters of syntax, and that the semantic level of the language is reasonable, and appropriate. Furthermore, the vast majority of extant mapfiles are restricted to the scope/version subset, which is newer than the rest of the language (Solaris 2.5), has fewer problems, and is generally well liked. I therefore seek to clean up the mapfile language without losing the benefit of the familiarity people have with the original, by creating a new syntax based upon the scope/version subset of the old version. I have placed several files in the case materials: [mapfile.html] A replacement chapter for the Solaris Linker and Libraries mapfiles chapter. The proposed language is defined by this document. [sysv_mapfiles.html] Rough draft of future article to be posted to my Sun blog after this case is complete, detailing the flaws of the original mapfile language, in support of the need to replace it. I do not consider this document to be part of this case, but it does provide useful background information for interested parties. [new_mapfiles.html] Rough draft of a followup article for my Sun blog, intended to follow sysv_mapfiles.html once this work has been put back. This document describes the design requirements applied to the new language, covers the same abstract syntax details documented in mapfile.html, and then provides a large number of examples showing how you express various concepts in both the old and new syntax. The mapfile language described in these documents has been fully implemented and code reviewed, and I believe it is ready for integration. Within SWAN, the machines rtld.central (x86) and ldd.central (sparc) have linkers containing this work installed. I invite any interested parties to log on to those machines and experiment. ----- A good way to evaluate the new syntax is to compare mapfiles written in both the old and new languages. The new_mapfiles.html document contains several such examples. In addition, as a proof of concept, and foreshadowing a future project, I have converted every mapfile in ON from the old syntax to the new, and using the new linker, have built and BFU'd the results on both sparc and x86 systems, currently running on rtld.central and ldd.central. The webrev for this workspace can be viewed at: http://linkers.central/webrev/mapfile_osnet within SWAN, and at http://cr.opensolaris.org/~alib/mapfile_osnet outside. Please note that I do not intend to integrate this ON workspace as part of the putback for this new mapfile syntax. Any such change must wait for a period after the linker support integrates. For the purposes of this case, this webrev is provided solely as illustration of the new language, and proof of suitability for its intended purpose. You can look at how the parts of the system you're familiar with might change using this new functionality. 99% of the mapfiles in ON do nothing other than symbol versioning. You'll find that these have only changed in minor ways: http://linkers.central/webrev/mapfile_osnet/usr/src/lib/README.mapfiles.sdiff.html The most substantial difference is that conditional input directives can be used to eliminate the ISA-specific mapfiles in the {amd64,i386,sparc,sparcv9} subdirectories, which is almost always a simplification. Libc is probably the most complex library in ON in this regard, and the mapfile changes for it are worth examining as a demonstration of how things work in a large history-laden example: http://linkers.central/webrev/mapfile_osnet/usr/src/lib/libc/port/mapfile-vers.sdiff.html Kernel developers may be interested in how the more traditional segment related parts of the language have evolved: http://linkers.central/webrev/mapfile_osnet/usr/src/uts/i86pc/conf/Mapfile.sdiff.html http://linkers.central/webrev/mapfile_osnet/usr/src/uts/i86pc/conf/Mapfile.amd64.sdiff.html http://linkers.central/webrev/mapfile_osnet/usr/src/uts/i86pc/conf/Mapfile.bios.sdiff.html http://linkers.central/webrev/mapfile_osnet/usr/src/uts/i86pc/conf/Mapfile.fb_swtch.sdiff.html http://linkers.central/webrev/mapfile_osnet/usr/src/uts/i86pc/unix/dboot/Mapfile.dboot.sdiff.html http://linkers.central/webrev/mapfile_osnet/usr/src/uts/i86xpv/conf/Mapfile.sdiff.html http://linkers.central/webrev/mapfile_osnet/usr/src/uts/i86xpv/conf/Mapfile.amd64.sdiff.html http://linkers.central/webrev/mapfile_osnet/usr/src/uts/i86xpv/unix/dboot/Mapfile.dboot.sdiff.html http://linkers.central/webrev/mapfile_osnet/usr/src/uts/sun4/conf/Mapfile.sdiff.html From Alan.Coopersmith@Sun.COM Tue Dec 22 13:39:38 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBMLdc3L028103 for ; Tue, 22 Dec 2009 13:39:38 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id nBMLdbES055492 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 22 Dec 2009 14:39:37 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KV200K1DPI15G00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 22 Dec 2009 13:39:37 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KV200F3QPI0HQ90@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 22 Dec 2009 13:39:36 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nBMLdawY015170 for ; Tue, 22 Dec 2009 13:39:36 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KV200F00P852600@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 22 Dec 2009 13:39:36 -0800 (PST) Received: from [10.6.102.27] ([unknown] [10.6.102.27]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KV2002T1PI0OK50@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 22 Dec 2009 13:39:36 -0800 (PST) Date: Tue, 22 Dec 2009 13:39:36 -0800 From: Alan Coopersmith Subject: Re: PSARC/2009/688 Human readable and extensible ld mapfile syntax In-reply-to: <4B312B4B.3030405@Sun.COM> Sender: Alan.Coopersmith@Sun.COM To: Ali Bahrami Cc: PSARC-ext@Sun.COM Message-id: <4B313C98.4040503@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <4B312B4B.3030405@Sun.COM> User-Agent: Thunderbird 2.0.0.23 (X11/20090926) Status: RO Content-Length: 701 This all looks good to me. The one thing I wonder about changing: > By default, the stack has READ, WRITE, and EXECUTE permissions. The EXECUTE setting exists for historical reasons. It is rarely if ever needed and is generally considered to be a potential security risk. Removing EXECUTE permission from the stack is a recommended practice: > > STACK { > FLAGS -= EXECUTE; > }; Is there any reason to not just say "If you're using a version 2 mapfile, stack is non-executable by default, and you have to explicitly add it in the very few cases it's needed" ? -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From Ali.Bahrami@sun.com Tue Dec 22 14:59:34 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBMMxYwv029453 for ; Tue, 22 Dec 2009 14:59:34 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nBMMxXsS021738 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 22 Dec 2009 14:59:33 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KV20060BT798O00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 22 Dec 2009 15:59:33 -0700 (MST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KV200KELT770350@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 22 Dec 2009 15:59:31 -0700 (MST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nBMMxVdG005211 for ; Tue, 22 Dec 2009 22:59:31 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KV200E00SLWKG00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 22 Dec 2009 15:59:31 -0700 (MST) Received: from [172.20.25.67] ([unknown] [172.20.25.67]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KV200J7XT649Z30@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 22 Dec 2009 15:58:52 -0700 (MST) Date: Tue, 22 Dec 2009 15:55:41 -0700 From: Ali Bahrami Subject: Re: PSARC/2009/688 Human readable and extensible ld mapfile syntax In-reply-to: <4B313C98.4040503@sun.com> Sender: Ali.Bahrami@sun.com To: Alan Coopersmith Cc: PSARC-ext@sun.com Message-id: <4B314E6D.4090901@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B312B4B.3030405@Sun.COM> <4B313C98.4040503@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20090929) Status: RO Content-Length: 1880 Alan Coopersmith wrote: > This all looks good to me. The one thing I wonder about changing: > >> By default, the stack has READ, WRITE, and EXECUTE permissions. The EXECUTE setting exists for historical reasons. It is rarely if ever needed and is generally considered to be a potential security risk. Removing EXECUTE permission from the stack is a recommended practice: >> >> STACK { >> FLAGS -= EXECUTE; >> }; > > Is there any reason to not just say "If you're using a version 2 mapfile, > stack is non-executable by default, and you have to explicitly add it in > the very few cases it's needed" ? > I appreciate the sentiment, because having the stack be executable by default is a real problem. I did think about doing that, but decided against it for a couple of reasons: 1) This would imply that an empty mapfile that contained nothing more than $mapfile_version 2 would alter default behavior. I think that sort of thing needs to be explicit, so that there's no confusion, particularly as an empty version 1 mapfile has no such effect. 2) The vast majority of applications don't use mapfiles anyway, and those that do are all (today) using the old syntax. This proposal would not reach any of them, so it misses a large fraction of our audience --- arguably the ones we most need to reach. Anyone who understands (1) and (2) is already in a position to include the STACK directive into their mapfiles, and is probably already doing so (as we do in ON, and I know you do in X11). 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). - Ali From carlsonj@workingcode.com Wed Dec 23 06:28:14 2009 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBNESDFX022278 for ; Wed, 23 Dec 2009 06:28:14 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nBNES9qt009184; Wed, 23 Dec 2009 08:28:12 -0600 (CST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KV400D0V06ZDL00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 23 Dec 2009 06:28:11 -0800 (PST) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KV400BBC06YB740@nwk-avmta-1.sfbay.Sun.COM>; Wed, 23 Dec 2009 06:28:10 -0800 (PST) Received: from relay44i.sun.com ([192.5.209.118]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nBNEPMKx017388; Wed, 23 Dec 2009 14:28:10 +0000 (GMT) Received: from mms49es.mms.us.syntegra.com ([160.41.221.232] [160.41.221.232]) by relay44i.sun.com with ESMTP id BT-MMP-4592713; Wed, 23 Dec 2009 14:28:08 +0000 (Z) Received: from relay45i.sun.com (relay45i.sun.com [192.5.209.94]) by mms49es.mms.us.syntegra.com with ESMTP id BT-MMP-12169768; Wed, 23 Dec 2009 14:28:07 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay4i.sun.com with ESMTP id BT-MMP-25748162; Wed, 23 Dec 2009 14:28:07 +0000 (Z) Received: from [10.50.24.188] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.3) with ESMTP id nBNES1q4008159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Dec 2009 09:28:01 -0500 (EST) Date: Wed, 23 Dec 2009 09:28:01 -0500 From: James Carlson Subject: Re: PSARC/2009/688 Human readable and extensible ld mapfile syntax In-reply-to: <4B314E6D.4090901@Sun.COM> To: Ali Bahrami Cc: Alan Coopersmith , PSARC-ext@sun.com Message-id: <4B3228F1.2070806@workingcode.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DCC-dmv.com-Metrics: carlson; whitelist X-Antispam: No, score=0.0/5.0, scanned in 0.061sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4B312B4B.3030405@Sun.COM> <4B313C98.4040503@sun.com> <4B314E6D.4090901@Sun.COM> User-Agent: Thunderbird 2.0.0.22 (X11/20090605) Status: RO Content-Length: 1307 Ali Bahrami wrote: > Anyone who understands (1) and (2) is already in a position to include the > STACK directive into their mapfiles, and is probably already doing so > (as we do in ON, and I know you do in X11). Yep; agreed. Those who bother with mapfiles are in a good position to set the right flags with minimal effort. Unfortunately, that's likely a distinct minority. Heck, I see few software vendors who even use -R correctly. Most rely on users or complicated scripts to set LD_LIBRARY_PATH, and are unlikely to indulge in exotica like mapfiles. > 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). 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? If you're changing the mapfile version number, isn't this a good time to introduce at least some of the new behavior by making non-executable stacks the default? Why keep the bad old default? -- James Carlson 42.703N 71.076W From Ali.Bahrami@sun.com Wed Dec 23 09:23:21 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBNHNLZR024686 for ; Wed, 23 Dec 2009 09:23:21 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id nBNHNJiK009534 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 23 Dec 2009 10:23:20 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KV40070T8AWQW00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 23 Dec 2009 09:23:20 -0800 (PST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KV400IYJ8ATX8B0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 23 Dec 2009 09:23:17 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nBNHNHan029763 for ; Wed, 23 Dec 2009 17:23:17 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KV4002006J8U000@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 23 Dec 2009 10:23:17 -0700 (MST) Received: from [198.182.198.27] ([unknown] [199.45.162.234]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KV400J1F8AQCI50@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 23 Dec 2009 10:23:16 -0700 (MST) Date: Wed, 23 Dec 2009 10:23:13 -0700 From: Ali Bahrami Subject: Re: PSARC/2009/688 Human readable and extensible ld mapfile syntax In-reply-to: <4B3228F1.2070806@workingcode.com> Sender: Ali.Bahrami@sun.com To: James Carlson Cc: Alan Coopersmith , PSARC-ext@sun.com Message-id: <4B325201.40400@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B312B4B.3030405@Sun.COM> <4B313C98.4040503@sun.com> <4B314E6D.4090901@Sun.COM> <4B3228F1.2070806@workingcode.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090505) Status: RO Content-Length: 3026 James Carlson wrote: > Ali Bahrami wrote: >> Anyone who understands (1) and (2) is already in a position to include the >> STACK directive into their mapfiles, and is probably already doing so >> (as we do in ON, and I know you do in X11). > > Yep; agreed. Those who bother with mapfiles are in a good position to > set the right flags with minimal effort. > > Unfortunately, that's likely a distinct minority. Heck, I see few > software vendors who even use -R correctly. Most rely on users or > complicated scripts to set LD_LIBRARY_PATH, and are unlikely to indulge > in exotica like mapfiles. > >> 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). > > 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? If > you're changing the mapfile version number, isn't this a good time to > introduce at least some of the new behavior by making non-executable > stacks the default? Why keep the bad old default? > I'm not opposed to changing the bad old default (indeed, would welcome it), but doing it based on the mapfile version seems like the wrong solution to me. My concerns are: - Basic UI: Magic defaults that change due to unrelated things are confusing to use, and to document. I can easily imagine someone changing to the V2 syntax without realizing that they've also changed their stack protections. - It won't affect many objects: As you say, those who use mapfiles are in a distinct minority, and as v2 mapfiles are something you have to opt into, those who use them will be a distinct minority of a distinct minority. In fact, it probably won't reach anyone we're not already reaching with explicit mapfile directives today. - You can have more than one mapfile on an ld command line, and they are each allowed to be either version 1 or 2 independently of the others. Which should win? Consider the example in which you have not converted your mapfiles, or maybe don't even have one, but are also using one of the standard ones we provide in /usr/lib/ld, which will certainly move to V2 once the ld support is in place. Should your stack defaults change because you used a system provided mapfile? I think it would be confusing, and won't make a significant difference. Executable stacks are bad, but the solution to that needs to be orthogonal to mapfile syntax. > However, when that solution arrives, won't the implication be that > non-executable stacks become the default way of doing things? No, because it would be an option that the user has to select, and not a default. - Ali From john.plocher@gmail.com Wed Dec 23 09:33:25 2009 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBNHXORf024843 for ; Wed, 23 Dec 2009 09:33:25 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nBNHXMTN004746; Wed, 23 Dec 2009 11:33:23 -0600 (CST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KV400A098RN0T00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 23 Dec 2009 09:33:23 -0800 (PST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KV400IH08RMYDB0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 23 Dec 2009 09:33:22 -0800 (PST) Received: from relay11i.sun.com (ip121.net129179-4.block1.us.syntegra.com [129.179.4.121]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nBNHXLvb018942; Wed, 23 Dec 2009 17:33:21 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay11i.sun.com with ESMTP id BT-MMP-9585372; Wed, 23 Dec 2009 17:33:21 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-303170; Wed, 23 Dec 2009 17:33:21 +0000 (Z) Received: from mail-qy0-f179.google.com ([209.85.221.179] [209.85.221.179]) by relay1i.sun.com with ESMTP id BT-MMP-16709069; Wed, 23 Dec 2009 17:33:21 +0000 (Z) Received: by qyk9 with SMTP id 9so3456591qyk.30 for ; Wed, 23 Dec 2009 09:33:19 -0800 (PST) Received: by 10.229.23.83 with SMTP id q19mr4659362qcb.37.1261589598841; Wed, 23 Dec 2009 09:33:18 -0800 (PST) Date: Wed, 23 Dec 2009 09:33:18 -0800 From: John Plocher Subject: Re: PSARC/2009/688 Human readable and extensible ld mapfile syntax In-reply-to: <4B3228F1.2070806@workingcode.com> To: James Carlson Cc: Ali Bahrami , PSARC-ext@sun.com, Alan Coopersmith Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=amd7nYB7ys88z22rkU7idTfpimjQXnzT5qK0cs5ZPxY=; b=liRWzQ8NsscTbrFQudFwJ0dcWyMIKbM8LGc0PcCimQ+6Mxf4VsmbsV42fqp2G1dS9k zLBtua7n5T9P04Ln0soC5GOlNo72B5VSCtxuwFMIbw3VvT/yTr3LKeU4sVMcw/T3tTnC 0G4Pzeoemufn0yQTo2A8BUl0VCqlWVLxSN4Ng= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=DsOcPn3ahWh38y14RV6SVKbBPkEjkMXRc77luiFLD/7lL8sNXBLImChu0mixlil0lA S/MQ97lVNu2p4EkK0yuegU9ulIlr517bgD/8KQa60dV87xWyOK3vW25ZAcIMk/14wdJE pK2GVq4wO0OPAmUuROo+cvJRXaEDxSxTtenfU= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.056sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4B312B4B.3030405@Sun.COM> <4B313C98.4040503@sun.com> <4B314E6D.4090901@Sun.COM> <4B3228F1.2070806@workingcode.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sac.sfbay.sun.com id nBNHXORf024843 Status: RO Content-Length: 928 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. 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 From carlsonj@workingcode.com Wed Dec 23 10:38:21 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBNIcLJs025824 for ; Wed, 23 Dec 2009 10:38:21 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nBNIcHXu005453; Wed, 23 Dec 2009 10:38:20 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KV400G0ZBRVEN00@brm-avmta-1.central.sun.com>; Wed, 23 Dec 2009 11:38:19 -0700 (MST) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KV400CVYBRU1Q10@brm-avmta-1.central.sun.com>; Wed, 23 Dec 2009 11:38:19 -0700 (MST) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nBNIJImY011642; Wed, 23 Dec 2009 18:38:18 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay13i.sun.com with ESMTP id BT-MMP-9587663; Wed, 23 Dec 2009 18:38:18 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-446230; Wed, 23 Dec 2009 18:38:18 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay1i.sun.com with ESMTP id BT-MMP-31586318; Wed, 23 Dec 2009 18:38:17 +0000 (Z) Received: from [10.50.24.188] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.3) with ESMTP id nBNIcGEg012825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Dec 2009 13:38:17 -0500 (EST) Date: Wed, 23 Dec 2009 13:38:16 -0500 From: James Carlson Subject: Re: PSARC/2009/688 Human readable and extensible ld mapfile syntax In-reply-to: <4B325201.40400@Sun.COM> To: Ali Bahrami Cc: Alan Coopersmith , PSARC-ext@sun.com Message-id: <4B326398.7020003@workingcode.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DCC-dmv.com-Metrics: carlson; whitelist X-Antispam: No, score=-2.6/5.0, scanned in 0.135sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4B312B4B.3030405@Sun.COM> <4B313C98.4040503@sun.com> <4B314E6D.4090901@Sun.COM> <4B3228F1.2070806@workingcode.com> <4B325201.40400@Sun.COM> User-Agent: Thunderbird 2.0.0.22 (X11/20090605) Status: RO Content-Length: 3300 Ali Bahrami wrote: > I can easily imagine someone changing to the V2 syntax without > realizing that they've also changed their stack protections. That's a good thing. Very few (if any) should be relying on executable stacks these days, and those few who do ought to be inconvenienced into explicitly asking for that behavior. The current default is backwards. > - It won't affect many objects: As you say, those who use mapfiles > are in a distinct minority, and as v2 mapfiles are something > you have to opt into, those who use them will be a distinct > minority of a distinct minority. In fact, it probably won't > reach anyone we're not already reaching with explicit mapfile > directives today. It's a start. > - You can have more than one mapfile on an ld command line, and > they are each allowed to be either version 1 or 2 independently > of the others. Which should win? I'd say the best answer would be that if any are v2, then you get non-executable stacks by default, and if you want something else, then you must explicitly specify it. A less-good (but still viable) answer would be that if you use multiple, then the default stack executability is set by the last one encountered. > Consider the example in which you have not converted your > mapfiles, or maybe don't even have one, but are also using > one of the standard ones we provide in /usr/lib/ld, which > will certainly move to V2 once the ld support is in place. > Should your stack defaults change because you used a system > provided mapfile? Yes! > I think it would be confusing, and won't make a significant > difference. Executable stacks are bad, but the solution to that > needs to be orthogonal to mapfile syntax. > >> However, when that solution arrives, won't the implication be that >> non-executable stacks become the default way of doing things? > > No, because it would be an option that the user has to select, and > not a default. Isn't that exactly the badness we have today? Users aren't savvy enough to pick the right options in obscure areas like this, and certainly should not need to be. The system should provide _good_ defaults. Providing good defaults definitely means pushing users into good practices, even if it means some pain. Note that we're talking here about folks who are compiling and linking -- and presumably testing -- applications. Those who just run them aren't affected; only developers are, and developers can tolerate new behaviors much more easily, particularly so since (a) it's only on OpenSolaris (everyone's still compiling on S8 or older to support customers), (b) it's telegraphed way in advance, and (c) it's obviously goodness to avoid stack-smashing attacks by default and every other platform that's capable of this has long since done it. I agree that it's logically disjoint from the v2 work itself, but we've got to start somewhere, and I'm not convinced that a better solution is coming "soon." Unless, of course, someone's just going to turn the big switch and default all stacks to non-executable tomorrow. If that's the case, then I see no need to make v2 special. -- James Carlson 42.703N 71.076W From gdamore@sun.com Wed Dec 23 10:45:16 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBNIjGRU025908 for ; Wed, 23 Dec 2009 10:45:16 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id nBNIjCqN004827 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 23 Dec 2009 11:45:16 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KV400A03C3FPU00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 23 Dec 2009 10:45:15 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KV4003WXC3EQOC0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 23 Dec 2009 10:45:14 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nBNIjEN0017923 for ; Wed, 23 Dec 2009 10:45:14 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KV400A00BGZIH00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 23 Dec 2009 10:45:14 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KV400CRAC3DN5A0@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 23 Dec 2009 10:45:14 -0800 (PST) Date: Wed, 23 Dec 2009 10:45:13 -0800 From: "Garrett D'Amore" Subject: Re: PSARC/2009/688 Human readable and extensible ld mapfile syntax In-reply-to: Sender: Garrett.Damore@sun.com To: John Plocher Cc: James Carlson , Ali Bahrami , PSARC-ext@sun.com, Alan Coopersmith Message-id: <4B326539.7010003@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B312B4B.3030405@Sun.COM> <4B313C98.4040503@sun.com> <4B314E6D.4090901@Sun.COM> <4B3228F1.2070806@workingcode.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091013) Status: RO Content-Length: 2099 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 > From carlsonj@workingcode.com Wed Dec 23 10:57:58 2009 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBNIvwME026267 for ; Wed, 23 Dec 2009 10:57:58 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nBNIvuVr027218; Wed, 23 Dec 2009 12:57:57 -0600 (CST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KV40070BCOKAM00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 23 Dec 2009 10:57:56 -0800 (PST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KV4000WLCOJ5510@nwk-avmta-1.sfbay.Sun.COM>; Wed, 23 Dec 2009 10:57:56 -0800 (PST) Received: from relay41i.sun.com ([192.5.209.70]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nBNIc0T6004733; Wed, 23 Dec 2009 18:57:55 +0000 (GMT) Received: from mmp42es.mmp.us.syntegra.com ([160.41.221.11] [160.41.221.11]) by relay41i.sun.com with ESMTP id BT-MMP-3450203; Wed, 23 Dec 2009 18:57:55 +0000 (Z) Received: from relay42i.sun.com (relay42i.sun.com [192.5.209.72]) by mmp42es.mmp.us.syntegra.com with ESMTP id BT-MMP-11717859; Wed, 23 Dec 2009 18:57:55 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay4i.sun.com with ESMTP id BT-MMP-13503333; Wed, 23 Dec 2009 18:57:54 +0000 (Z) Received: from [10.50.24.188] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.3) with ESMTP id nBNIviUv014791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Dec 2009 13:57:49 -0500 (EST) Date: Wed, 23 Dec 2009 13:57:44 -0500 From: James Carlson Subject: Re: PSARC/2009/688 Human readable and extensible ld mapfile syntax In-reply-to: <4B326539.7010003@sun.com> To: "Garrett D'Amore" Cc: John Plocher , Ali Bahrami , PSARC-ext@sun.com, Alan Coopersmith Message-id: <4B326828.3040209@workingcode.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DCC-dmv.com-Metrics: carlson; whitelist X-Antispam: No, score=-0.2/5.0, scanned in 0.173sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4B312B4B.3030405@Sun.COM> <4B313C98.4040503@sun.com> <4B314E6D.4090901@Sun.COM> <4B3228F1.2070806@workingcode.com> <4B326539.7010003@sun.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090605) Status: RO Content-Length: 1274 Garrett D'Amore wrote: > 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. +1 If that's the actual path that will (soon?) be taken, then I no longer care about hanging my hat on the v2 syntax. > 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.) There are actually three 'times' involved -- compilation (cc), link editing (ld), and link-load (ld.so.1). It's during that second one that mapfiles are of interest and that the segment flags are set. > 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. :-) I think that's a step too far. Yes, they're Committed interfaces and, no, it would not be good to have them go away. -- James Carlson 42.703N 71.076W From gdamore@sun.com Wed Dec 23 11:15:58 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBNJFvlf026418 for ; Wed, 23 Dec 2009 11:15:57 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id nBNJFtUA027523 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 23 Dec 2009 12:15:57 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KV400C0XDIKL000@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 23 Dec 2009 11:15:56 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KV400C5BDIJHC00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 23 Dec 2009 11:15:55 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nBNJFtYX021286 for ; Wed, 23 Dec 2009 11:15:55 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KV400A00DI1EP00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 23 Dec 2009 11:15:55 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KV4002OQDII8920@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 23 Dec 2009 11:15:54 -0800 (PST) Date: Wed, 23 Dec 2009 11:15:53 -0800 From: "Garrett D'Amore" Subject: Re: PSARC/2009/688 Human readable and extensible ld mapfile syntax In-reply-to: <4B326828.3040209@workingcode.com> Sender: Garrett.Damore@sun.com To: James Carlson Cc: John Plocher , Ali Bahrami , PSARC-ext@sun.com, Alan Coopersmith Message-id: <4B326C69.7070608@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B312B4B.3030405@Sun.COM> <4B313C98.4040503@sun.com> <4B314E6D.4090901@Sun.COM> <4B3228F1.2070806@workingcode.com> <4B326539.7010003@sun.com> <4B326828.3040209@workingcode.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091013) Status: RO Content-Length: 1585 James Carlson wrote: > Garrett D'Amore wrote: > >> 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. >> > > +1 > > If that's the actual path that will (soon?) be taken, then I no longer > care about hanging my hat on the v2 syntax. > > >> 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.) >> > > There are actually three 'times' involved -- compilation (cc), link > editing (ld), and link-load (ld.so.1). It's during that second one that > mapfiles are of interest and that the segment flags are set. > > >> 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. :-) >> > > I think that's a step too far. Yes, they're Committed interfaces and, > no, it would not be good to have them go away. > But wouldn't a tool to convert them answer the requirement for Committed support? I don't think the specific compiler command lines are part of that Committed interface, but perhaps I'm wrong. And I think I'd propose marking them Obsolete (at least) as part of this. - Garrett From Andrew.Gabriel@sun.com Wed Dec 23 11:19:57 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBNJJv0M026439 for ; Wed, 23 Dec 2009 11:19:57 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nBNJJuxt024259 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 23 Dec 2009 11:19:57 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KV400K0DDP8M800@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 23 Dec 2009 12:19:56 -0700 (MST) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KV400CQ4DP51M50@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 23 Dec 2009 12:19:54 -0700 (MST) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nBNJJrrr012278 for ; Wed, 23 Dec 2009 19:19:53 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KV400200DL2RU00@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 23 Dec 2009 19:19:48 +0000 (GMT) Received: from [81.187.162.109] ([unknown] [81.187.162.109]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KV400IK0DOZZ030@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 23 Dec 2009 19:19:48 +0000 (GMT) Date: Wed, 23 Dec 2009 19:19:50 +0000 From: Andrew Gabriel Subject: Re: PSARC/2009/688 Human readable and extensible ld mapfile syntax In-reply-to: <4B326828.3040209@workingcode.com> Sender: Andrew.Gabriel@sun.com To: James Carlson Cc: "Garrett D'Amore" , Ali Bahrami , PSARC-ext@sun.com Message-id: <4B326D56.6030907@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B312B4B.3030405@Sun.COM> <4B313C98.4040503@sun.com> <4B314E6D.4090901@Sun.COM> <4B3228F1.2070806@workingcode.com> <4B326539.7010003@sun.com> <4B326828.3040209@workingcode.com> User-Agent: Thunderbird 2.0.0.23 (X11/20090929) Status: RO Content-Length: 1066 James Carlson wrote: > Garrett D'Amore wrote: > >> 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. >> Does this have any implications with respect to the SPARC ABI? If so, I suspect this would need some liaising with SPARC International Inc. >> 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. :-) >> > > I think that's a step too far. Yes, they're Committed interfaces and, > no, it would not be good to have them go away. > Pretty much every backwards incompatible change will result in loss of some customer(s) and some revenue. So doing this gratuitously without very good cause should be avoided. Also note that analyzer(1) creates mapfiles. -- Andrew From Alan.Coopersmith@sun.com Wed Dec 23 11:23:44 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBNJNiHb026480 for ; Wed, 23 Dec 2009 11:23:44 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nBNJNiI0025821 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 23 Dec 2009 11:23:44 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KV400D05DVK1W00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 23 Dec 2009 11:23:44 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KV400CFLDVKHI00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 23 Dec 2009 11:23:44 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nBNJNilX022156 for ; Wed, 23 Dec 2009 11:23:44 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KV400H00DQ8N200@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 23 Dec 2009 11:23:44 -0800 (PST) Received: from [10.6.102.27] ([unknown] [10.6.102.27]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KV4000LSDVJ3660@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 23 Dec 2009 11:23:43 -0800 (PST) Date: Wed, 23 Dec 2009 11:23:43 -0800 From: Alan Coopersmith Subject: Re: PSARC/2009/688 Human readable and extensible ld mapfile syntax In-reply-to: <4B326C69.7070608@sun.com> Sender: Alan.Coopersmith@sun.com To: "Garrett D'Amore" Cc: James Carlson , John Plocher , Ali Bahrami , PSARC-ext@sun.com Message-id: <4B326E3F.3090905@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <4B312B4B.3030405@Sun.COM> <4B313C98.4040503@sun.com> <4B314E6D.4090901@Sun.COM> <4B3228F1.2070806@workingcode.com> <4B326539.7010003@sun.com> <4B326828.3040209@workingcode.com> <4B326C69.7070608@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20090926) Status: RO Content-Length: 1594 Garrett D'Amore wrote: > James Carlson wrote: >> Garrett D'Amore wrote: >>> 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. :-) >>> >> >> I think that's a step too far. Yes, they're Committed interfaces and, >> no, it would not be good to have them go away. >> > > But wouldn't a tool to convert them answer the requirement for Committed > support? I don't think the specific compiler command lines are part of > that Committed interface, but perhaps I'm wrong. And I think I'd propose > marking them Obsolete (at least) as part of this. That would complicate life for teams and projects trying to support older Solaris releases and Solaris next from the same source tree. I know some open source projects (including older releases of X and current releases of Mesa) have some level of support for SVR4 linker mapfiles for symbol visibility. (Current releases of X upstream have mostly migrated to using source code annotations for that, though they're sadly non-standard (gcc __attribute__(visibility), Sun cc "__hidden" & "__global" keywords).) Any project to remove support for V1 mapfiles would have to update spec2map or properly obsolete it and fix every gate/product still using it. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From Ali.Bahrami@sun.com Wed Dec 23 11:27:11 2009 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBNJRBEc026501 for ; Wed, 23 Dec 2009 11:27:11 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nBNJR6WV014657 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 23 Dec 2009 13:27:11 -0600 (CST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KV400D0HE1A8U00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 23 Dec 2009 11:27:10 -0800 (PST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KV400CPFE1AHI00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 23 Dec 2009 11:27:10 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nBNJRAo7022395 for ; Wed, 23 Dec 2009 19:27:10 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KV400I00DXEUS00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 23 Dec 2009 12:27:10 -0700 (MST) Received: from [198.182.198.27] ([unknown] [199.45.162.234]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KV400LNAE18M290@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 23 Dec 2009 12:27:09 -0700 (MST) Date: Wed, 23 Dec 2009 12:27:08 -0700 From: Ali Bahrami Subject: Re: PSARC/2009/688 Human readable and extensible ld mapfile syntax In-reply-to: <4B326539.7010003@sun.com> Sender: Ali.Bahrami@sun.com To: "Garrett D'Amore" Cc: John Plocher , James Carlson , PSARC-ext@sun.com, Alan Coopersmith Message-id: <4B326F0C.20500@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B312B4B.3030405@Sun.COM> <4B313C98.4040503@sun.com> <4B314E6D.4090901@Sun.COM> <4B3228F1.2070806@workingcode.com> <4B326539.7010003@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090505) Status: RO Content-Length: 3652 Garrett D'Amore wrote: > 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 I agree with the sentiment that executable stacks should be an opt in feature, and not tied to mapfile syntax. If you want to change the world, this is the only comprehensive way to do that, and my guess is that it won't break many programs. I sent mail to some folks in the Solaris group earlier today proposing that, and hopefully something good will come of it. With that, I'd like to suggest that changing the stack protections is not this case. ----- I'd be happy to phase out the V1 syntax, but we really have no way of knowing who is using it, or how. I've chosen to be conservative on this, and provide a bridge. I spent years as an ISV, and I know that they don't appreciate having to revisit working systems, even for good reasons. I don't want to give anyone an excuse not to stay with Solaris over something as minor as this. The win of the v2 syntax isn't going to be big for these folks anyway --- I would not be proposing a new syntax if symbol versioning was the sole concern. There's not much cost to supporting V1, the extra code is not large, and there's no maintenance concern. I think we should support it for a few years, and then evaluate the situation once we're well past the transition. Another point: Our Linux/GNU friends support our old symbol versioning syntax in their linker, and there's value in making it easy for FOSS people to write one file that works in both places. ----- I just converted > 600 mapfiles in ON to the new syntax, and my feeling is that a tool to convert them would be of limited use. The actual syntax changes are simple and mechanical, particularly in the 99% that are related to symbol versioning. At the same time, I gained some big wins by rearranging things and applying conditional input directives, and a script can't help with that. The future blog article in the case materials (new_mapfiles.html) provides lots of conversion examples, and will be easy to find via google. As such, I'm not proposing such a tool as part of this case, but agree that it might be added downstream. - Ali From Nicolas.Williams@Sun.COM Wed Dec 23 11:29:05 2009 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBNJT4MA026520 for ; Wed, 23 Dec 2009 11:29:05 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nBNJT3XC016040; Wed, 23 Dec 2009 13:29:03 -0600 (CST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KV400E0HE4EV000@nwk-avmta-1.sfbay.Sun.COM>; Wed, 23 Dec 2009 11:29:02 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KV4000EZE4D4P30@nwk-avmta-1.sfbay.Sun.COM>; Wed, 23 Dec 2009 11:29:02 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nBNJLV1M012442; Wed, 23 Dec 2009 13:21:31 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nBNJLVe9012441; Wed, 23 Dec 2009 13:21:31 -0600 (CST) Date: Wed, 23 Dec 2009 13:21:31 -0600 From: Nicolas Williams Subject: Re: PSARC/2009/688 Human readable and extensible ld mapfile syntax In-reply-to: <4B326C69.7070608@sun.com> To: "Garrett D'Amore" Cc: James Carlson , John Plocher , Ali Bahrami , PSARC-ext@Sun.COM, Alan Coopersmith Message-id: <20091223192130.GS1516@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <4B312B4B.3030405@Sun.COM> <4B313C98.4040503@sun.com> <4B314E6D.4090901@Sun.COM> <4B3228F1.2070806@workingcode.com> <4B326539.7010003@sun.com> <4B326828.3040209@workingcode.com> <4B326C69.7070608@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1480 On Wed, Dec 23, 2009 at 11:15:53AM -0800, Garrett D'Amore wrote: > James Carlson wrote: > >Garrett D'Amore wrote: > >>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. :-) > > > >I think that's a step too far. Yes, they're Committed interfaces and, > >no, it would not be good to have them go away. > > But wouldn't a tool to convert them answer the requirement for Committed > support? I don't think the specific compiler command lines are part of > that Committed interface, but perhaps I'm wrong. And I think I'd propose > marking them Obsolete (at least) as part of this. Third parties' builds would still break until the mapfiles are converted. Yes, they could then do that. That's just painful though. I agree with Jim, removing v1 mapfile support is a step too far. I would prefer that the default somehow be that when building executables on OpenSolaris the stack ends up being not executable. (It'd also be nice if ld could warn about executable stacks when no mapfile explicitly set the stack to be executable. And it'd be nice if the warning said what to do about it. I'd settled for this if the default just could not be made that new executables get non-executable stacks.) Nico -- From Rod.Evans@sun.com Wed Dec 23 11:37:45 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBNJbiql026621 for ; Wed, 23 Dec 2009 11:37:44 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nBNJbhiG001532; Wed, 23 Dec 2009 11:37:43 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KV400M05EIVER00@brm-avmta-1.central.sun.com>; Wed, 23 Dec 2009 12:37:43 -0700 (MST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KV400CNAEIU1F60@brm-avmta-1.central.sun.com>; Wed, 23 Dec 2009 12:37:42 -0700 (MST) Received: from [129.146.228.120] (chaz.SFBay.Sun.COM [129.146.228.120]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id nBNJbfFX200480; Wed, 23 Dec 2009 11:37:41 -0800 (PST) Date: Wed, 23 Dec 2009 11:37:20 -0800 From: Rod Evans Subject: Re: PSARC/2009/688 Human readable and extensible ld mapfile syntax In-reply-to: <4B326828.3040209@workingcode.com> To: James Carlson Cc: "Garrett D'Amore" , John Plocher , Ali Bahrami , PSARC-ext@sun.com, Alan Coopersmith Reply-to: Rod.Evans@sun.com Message-id: <4B327170.1000605@sun.com> Organization: Sun Microsystems Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B312B4B.3030405@Sun.COM> <4B313C98.4040503@sun.com> <4B314E6D.4090901@Sun.COM> <4B3228F1.2070806@workingcode.com> <4B326539.7010003@sun.com> <4B326828.3040209@workingcode.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091124) Status: RO Content-Length: 2117 To stir the pot some more ... If we want to change the default for all applications to be that the stack is non-executable, then why don't we have exec() do it? We already do this for amd64, no? We try and steer away from having the ELF file be a transportation medium for arbitrary aspects of process creation. I believe a similar concept was the whole large page story, where various folks wanted to tell ld(1) that they wanted large pages, and ld(1) would squirrel this intent into the ELF file, or for ld.so.1 retrieval, so that the request would be passed onto the kernel. That's why we invented mmapobj(2), to get out of this game. The user shouldn't know about large pages, let alone be expected to tell the kernel it wants them. The kernel should use the best resources available for the file in question. This seems the same concept as an executable stack. Having the user record their intent, or ld(1) do it by default for them, just seems silly. Have the kernel do for everyone. Now, what do we do for folks who want an executable stack? Well, I guess these, hopefully few, folks can use a mapfile to set an executable stack. But there's also the ABI question. Under the "Managing the Process Stack" section of the SPARC ABI, it states "On SPARC, the stack segment is read, write, and execute permissions". Interestingly, for Intel it states "On the Intel386, the stack has read and write permissions". Although I believe our default for Intel is the same as SPARC. Our model used to be that by default we built ABI compliant applications and by default provided an environment for ABI execution. Should we consider these "rules" antiquated now? and default more to a secure environment? I'm not aware of anyone really updating any ABI's anymore, and the force of evolution seems to be de-facto standards (meaning whatever Linux does :-). -- Rod. Everybody to Everest! April 2010, I'll climb to Mt. Everest Base Camp as a fund raiser for The Challenged Athletes Foundation - www.everybodytoeverest.com. Visit www.everestchallenge.kintera.org/rie to show your support. Thanks! From gdamore@sun.com Wed Dec 23 11:38:25 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBNJcPSr026638 for ; Wed, 23 Dec 2009 11:38:25 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nBNJcOYt001830 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 23 Dec 2009 11:38:24 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KV400M07EK0HD00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 23 Dec 2009 12:38:24 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KV400C56EJZ1Q40@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 23 Dec 2009 12:38:23 -0700 (MST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nBNJcNHr023804 for ; Wed, 23 Dec 2009 11:38:23 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KV400500E825P00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 23 Dec 2009 11:38:23 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KV4000Y1EJY36A0@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 23 Dec 2009 11:38:23 -0800 (PST) Date: Wed, 23 Dec 2009 11:38:22 -0800 From: "Garrett D'Amore" Subject: Re: PSARC/2009/688 Human readable and extensible ld mapfile syntax In-reply-to: <4B326F0C.20500@Sun.COM> Sender: Garrett.Damore@sun.com To: Ali Bahrami Cc: John Plocher , James Carlson , PSARC-ext@sun.com, Alan Coopersmith Message-id: <4B3271AE.30008@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B312B4B.3030405@Sun.COM> <4B313C98.4040503@sun.com> <4B314E6D.4090901@Sun.COM> <4B3228F1.2070806@workingcode.com> <4B326539.7010003@sun.com> <4B326F0C.20500@Sun.COM> User-Agent: Thunderbird 2.0.0.23 (X11/20091013) Status: RO Content-Length: 2560 Ali Bahrami wrote: > Garrett D'Amore wrote: > > I agree with the sentiment that executable stacks should be > an opt in feature, and not tied to mapfile syntax. If you want > to change the world, this is the only comprehensive way to do that, > and my guess is that it won't break many programs. I sent mail to > some folks in the Solaris group earlier today proposing that, and > hopefully something good will come of it. > > With that, I'd like to suggest that changing the stack protections is > not this case. Agreed. > > ----- > > I'd be happy to phase out the V1 syntax, but we really have no > way of knowing who is using it, or how. I've chosen to be conservative > on this, and provide a bridge. I spent years as an ISV, and I know that > they don't appreciate having to revisit working systems, even for good > reasons. I don't want to give anyone an excuse not to stay with Solaris > over something as minor as this. The win of the v2 syntax isn't going to > be big for these folks anyway --- I would not be proposing a new syntax > if symbol versioning was the sole concern. > > There's not much cost to supporting V1, the extra code is not large, and > there's no maintenance concern. I think we should support it for a few > years, and then evaluate the situation once we're well past the > transition. > > Another point: Our Linux/GNU friends support our old symbol versioning > syntax in their linker, and there's value in making it easy for FOSS > people to write one file that works in both places. Okay. But does it make sense to at least *mark* the V1 syntax as "Obsolete", so that folks understand that there is a newer syntax that they should be moving to? > > ----- > > I just converted > 600 mapfiles in ON to the new syntax, and my feeling > is that a tool to convert them would be of limited use. The actual syntax > changes are simple and mechanical, particularly in the 99% that are > related > to symbol versioning. At the same time, I gained some big wins by > rearranging things and applying conditional input directives, and a > script can't help with that. Excellent! > > The future blog article in the case materials (new_mapfiles.html) > provides > lots of conversion examples, and will be easy to find via google. Good! > > As such, I'm not proposing such a tool as part of this case, but > agree that it might be added downstream. Fair enough. Btw, I'm not issuing a +1 on my own behalf yet, because I've not actually read your case materials. I'll endeavor to do so sometime next week. -- Garrett From Ali.Bahrami@sun.com Wed Dec 23 12:00:47 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBNK0lnk027147 for ; Wed, 23 Dec 2009 12:00:47 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nBNK0kA5011958 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 23 Dec 2009 12:00:46 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KV400M1JFL9V300@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 23 Dec 2009 12:00:45 -0800 (PST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KV4000I5FL85060@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 23 Dec 2009 12:00:44 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nBNK0iSo000360 for ; Wed, 23 Dec 2009 20:00:44 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KV400600F58U300@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 23 Dec 2009 13:00:44 -0700 (MST) Received: from [198.182.198.27] ([unknown] [199.45.162.234]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KV4009NTFL14LF0@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 23 Dec 2009 13:00:38 -0700 (MST) Date: Wed, 23 Dec 2009 13:00:37 -0700 From: Ali Bahrami Subject: Re: PSARC/2009/688 Human readable and extensible ld mapfile syntax In-reply-to: <4B3271AE.30008@sun.com> Sender: Ali.Bahrami@sun.com To: "Garrett D'Amore" Cc: John Plocher , James Carlson , PSARC-ext@sun.com, Alan Coopersmith Message-id: <4B3276E5.1080509@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B312B4B.3030405@Sun.COM> <4B313C98.4040503@sun.com> <4B314E6D.4090901@Sun.COM> <4B3228F1.2070806@workingcode.com> <4B326539.7010003@sun.com> <4B326F0C.20500@Sun.COM> <4B3271AE.30008@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090505) Status: RO Content-Length: 637 Garrett D'Amore wrote: > Okay. But does it make sense to at least *mark* the V1 syntax as > "Obsolete", so that folks understand that there is a newer syntax that > they should be moving to? Certainly. The plan is to move the existing mapfile chapter of the Linker and Libraries manual into an appendix, and to clearly indicate that it's considered to be obsolete, and that the V2 syntax is preferred. The main mapfile chapter will be replaced with the document provided in the case materials (mapfile.html) that will only discuss version 2, other than a reference to the appendix during the discussion of mapfile versions. - Ali From carlsonj@workingcode.com Wed Dec 23 12:15:18 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBNKFI3f027253 for ; Wed, 23 Dec 2009 12:15:18 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id nBNKFF9O001014; Wed, 23 Dec 2009 13:15:16 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KV400303G9FFN00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 23 Dec 2009 12:15:15 -0800 (PST) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KV40006MG9F5580@nwk-avmta-1.sfbay.Sun.COM>; Wed, 23 Dec 2009 12:15:15 -0800 (PST) Received: from relay41i.sun.com ([192.5.209.70]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nBNKFEgp003764; Wed, 23 Dec 2009 20:15:15 +0000 (GMT) Received: from mmp42es.mmp.us.syntegra.com ([160.41.221.11] [160.41.221.11]) by relay41i.sun.com with ESMTP id BT-MMP-3455334; Wed, 23 Dec 2009 20:15:14 +0000 (Z) Received: from relay41i.sun.com (relay41i.sun.com [192.5.209.70]) by mmp42es.mmp.us.syntegra.com with ESMTP id BT-MMP-11838773; Wed, 23 Dec 2009 20:15:14 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay4i.sun.com with ESMTP id BT-MMP-30117502; Wed, 23 Dec 2009 20:15:13 +0000 (Z) Received: from [10.50.24.188] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.3) with ESMTP id nBNKF7iO025659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Dec 2009 15:15:10 -0500 (EST) Date: Wed, 23 Dec 2009 15:15:07 -0500 From: James Carlson Subject: Re: PSARC/2009/688 Human readable and extensible ld mapfile syntax In-reply-to: <4B327170.1000605@sun.com> To: Rod.Evans@sun.com Cc: "Garrett D'Amore" , John Plocher , Ali Bahrami , PSARC-ext@sun.com, Alan Coopersmith Message-id: <4B327A4B.2060701@workingcode.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DCC-dmv.com-Metrics: carlson; whitelist X-Antispam: No, score=-2.6/5.0, scanned in 0.085sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4B312B4B.3030405@Sun.COM> <4B313C98.4040503@sun.com> <4B314E6D.4090901@Sun.COM> <4B3228F1.2070806@workingcode.com> <4B326539.7010003@sun.com> <4B326828.3040209@workingcode.com> <4B327170.1000605@sun.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090605) Status: RO Content-Length: 3205 Rod Evans wrote: > To stir the pot some more ... > > If we want to change the default for all applications to be that > the stack is non-executable, then why don't we have exec() do it? > We already do this for amd64, no? Because of binary compatibility. It's two different audiences. With ld.so.1 and exec(2), the audience of users is "everyone." It includes people who are receiving binaries from vendors, who may do all sorts of crazy things, including writing SMC on the stack. With ld, the audience is primarily "developers." Changing that causes no trouble for existing executables. It's only people who are creating new ones who run into the issue, and they're in a perfect position to fix the problem or work around it if needed. That's not true for the person who gets an OCO (object code only) binary from some vendor. > We try and steer away from having the ELF file be a transportation > medium for arbitrary aspects of process creation. I believe a Yep; understood. It's unfortunate that we're here. If stacks were not intended to be executable and weren't used that way from the beginning, we'd be in a different place. It's important to note that the issue (if it exists on an application) is specific to the design of that application. It's not something that the user of the application wants or needs, nor is it something that a system administrator could or should need to consider. Since needing an executable stack is a wart in the application, it's hard to see how anything other than a tag of some sort in the executable would do. I appreciate the general principle, but I don't think it applies here. > But there's also the ABI question. Under the "Managing the Process > Stack" section of the SPARC ABI, it states "On SPARC, the stack segment > is read, write, and execute permissions". Interestingly, for Intel > it states "On the Intel386, the stack has read and write permissions". > Although I believe our default for Intel is the same as SPARC. > > Our model used to be that by default we built ABI compliant applications > and by default provided an environment for ABI execution. Should we > consider these "rules" antiquated now? and default more to a secure > environment? I'm not aware of anyone really updating any ABI's > anymore, and the force of evolution seems to be de-facto standards > (meaning whatever Linux does :-). ;-} The ABI question is an excellent one. It's worth noting that applications successfully built with the modified ld (with the new default) will still be ABI-compliant. The application will never try to execute on the stack, so it'll never notice that this is restricted. The only question is what the developer must do in order to get into the case where execution on the stack is permitted as per the ABI. We require people to add a non-obvious set of libraries and toss in special compiler flags to get standards-compliant behavior, and this doesn't seem so different to me, particularly given the security and brownie point benefits. Being the last OS on the planet to disable execution on the stack probably isn't a good goal. -- James Carlson 42.703N 71.076W From Ali.Bahrami@sun.com Wed Jan 6 10:37:16 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o06IbGvg013949 for ; Wed, 6 Jan 2010 10:37:16 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o06IRfpu001540 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 6 Jan 2010 10:37:13 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KVU0062H91K2900@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 06 Jan 2010 11:36:56 -0700 (MST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KVU005I591KIA10@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 06 Jan 2010 11:36:56 -0700 (MST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o06Iatqf001281 for ; Wed, 06 Jan 2010 18:36:55 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KVU00J008EUEN00@mail-amer.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 06 Jan 2010 11:36:55 -0700 (MST) Received: from [198.182.198.27] ([unknown] [199.45.162.234]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KVU00J5Q919Q2C0@mail-amer.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 06 Jan 2010 11:36:46 -0700 (MST) Date: Wed, 06 Jan 2010 11:36:45 -0700 From: Ali Bahrami Subject: Re: PSARC/2009/688 Human readable and extensible ld mapfile syntax In-reply-to: <4B312B4B.3030405@Sun.COM> Sender: Ali.Bahrami@sun.com To: PSARC-ext@sun.com Message-id: <4B44D83D.8080209@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B312B4B.3030405@Sun.COM> User-Agent: Thunderbird 2.0.0.21 (X11/20090505) Status: RO Content-Length: 77 This case was given a verbal +1 and approved in today's meeting. - Ali