From sacadmin Wed Sep 6 15:12:56 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.17.57]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k86MCu1T015715 for ; Wed, 6 Sep 2006 15:12:56 -0700 (PDT) Received: from [129.146.226.100] (chaz.SFBay.Sun.COM [129.146.226.100]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k86MCtXQ434359; Wed, 6 Sep 2006 15:12:56 -0700 (PDT) Message-ID: <44FF47BA.2040904@sun.com> Date: Wed, 06 Sep 2006 15:12:10 -0700 From: Rod Evans Reply-To: Rod.Evans@sun.com Organization: Sun Microsystems Inc. User-Agent: Mail/News 1.5.0.4 (X11/20060731) MIME-Version: 1.0 To: psarc@sac.sfbay.sun.com, ali.bahrami@sun.com CC: Rod.Evans@sun.com Subject: 2006/526: SHT_SUNW_LDYNSYM - default local symbol addition Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 18926 I'm sponsoring the following case for Ali Bahrami. Timeout Sept 13rd 2006. -------------------------------------------------------------------------- This case modifies the link-editor, ld(1), to create a new local symbol section within the text segment. This section augments the information presently available within the .dynsym. This new section will be produced by default anytime ld(1) creates a dynamic image. The new option, -znoldynsym can be used to disable the creation of this new symbol table. ------------------------------------------------------------------------- I have created a new ELF section named (SHT_SUNW_LDYNSYM), and have modified ld(1) to add one of these sections to every executable or sharable library that contains a .dynsym (SHT_DYNSYM) section. dladdr()/dladdr1() have been modified to use the extra information. The purpose of this new section is to allow us to produce accurate stack traces for non-global functions in processes that have been stripped, and without the need to examine the file image of the running program. I tried several alternative implementations to solve this problem along the path to this solution. The purpose of this document is to: 1) Explain the motivation for this new feature 2) Describe how the dynsym is located and accessed by client software. 3) Describe the alternative approaches that were considered and and rejected as this project evolved. 4) Describe the solution that I plan to integrate back into Solaris. Background: ----------- ELF files are usually constructed with a symbol table (symtab) that can be used to locate all of the symbols within the file. This table is found in the file, but is not "allocable", meaning that it is not mapped into the address of a running process and cannot be examined at runtime by a program using the file. Symbol tables are required by the linker, but cannot be used at runtime, and are often stripped from the resulting executable or sharable library. The runtime linker has a need to locate global symbols found within dynamic executables and sharable libraries at runtime, using only data visible in the mapped segments of the code (the allocable sections). For this purpose, a second symbol table (the dynsym) is placed in the file. In contrast to the regular symbol table, this symbol table is allocable, which makes it readable at runtime. The program headers point at the "dynamic" section of the image, and the dynamic section in turn can be used to find the dynsym as well. The dynsym is the minimal subset of the symtab required by the runtime linker to do its job. Over the years, the concept of observability has become a critical part of the design of Solaris. The ability to easily examine and understand what is happening within programs is an important advantage of our system relative to others. When we attempt to provide a stack trace for a running program that has been stripped (no symtab is present), we are unable to show the names of any non-global functions, because they do not exist in the dynsym. This issue comes up in cases such as: 4821429 Need mapfile option (or ld option) to remove non-FUNC LOCL Elf symbols The runtime linker itself is unable to use the symtab even if it does exist, which leads to: 4934427 runtime linker should load up static symbols names visible to dladdr() We have long thought that the local function symbol information necessary to improve these situations could be added to our ELF files without breaking existing code, and that the resulting ELF files would see a small and acceptable increase in size. This is a simple alternative to other more complex ideas (mapfile options, etc) sometimes proposed to address this same issue. The presence of local function symbols in the running process would allow better results from several routines and tools: dladdr(3C) / dladdr1(3C) walkcontext(3C) / printstack(3C) libproc (e.g. pstack(1)) Debuggers (dbx, mdb, etc...), when used on stripped files In other words, any situation where the dynsym is the only source of available symbol information and we want to look at the call stack will benefit from this change. The ability to work with stripped files found in production at customer sites, without requiring code to be rebuilt or instrumented, is valuable, and worth a small amount of additional space. How The Dynsym Is Accessed -------------------------- Traditionally, the .dynamic section of a dynamic ELF file contains 5 items necessary to access the dynsym from within a running program (i.e. by ld.so.1): DT_SYMTAB - Starting address of the dynsym DT_SYMENT - Size in bytes of a single symbol entry in the dynsym (used to distinguish 32 and 64-bit symbol tables). DT_HASH - Hash table used by the runtime linker to speed symbol lookup. The "nchain" item in the hash table also gives the number of items in the dynsym. DT_STRTAB - String table containing the name strings referenced by the dynsym. DT_STRSZ - Size of the string table. There is a 1-1 correspondence between the dynsym and the hash table, with the hash table containing 0-based offsets into the dynsym from the address given by DT_SYMTAB. Any change to the dynsym layout must preserve this, or existing code will break. The existing ON code base accesses the dynsym in one of two ways: 1) Use the section header to locate the dynsym and determine it's size (and hence, the number of symbols), and then access it linearly. This approach is used by programs that access the ELF files, especially the linker, but also debuggers and other tools. 2) Use the information in the dynamic section to locate the dynsym. This approach is used by software that must examine the address space of a running process (primarily the runtime linker ld.so.1). It turns out that only the runtime loader (ld.so.1) uses the hash table to locate symbols, and that the other accesses are all linear as with the previous case. If possible, it would be highly desirable to add the additional local function symbols to the existing dynsym. That approach has the best chance of allowing existing software to benefit from the added information without having to first be modified to see it. Such a change must be done in a way that does not break backward compatibility with existing systems and files. After several iterations, I have come to the realization that this is not possible, and that a separate section is needed. [Rejected] Solution #1: Hash Local Symbols ---------------------------------------- The first approach considered was to simply add local function symbols to the dynsym, and also include them in the hash table. This approach was rejected immediately (no prototype was done) for two reasons: i) It puts a runtime burden on the runtime loader to recognize and not use local symbols, and we are unwilling to reduce runtime performance. ii) Multiple local symbols with the same name can exist, and a global symbol of the same name is also possible. The hash table assumes a single symbol per name. [Rejected] Solution #2: Local symbols At End Of Dynsym ---------------------------------------------------- I prototyped a version of the linker in which local function symbols are added at the end of the dynsym, and not added to the hash table. A new element was added to the dynamic section to specify how many such local symbols are present, so that the runtime linker could find them for use by dladdr() and dladdr1(). This solution has the benefit of functioning properly with existing code, without requiring any changes to that code. The prototype worked, but this approach was rejected because the symbol table that results is malformed. A proper symbol table puts the scope reduced global symbols at the beginning, followed by the local symbols, with the global symbols coming at the end. We want debuggers that already examine the dynsym to be able to use these new symbols without requiring those debuggers to be modified. To ensure this, the dynsym must follow the same rules used to lay out the symtab. Hence, local symbols have to come at the head of the table, before the global symbols. [Rejected] Solution #3: Local symbols At Head Of Dynsym ----------------------------------------------------- This approach is based on two observations: 1) Software that accesses the dynsym via the section headers will see any additional local symbols we might place there and will use them correctly without requiring any code changes within that software, while access to the global symbols will not be impaired. 2) Software that accesses the dynsym via the dynamic section will continue to work correctly even if we add additional symbols to the dynsym, as long as the relationship between the DT_SYMTAB, DT_SYMENT, DT_HASH, DT_STRTAB, and DT_STRSZ items are maintained. In particular, there is no requirement that DT_SYMTAB reference the actual start of the dynsym section, only that it point at the first global symbol and be consistent with those other items. As such, the idea is to add the local function symbols at the beginning of the dynsym, following the same rules used for symtab. The global symbols are placed at the end, immediately following the local part. DT_SYMTAB continues to reference the start of the global symbols, and DT_HASH continues to be correctly interpreted relative to that address (and the hash chainsize continues to give the size of the global part of the dynsym). Other sections that parallel the dynsym (versym and syminfo) are taken in relative to DT_SYMTAB, and as such do not waste unnecessary space on the local symbols. Software that uses the dynamic section in the old way will continue to see consistent and correct global symbol information. To access the entire dynsym, including the local symbols, two new dynamic entries are used to communicate the new data: [DT_SUNW_SYMTAB] References the top of the dynsym. [DT_SUNW_SYMSZ] The total size of the dynsym (including both local and global symbols). This value corresponds to the section data size recorded in the section header. Software that accesses the dynsym via the dynamic section that would benefit from local symbol information (e.g. dladdr(3C)) can easily obrain that data by using these new items. This solution satisfies both of the observations noted at the start of this section: 1) Software that accesses the dynsym via section headers will operate correctly, and benefit from the additional local symbols. 2) Software that accesses the dynsym via the dynamic section to do linking (i.e. via DT_SYMTAB) will continue to see the correct information and the hashtable will function correctly. This change is completely compatible with pre-existing dynamic ELF files: Files that lack DT_SUNW_SYMTAB continue to work as they always have, without any additional cost. It is interesting to note that very little software had to change in order to benefit from this: - elfdump(1) required a small change - dladdr(3C) was changed to use the new DT_SUNW_SYMTAB item if present. - libproc (pstack) received a change to improve it's ability to examine a process for which the original ELF file is not available. This is a minor change, since libproc usually gets this information via the symtab of the file on disk rather than from memory. The dbx and mdb debuggers are able to see the new symbols without having to be updated first. There is one situation in which this change to the dynsym can cause problems to existing code: - The program uses the ELF section headers to locate the dynsym instead of accessing it via the DT_SYMTAB entry. - It uses the DT_HASH section to determine the length instead of getting that from the section header. It should be noted that this is inconsistent: If the address and size are obtained from the same source (from the section headers, or from the dynamic section) as intended, the results will always be correct. It is only when the address comes from one source and the size from another that things go wrong. I found very few instances of this in ON (in tools like elfdump), and do not believe it would occur in user code. This solution is very compelling. It adds a moderate amount of complexity to the linker, but in return requires very little from other software. Unfortunately, it has a flaw: An ELF file that contains such an augmented dynsym will cause problems if copied backwards to an older version of Solaris where the linker does not understand DT_SUNW_SYMTAB: - ld will handle relocations incorrectly, producing a bad result file (that may start and run for an unknown amount of time before failing). The existing linker assumes that DT_SYMTAB references the head of the dynsym section. - Both ld and rtld will be confused about the parallel sections (versym and syminfo) that are supposed to line up with dynsym. - In both cases above, the result will be confusing error messages resulting from a confused linker, instead of a clean version mismatch error message. In principle, one might argue that data files produced by new linkers should not be required to work properly with an older linker. The backward compatibility that we promise is that old files will continue to work on new systems, not that new files will run on old systems. Despite this, I believe we have to reject this approach. Taking a pragmatic view, we know that users will do this, sometimes willfully, and sometimes without realizing that they are (e.g. an NFS environment with machines at different OS levels). The resulting confusion will lead to unnecessary complaints, bug reports, and unfortunate publicity relative to other operating systems. Those other systems will be portrayed as being more concerned with backward compatibility, our historical strength. This is a scenario that cannot be allowed to happen. Alternatively, one might make this feature optional. We know that most users will not set an optional feature (or even know it is there). This will prevent them from creating files with backward compatibility issues. We can then proceed to use it within Solaris immediately. In time, the old versions of Solaris that do not understand the feature will be flushed out of our support pipeline. At that point, we could move to make the feature be the default. The problem with this is that it defers the user visible benefits into the indefinite future, years from now. I would prefer to do something that pays off now in a concrete way, even if it is a little less elegant as a result. For these reasons, I rejected this option, despite my feeling that it would have been a nice solution going forward. The layout and use of the dynsym is highly constrained by existing practice --- to the point where it is not possible to make a change of this nature without causing an unacceptable compatibility problem. Solution #4: A Separate Section For Local Function Symbols ---------------------------------------------------------- Since we cannot change the dynsym, a reasonable fallback solution is to create another allocable symbol table to contain the local function symbols. I have chosen to name this the ldynsym. A given ELF file is only supposed to have a single SHT_DYNSYM section, so this new section has a new section type (SHT_SUNW_LDYNSYM). As a consequence of using a separate section with a new section type, we can guarantee that old ELF software that doesn't understand the new section will ignore it, and continue to run as before, while new SHT_SUNW_LDYNSYM aware software can benefit from it. The implementation of this solution required fewer deep changes to the linker, but does shift some complexity to the clients. Mdb, libproc, and dbx will all require minor modifications to make use of the new information. Absent such modification, they will all work the same way as before, with no degradation. In our previous "Rejected Solution #3: Local symbols At Head Of Dynsym", we constructed a symbol table that contained local symbols at the top, with globals following. In this solution, we put the local part of that symbol table in the ldynsym, leaving the dynsym to hold only the global symbols as before. The linker, ld(1), takes care to place the data section of the ldynsym directly in front of, and adjacent to, the dynsym. We then place two new items in the dynamic section of the resulting ELF file: [DT_SUNW_SYMTAB] References the top of the ldynsym. [DT_SUNW_SYMSZ] The total size of both the ldynsym and the dynsym. Using DT_SUNW_SYMTAB, the runtime linker sees the full symbol table with both local and global symbols, even though those are really two separate ELF sections. I believe that other software should be able to take advantage of the same trick to simplify the changes necessary to take advantage of the local symbols. By its nature, a feature like this is vastly more useful when it is on by default. Otherwise, it generally will not be available when it is needed, since situations where a stack trace is needed are usually unplanned emergencies. The decision to generate an ldynsym by default implies a decision to accept a slight increase in ELF file size. Before such a decision can be made, it is important to understand the amount by which the files will grow. To do this, I did two full nightly builds of the ON consolidation. One was an unaltered workspace, while the other contained my code changes. The overall increase in size of the proto area was 1.4%. The increase to a given file is directly proportional to the number of local functions it contains. Hence, the per-library increase varies on a case by case basis. For example, the overall increase is 1.4%, but the increase in libc.so.1 is about 5%. I feel that a 1.4% increase is small enough to leave the feature on by default. I have provided a command line option (-znoldynsym) to disable it. Conclusions ----------- The availability of local function symbols in the allocable region of ELF binaries allows us to generate accurate stack trace information. The amount of additional space required to do so is small, and the resulting improvement in Solaris observability is worthwhile. Ideally, these symbols would be added to the existing dynsym section. However, experimentation has convinced me that the backward compatibility issues constrain the options to the point where this isn't possible. Therefore, an alternative implementation, using a separate ldynsym section, is the best way forward. I have completed the work necessary to implement this solution, and wish to integrate the results. ------------------------------------------------------------------------- Release Binding: Patch/Micro SHT_SUNW_LDYNSYM: Committed -znoldynsym: Committed -- Rod. From sacadmin Fri Sep 8 04:47:42 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k88BlgSZ004715 for ; Fri, 8 Sep 2006 04:47:42 -0700 (PDT) Received: from gmpea-pix-1.sun.com (gmpes-gis-mail-1.UK.Sun.COM [129.156.42.5]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k88Blf3I009602 for ; Fri, 8 Sep 2006 04:47:41 -0700 (PDT) Received: from d1-emea-09.sun.com (d1-emea-09.sun.com [192.18.2.119] (may be forged)) by gmpea-pix-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k88BlZE2011248 for ; Fri, 8 Sep 2006 12:47:36 +0100 (BST) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J5900G01UJ7KZ00@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc@sac.sfbay.sun.com; Fri, 08 Sep 2006 12:47:35 +0100 (BST) Received: from [129.150.120.189] by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J5900B9PVF6CK20@d1-emea-09.sun.com>; Fri, 08 Sep 2006 12:47:31 +0100 (BST) Date: Fri, 08 Sep 2006 12:47:28 +0100 From: Darren J Moffat Subject: Re: 2006/526: SHT_SUNW_LDYNSYM - default local symbol addition In-reply-to: <44FF47BA.2040904@sun.com> Sender: Darren.Moffat@Sun.COM To: Rod.Evans@Sun.COM Cc: psarc@sac.sfbay.sun.com, Ali.Bahrami@Sun.COM Message-id: <45015850.5040707@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <44FF47BA.2040904@sun.com> User-Agent: Mail/News 1.5.0.4 (X11/20060731) Status: RO Content-Length: 176 Is this new section included in the elfsign(1) signature ? Should it be ? I don't think it needs to be since it doesn't impact runtime execution does it ? -- Darren J Moffat From sacadmin Fri Sep 8 09:45:11 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k88GjBOc011369 for ; Fri, 8 Sep 2006 09:45:11 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k88GjAY3001752 for ; Fri, 8 Sep 2006 09:45:10 -0700 (PDT) Received: from fe-amer-02.sun.com ([192.18.108.176]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k88GjAkU019298 for ; Fri, 8 Sep 2006 10:45:10 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J5A00G018XMBM00@mail-amer.sun.com> (original mail from Ali.Bahrami@Sun.COM) for psarc@sac.sfbay.sun.com; Fri, 08 Sep 2006 10:45:10 -0600 (MDT) Received: from [172.20.25.67] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J5A00M1Y9799TL2@mail-amer.sun.com>; Fri, 08 Sep 2006 10:45:10 -0600 (MDT) Date: Fri, 08 Sep 2006 10:45:59 -0600 From: Ali Bahrami Subject: Re: 2006/526: SHT_SUNW_LDYNSYM - default local symbol addition In-reply-to: <45015850.5040707@Sun.COM> Sender: Ali.Bahrami@Sun.COM To: Darren J Moffat Cc: Rod.Evans@Sun.COM, psarc@sac.sfbay.sun.com Message-id: <45019E47.1000505@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <44FF47BA.2040904@sun.com> <45015850.5040707@Sun.COM> User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050930) Status: RO Content-Length: 1087 Darren J Moffat wrote: > Is this new section included in the elfsign(1) signature ? > Should it be ? I don't think it needs to be since it doesn't > impact runtime execution does it ? > > -- > Darren J Moffat I believe it is. Looking at usr/closed/lib/libelfsign/common/elfsignlib.c it appears that any section that has the SHF_ALLOC flag set (meaning it is mapped into the process) is included. I think this is the right thing, though your point is correct that it doesn't impact runtime execution (much). ldynsym contains data that can be used by dladdr() at runtime. An altered ldynsym could cause dladdr() to give different results. So there is a (minor) impact on runtime execution. Given that ldynsym mostly lies there and doesn't get looked at much by a running program, it would be a reasonable place to stash some malicious data. Having it be part of the signing computation closes off that possibility. And then, there's the simplicity angle: The "if we load it into memory, we include it in the signing computation" story is easy to remember and defend. - Ali From sacadmin Fri Sep 8 10:57:28 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k88HvSge015124 for ; Fri, 8 Sep 2006 10:57:28 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k88HvROL011090 for ; Fri, 8 Sep 2006 10:57:27 -0700 (PDT) Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k88HvRVW026396 for ; Fri, 8 Sep 2006 11:57:27 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J5A00B01C1W8S00@mail-amer.sun.com> (original mail from Ali.Bahrami@Sun.COM) for psarc@sac.sfbay.sun.com; Fri, 08 Sep 2006 11:57:27 -0600 (MDT) Received: from [172.20.25.67] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J5A00BTKCJRAOQ0@mail-amer.sun.com>; Fri, 08 Sep 2006 11:57:27 -0600 (MDT) Date: Fri, 08 Sep 2006 11:58:16 -0600 From: Ali Bahrami Subject: Re: 2006/526: SHT_SUNW_LDYNSYM - default local symbol addition In-reply-to: <45019E47.1000505@sun.com> Sender: Ali.Bahrami@Sun.COM To: psarc@sac.sfbay.sun.com, Rod Evans , Roch.Bourbonnais@Sun.COM, Pierre.Rogier@Sun.COM Message-id: <4501AF38.8060200@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <44FF47BA.2040904@sun.com> <45015850.5040707@Sun.COM> <45019E47.1000505@sun.com> User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050930) Status: RO Content-Length: 2941 The following message came to me offline. I'm sending it and my answers to the entire psarc list so that it becomes part of the record for this case. > Date: Thu, 07 Sep 2006 12:56:17 +0200 > From: Pierre Rogier > Subject: Re: [Fwd: 2006/526: SHT_SUNW_LDYNSYM - default local symbol addition] > To: Roch - PAE > Cc: Rod.Evans@sun.com > > Hi Roch, Hi Rod. > > That is indeed interesting, since most of the core we get from customers > come from stripped optimized binaries. > I wonder whether we should not also add a new option (unset by default) > to "strip" command to be able to get rid of the new section. > > I also wonder if it will not solve the issue ( unable to backtrack > through some of the static function ) > that we have with pstack on x86 binaries that use some binaries > compiled with gcc and some with workshop. > > Pierre Stripping ldynsym ----------------- This new ldynsym is an allocable section, and it resides in the text segment of the mapped image. That means that it cannot be stripped in the usual way (as with debug sections or the non-allocable .symtab symbol table). It would be possible to leave the ldynsym in place and zero the data it contains, perhaps with a new option to mcs(1). The problem with that idea is that the names of the symbols will still remain in the dynamic string table (which is shared with the standard dynsym). It is not a simple matter to zero out these strings, because a single string can be referenced by more than one place in an ELF file (a memory saving optimization). The use of object obfuscation to hide algorithms is highly dubious, but there are people who insist on doing it anyway. I doubt that zeroing the ldynsym but leaving the strings behind would satisfy those people. As such, I believe that suppressing the ldynsym at link time is the best and only real solution to their concerns. For this reason, I am not planning to implement an after-link removal option for ldynsym. I will make sure that the ld(1) manpage discussion of the -znoldynsym option explains clearly that the section cannot be stripped, and that people with a desire to hide local symbol names should be sure to include -znoldynsym in their links. pstack ------ The new ldynsym section will allow us to improve libproc, and by extension pstack(1) to show us local functions in the stack trace even when the executable has been stripped. The same is true for mdb, or dbx. However, each of these will have to be modified to understand and examine the ldynsym first. These changes should not be too difficult. I intend to pursue them in a follow up project once ldynsym in in place. The only caveat to this is that programs linked with the GNU ld (as opposed to our own Solaris linker) will not contain ldynsym sections, and so pstack will still be unable to show local functions in own of those programs. - Ali From sacadmin Fri Sep 8 10:59:32 2006 Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k88HxWEF015164 for ; Fri, 8 Sep 2006 10:59:32 -0700 (PDT) Received: from [129.146.108.62] (vinifera.SFBay.Sun.COM [129.146.108.62]) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) with ESMTP id k88HxVP12133; Fri, 8 Sep 2006 10:59:31 -0700 (PDT) Message-ID: <4501AF83.1040805@sun.com> Date: Fri, 08 Sep 2006 10:59:31 -0700 From: Scott Rotondo User-Agent: Mail/News 1.5.0.4 (X11/20060718) MIME-Version: 1.0 To: Ali Bahrami CC: Darren J Moffat , Rod.Evans@sun.com, psarc@sac.sfbay.sun.com Subject: Re: 2006/526: SHT_SUNW_LDYNSYM - default local symbol addition References: <44FF47BA.2040904@sun.com> <45015850.5040707@Sun.COM> <45019E47.1000505@sun.com> In-Reply-To: <45019E47.1000505@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1295 Ali Bahrami wrote: > Darren J Moffat wrote: >> Is this new section included in the elfsign(1) signature ? >> Should it be ? I don't think it needs to be since it doesn't >> impact runtime execution does it ? >> >> -- >> Darren J Moffat > > I believe it is. Looking at > > usr/closed/lib/libelfsign/common/elfsignlib.c > > it appears that any section that has the SHF_ALLOC flag > set (meaning it is mapped into the process) is included. > > I think this is the right thing, though your point is correct > that it doesn't impact runtime execution (much). > > ldynsym contains data that can be used by dladdr() at runtime. > An altered ldynsym could cause dladdr() to give different results. > So there is a (minor) impact on runtime execution. > > Given that ldynsym mostly lies there and doesn't get looked > at much by a running program, it would be a reasonable place > to stash some malicious data. Having it be part of the signing > computation closes off that possibility. > > And then, there's the simplicity angle: The "if we load it into > memory, we include it in the signing computation" story is easy to > remember and defend. > > - Ali Exactly right. This is why we had libelfsign check for the SHF_ALLOC flag rather than hard-coding a list of ELF sections. Scott From sacadmin Mon Sep 11 03:27:53 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k8BARrbO024153 for ; Mon, 11 Sep 2006 03:27:53 -0700 (PDT) Received: from gmpea-pix-1.sun.com (gmpes-gis-mail-2.UK.Sun.COM [129.156.42.6]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k8BARpYq015692 for ; Mon, 11 Sep 2006 03:27:52 -0700 (PDT) Received: from d1-emea-10.sun.com ([192.18.2.120]) by gmpea-pix-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k8BARjb5026684 for ; Mon, 11 Sep 2006 11:27:46 +0100 (BST) Received: from conversion-daemon.d1-emea-10.sun.com by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J5F00D01BO31R00@d1-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc@sac.sfbay.sun.com; Mon, 11 Sep 2006 11:27:45 +0100 (BST) Received: from [129.150.120.189] by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J5F007Y7BQ9BH10@d1-emea-10.sun.com>; Mon, 11 Sep 2006 11:27:45 +0100 (BST) Date: Mon, 11 Sep 2006 11:27:41 +0100 From: Darren J Moffat Subject: Re: 2006/526: SHT_SUNW_LDYNSYM - default local symbol addition In-reply-to: <45019E47.1000505@sun.com> Sender: Darren.Moffat@Sun.COM To: Ali Bahrami Cc: Rod.Evans@Sun.COM, psarc@sac.sfbay.sun.com Message-id: <45053A1D.4090003@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <44FF47BA.2040904@sun.com> <45015850.5040707@Sun.COM> <45019E47.1000505@sun.com> User-Agent: Mail/News 1.5.0.4 (X11/20060731) Status: RO Content-Length: 689 Ali Bahrami wrote: > Darren J Moffat wrote: >> Is this new section included in the elfsign(1) signature ? >> Should it be ? I don't think it needs to be since it doesn't >> impact runtime execution does it ? >> >> -- >> Darren J Moffat > > I believe it is. Looking at > > usr/closed/lib/libelfsign/common/elfsignlib.c > > it appears that any section that has the SHF_ALLOC flag > set (meaning it is mapped into the process) is included. > > I think this is the right thing, though your point is correct > that it doesn't impact runtime execution (much). Okay thanks, I missed that fact that it could have a small runtime impact. This all looks good to me. -- Darren J Moffat From sacadmin Wed Sep 27 12:23:24 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.108.31]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k8RJNNQc029280 for ; Wed, 27 Sep 2006 12:23:23 -0700 (PDT) Received: from [129.146.226.100] (chaz.SFBay.Sun.COM [129.146.226.100]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k8RJNNki329303; Wed, 27 Sep 2006 12:23:23 -0700 (PDT) Message-ID: <451ACF77.50903@sun.com> Date: Wed, 27 Sep 2006 12:22:31 -0700 From: Rod Evans Reply-To: Rod.Evans@sun.com Organization: Sun Microsystems Inc. User-Agent: Mail/News 1.5.0.4 (X11/20060731) MIME-Version: 1.0 To: PSARC@sac.sfbay.sun.com CC: Sherri.Shieh@sun.com, Ed.Gould@sun.com, Ali Bahrami Subject: 2006/526: SHT_SUNW_LDYNSYM - default local symbol addition Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 58 Case has been marked as closed and approved. -- Rod.