| Bug #11642 | [Patch]es x86 Assembler and text relocations | ||
|---|---|---|---|
| Submitted: | 29 Jun 2005 14:57 | Modified: | 8 Aug 2005 12:43 |
| Reporter: | Miguel Solorzano | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server | Severity: | S2 (Serious) |
| Version: | 4.0/4.1/5.0 | OS: | Any (all) |
| Assigned to: | Michael Widenius | CPU Architecture: | Any |
[29 Jun 2005 14:57]
Miguel Solorzano
[14 Jul 2005 21:37]
Peter Gulutzan
Suggested new /strings/longlong2str-x86.s (#1)
Attachment: longlong2str-x86.s (text/plain), 5.79 KiB.
[14 Jul 2005 21:55]
Peter Gulutzan
I believe there are two separable issues here: text relocations and executable-stack notes. I will address them separately. The text relocation issue. This appears to be the main issue. The problem is dig_vec_upper in longlong2str-x86.s. The suggested patch (call __i686.get_pc_thunk.bx, div by a memory location rather than a register) makes me (a) fearful of some compatibility issue on some unthought-of platform, (b) certain that there would be a tiny performance loss. Therefore I propose a rewritten longlong2str-x86.s where there is no reference to dig_vec_upper. It would require some further tests, but I am sure at least that the external reference is gone, and it is slightly faster than the current version on some tests that I've conducted. The inspiration was a remark by Kevin F. Quinn on the gentoo.org forum. Please check the "Files" box for this bug and see if it might be a start toward meeting your actual needs. The executable-stack notes issue. The addition of .section .note.GNU-stack, "", @progbits in every .s file seems reasonable, but I get the impression that it was thrown in because it seems reasonable, not because it's absolutely necessary to solve the original problem. I have also seen the remark (on a Red Hat forum) that this is "non-portable to non-GNU", and the suggestion that using "as --noexecstack ..." is equally reasonable. In this respect I am not pretending expertise, but admitting an ignorance which makes me reluctant to change all our .s files immediately.
[17 Jul 2005 19:16]
Peter Gulutzan
Suggested new longlong2str-x86s (#2)
Attachment: longlong2str-x86.s (text/plain), 5.79 KiB.
[17 Jul 2005 19:19]
Peter Gulutzan
The first attached file ("longlong2str-x86.s (#1)") has an error. Use "longlong2str-x86.s (#2)".
[19 Jul 2005 12:03]
Francesco Riosa
Replacing the mysql-4.0.25 ./strings/longlong2str-x86.s with the 2nd one provided generate a clean build. mysql-test-run return successfull result for both normal and hardened system (gentoo 2005.0 updated 20050718) . speaking only of the hardened system from now on: The ELF files are free of textrels as shown from "eu-findtextrel" program from "elfutils-0.108" . following the list of "[ skipped ]" tests: bdb-alter-table-1 bdb-alter-table-2 bdb-crash bdb-deadlock bdb bdb_cache lowercase_table2 lowercase_table3 openssl_1 rpl000018 rpl_chain_temp_table rpl_failsafe rpl_heap rpl_trunc_binlog extract from the "mysqlbug" utility C++ compiler: i686-pc-linux-gnu-g++ (GCC) 3.4.4 (Gentoo Hardened 3.4.4, ssp-3.4.4-1.0, pie-8.7.8) System: Linux pinksky 2.6.11-hardened-r15 #3 Mon Jul 18 19:09:16 CEST 2005 i686 AMD Athlon(tm) processor AuthenticAMD GNU/Linux Architecture: i686 Configured with: /var/tmp/portage/gcc-3.4.4/work/gcc-3.4.4/configure --enable-version-specific-runtime-libs --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.4.4 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4.4 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4.4/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4.4/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/include/g++-v3 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --disable-libunwind-exceptions --disable-multilib --disable-libgcj --enable-languages=c,c++,f77 --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu Thread model: posix
[21 Jul 2005 21:35]
Peter Gulutzan
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/internals/27447
[21 Jul 2005 21:44]
Peter Gulutzan
The patch should take care of the assembler text relocations. For gnu-stack, there will have to be a separate patch because I regard that as a different issue, and because it might have to be unapplied separately from the text-relocations patch. so I have created a new bug report: bug#12096 Add line for non-executable stack in .s files. (http://bugs.mysql.com/bug.php?id=12096&edit=1) The patch is for version 5.0. Backporting to 4.1 is recommended.
[22 Jul 2005 14:21]
Francesco Riosa
The comments mentioned from MySQL bug #12096 (trimmed). BTW the home page of the "gentoo expert" is http://pax.grsecurity.net/ , that's not me. >>>The executable-stack notes issue. The addition of >>>.section .note.GNU-stack, "", @progbits >>>in every .s file seems reasonable, but I get the impression that it was >>>thrown in because it seems reasonable, not because it's absolutely >>>necessary to solve the original problem. I have also seen the remark >>>(on a Red Hat forum) that this is "non-portable to non-GNU", and the >>>suggestion that using "as --noexecstack ..." is equally reasonable. In >>>this respect I am not pretending expertise, but admitting an ignorance >>>which makes me reluctant to change all our .s files immediately. all correct above, here's my take. 1. an extra section has to be portable to all ELF platforms, at most the linker will simply ignore it. on another note, how many i386 platforms does mysql run on that are non-GNU toolchain based yet use AT&T (i.e., UNIX) style asm? 2. there're more than two ways to deal with GNU_STACK (which i personally find a poor solution to the wrong problem btw, but we have to deal with the breakage it causes). - add a GNU-stack section to the .S - pass --{,no}execstack to as - pass -Wa,--{,no}execstack to gcc (when building the .o) - pass -Wl,--{,no}execstack to gcc (when building an executable or library) - use execstack -[sc] after build or installation (on the executable or library) as you can see, the earliest moment we can fix the problem is by adding that extra section to the .S (gcc 3.3 itself produces such as well when compiling a .c), so it's the preferred solution in general. the other solutions are acceptable as they still put the burden on the package author (we're not talking about mysql only, but all packages that a distro maintainer has to worry about), but it means that you either have to use per object ASFLAGS/LDFLAGS or mark everything without regard to their true need for executable stack - all are bound to fail and cause problems in the long run. from a distro maintenance point of view, the simplest (but still burdensome) approach is the last one, i.e., explicitly marking the binaries at the distro level, this is what (hardened) gentoo has been doing for some time now but we'd like to push these and other changes upstream. it's up to you to decide what you pick, at least i hope to have helped explain our side of the coin.
[8 Aug 2005 10:18]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/internals/27988
[8 Aug 2005 12:43]
Michael Widenius
Thank you for your bug report. This issue has been committed to our
source repository of that product and will be incorporated into the
next release.
If necessary, you can access the source repository and build the latest
available version, including the bugfix, yourself. More information
about accessing the source trees is available at
http://www.mysql.com/doc/en/Installing_source_tree.html
Additional info:
Have now pushed a slightly smaller and faster fix than the one that Peter suggested
Fix will be in 4.1.14 and 5.0.11
