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.
ok; committed the pax-utils.eclass, so to sort out the PaX issue on the bootstrap compiler it'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'll post here when I have some results.
Created attachment 77819 [details, diff] add PaX marking to bootstrap compiler
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
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...
meant to say - I'm away for a few days, I'll look at the execstack thing again propertly when I get back.
i wonder, where do the nested function trampolines occur in gnat? in the main executable itself or some library only? i'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.
They'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'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 'sort' (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 & hashing stuff provided by gnatlib that wouldn't require execstack. However time has been extremely short...
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: <anonymous mapping>, 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
(In reply to comment #8) > 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.
Does not look like there is going to be any activity on this in any foreseeable future. Should we close this bug with LATER?
(In reply to comment #10) > Does not look like there is going to be any activity on this in any foreseeable > future. Should we close this bug with LATER? You're right - haven't had time for over a year, that's not likely to change... There's probably very few people, if any, actually interested. Closing WONTFIX
