<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "http://bugs.gentoo.org/bugzilla.dtd">

<bugzilla version="2.22.7"
          urlbase="http://bugs.gentoo.org/"
          maintainer="bugzilla@gentoo.org"
>

    <bug>
          <bug_id>119382</bug_id>
          
          <creation_ts>2006-01-18 00:03 0000</creation_ts>
          <short_desc>Hardened support for gnat</short_desc>
          <delta_ts>2008-02-04 21:03:33 0000</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>Gentoo Linux</product>
          <component>Development</component>
          <version>unspecified</version>
          <rep_platform>All</rep_platform>
          <op_sys>Linux</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>WONTFIX</resolution>
          <bug_file_loc>http://dev.gentoo.org/~kevquinn/gnat</bug_file_loc>
          
          
          <priority>P2</priority>
          <bug_severity>normal</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          
          <everconfirmed>1</everconfirmed>
          <reporter>kevquinn@gentoo.org</reporter>
          <assigned_to>kevquinn@gentoo.org</assigned_to>
          <cc>ada@gentoo.org</cc>
    
    <cc>esigra@gmail.com</cc>
    
    <cc>pageexec@freemail.hu</cc>
    
    <cc>stoile@anderedomain.de</cc>

      

      
          <long_desc isprivate="0">
            <who>kevquinn@gentoo.org</who>
            <bug_when>2006-01-18 00:03:18 0000</bug_when>
            <thetext>This bug is for issues related to using gnat on hardened systems.

The first issue is for PaX kernels, which kill the bootstrap compiler when it tries to use a trampoline.  Adding the appropriate PaX marking to the gnat1 compiler is sufficient to overcome this.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>kevquinn@gentoo.org</who>
            <bug_when>2006-01-22 06:51:56 0000</bug_when>
            <thetext>ok; committed the pax-utils.eclass, so to sort out the PaX issue on the bootstrap compiler it&apos;s enough to inherit pax-utils and add:

pax-mark -execstack $(find ${GNATBOOT} -name gnat1)

to the base_unpack) section in gnatbuild.eclass (patch to follow for clarity).


The remaining issues for hardened are the possibility of removing the requirement for executable stack from the compiler itself and gnatlib.

I&apos;ll post here when I have some results.


</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>kevquinn@gentoo.org</who>
            <bug_when>2006-01-22 06:52:41 0000</bug_when>
            <thetext>Created an attachment (id=77819)
add PaX marking to bootstrap compiler

</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>george@gentoo.org</who>
            <bug_when>2007-02-15 15:28:22 0000</bug_when>
            <thetext>Hi Kevin

Thanks for this fix! And sorry for delay - my stored ada search did not look for ada@g.o in CC :(. Anyway, I added this fix (tested on non-hardened system Ok) to the eclass.

Also, what about the execstacks? Is there any reasonable possibility of it being fixed or should we simply QA mark necessary files and forget about it?

George</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>kevquinn@gentoo.org</who>
            <bug_when>2007-02-15 22:54:42 0000</bug_when>
            <thetext>ooh; that patch was somewhat out of date :)
the line needs to be:

pax-mark E $(find ${GNATBOOT} -name gnat1)

sorry about that.

re removing the execstacks in gnatlib - no progress yet (!) - been doing other stuff.  I think more instances have been added since I last looked...</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>kevquinn@gentoo.org</who>
            <bug_when>2007-02-15 22:56:43 0000</bug_when>
            <thetext>meant to say - I&apos;m away for a few days, I&apos;ll look at the execstack thing again propertly when I get back.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>pageexec@freemail.hu</who>
            <bug_when>2007-04-24 10:09:33 0000</bug_when>
            <thetext>i wonder, where do the nested function trampolines occur in gnat? in the main executable itself or some library only? i&apos;m asking it because in the former case gcc/ld should have already marked the executable with -E. also, are we really talking about the gcc style nested function trampolines here at all? the EMUTRAMP logic assumes/emulates specific insn sequences only, if gnat has its own, they need to be added explicitly in PaX.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>kevquinn@gentoo.org</who>
            <bug_when>2007-04-24 18:18:24 0000</bug_when>
            <thetext>They&apos;re in a library, and in code that forms part of the compiler driver.  Once the bootstrap is marked, the compilation successfully builds gnat1 (the Ada compiler driver) with the correct markings.

We are talking standard GCC trampolines (the backend is the unchanged).  It&apos;s natural in Ada to express nested subprograms; on strict Ada83 and Ada95 standard compilers these are implementable without a trampoline (since the language restricts calls to nested subprograms to the scope of their _declaration_ rather than just the scope of their runtime creation).  The GNAT people however extended the language to provide the C-style ability to reference a nested function outside of the scope of its declaration (and introduced the ability therefore to write bad code that called such nested functions when they are out of their run-time scope), so they could implement things like a generic &apos;sort&apos; (IIRC) the same way the C library does.  I had hoped to rewrite the relevant sections of the Ada front-end to eliminate the execstack requirement from the compiler, and also to look at providing a variation of the sort &amp; hashing stuff provided by gnatlib that wouldn&apos;t require execstack.  However time has been extremely short...
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>stoile@anderedomain.de</who>
            <bug_when>2007-09-05 12:09:22 0000</bug_when>
            <thetext>Which versions of gnat are fixed for pax kernels? I get this error:

