Bugzilla Bug 119382

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 an attachment (id=77819) [details]
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