Sep  4 22:52:29 chris PAX: From 192.168.0.6: execution attempt in: &lt;anonymous mapping&gt;, 5c21d000-5c235000 5c21d000
Sep  4 22:52:29 chris PAX: terminating task: /var/tmp/portage/dev-lang/gnat-gcc-3.4.6/work/usr/bin/gnat1(gnat1):15369, uid/euid: 250/250, PC: 5c2301e0, SP: 5c23018c
Sep  4 22:52:29 chris PAX: bytes at PC: b9 10 02 23 5c e9 96 91 fa ab 00 00 30 e0 00 00 b9 10 02 23 
Sep  4 22:52:29 chris PAX: bytes at SP-4: 5c2301a8 081235ec 00000001 00000000 5c2301a8 5c2301b0 00000003 00000001 5c230228 081d9498 00000003 5c2301e0 5c2301f0 0000e030 5c2301e0 081170a2 5c230190 0000e030 00005133 00005134 00000003 
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>pageexec@freemail.hu</who>
            <bug_when>2007-09-14 07:07:30 0000</bug_when>
            <thetext>(In reply to comment #8)
&gt; Which versions of gnat are fixed for pax kernels?

i think none is, the short term solution should be to paxctl -E gnat1 and other executables that link to the libraries with trampolines.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>george@gentoo.org</who>
            <bug_when>2008-01-23 22:05:37 0000</bug_when>
            <thetext>Does not look like there is going to be any activity on this in any foreseeable future. Should we close this bug with LATER?</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>kevquinn@gentoo.org</who>
            <bug_when>2008-02-04 21:03:33 0000</bug_when>
            <thetext>(In reply to comment #10)
&gt; Does not look like there is going to be any activity on this in any foreseeable
&gt; future. Should we close this bug with LATER?

You&apos;re right - haven&apos;t had time for over a year, that&apos;s not likely to change...
There&apos;s probably very few people, if any, actually interested.

Closing WONTFIX</thetext>
          </long_desc>
      
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>77819</attachid>
            <date>2006-01-22 06:52 0000</date>
            <desc>add PaX marking to bootstrap compiler</desc>
            <filename>gnatbuild.eclass.diff</filename>
            <type>text/plain</type>
            <data encoding="base64">SW5kZXg6IGduYXRidWlsZC5lY2xhc3MKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL3Zhci9jdnNyb290
L2dlbnRvby14ODYvZWNsYXNzL2duYXRidWlsZC5lY2xhc3MsdgpyZXRyaWV2aW5nIHJldmlzaW9u
IDEuMgpkaWZmIC11IC1iIC1CIC1yMS4yIGduYXRidWlsZC5lY2xhc3MKLS0tIGduYXRidWlsZC5l
Y2xhc3MJMTggSmFuIDIwMDYgMDA6MzI6MDcgLTAwMDAJMS4yCisrKyBnbmF0YnVpbGQuZWNsYXNz
CTIyIEphbiAyMDA2IDE0OjUwOjMyIC0wMDAwCkBAIC02LDcgKzYsNyBAQAogIyBzZXQgSE9NRVBB
R0UgYW5kIExJQ0VOU0UgaW4gYXBwcm9wcmlhdGUgZWJ1aWxkLCBhcyB3ZSBoYXZlCiAjIGduYXQg
ZGV2ZWxvcGVkIGF0IHR3byBsb2NhdGlvbnMgbm93LgogCi1pbmhlcml0IHZlcnNpb25hdG9yIHRv
b2xjaGFpbi1mdW5jcyBmbGFnLW8tbWF0aWMgbXVsdGlsaWIKK2luaGVyaXQgdmVyc2lvbmF0b3Ig
dG9vbGNoYWluLWZ1bmNzIGZsYWctby1tYXRpYyBtdWx0aWxpYiBwYXgtdXRpbHMKIAogRVhQT1JU
X0ZVTkNUSU9OUyBwa2dfc2V0dXAgc3JjX3VucGFjayBzcmNfY29tcGlsZSBzcmNfaW5zdGFsbAog
CkBAIC0yNTcsNiArMjU3LDcgQEAKIAljYXNlICQxIGluCiAJCWJhc2VfdW5wYWNrKQogCQkJdW5w
YWNrICR7QX0KKwkJCXBheC1tYXJrIC1leGVjc3RhY2sgJChmaW5kICR7R05BVEJPT1R9IC1uYW1l
IGduYXQxKQogCQk7OwogCiAJCWNvbW1vbl9wcmVwKQo=
</data>        

          </attachment>
    </bug>

</bugzilla>