Re: [Gcl-devel] Re: Trying to build axiom

[Camm Maguire]

Greetings!  Glad to hear you've got it working.  If you are interested
and have the time, and can propose a way in which GCL can work with
these security modifications with minimal disruption to the goals of
each, this would be very helpful.  Please bear in mind though that it
could be some considerable time before we could put in any substantial
modifications, though simple ones are plausible in the short term. 

I'm not sure, but from your reports it seems as if the kernel is
detecting that code is being executed from the data section, and
killing the process with -9.  There is a rather non-optimal workaround
at present if this is the case, and that is to build with dlopen as
the linker and loader. (--disable-statsysbfd --enable-dlopen).  A few
minor patches to the axiom source are also required for this (and can
be found in the Debian axiom source package in debian/patch.*).  This
is used at the moment in porting axiom to Debian alpha, ia64,
mips(el), and hppa.  This method also has the known limitation that
the build of the axiom databases will exceed the maximum number of
open files needed for dlopen.  Tim has put in a workaround to avoid
building the databases in such cases, but from GCL's vantage point,
we'd love to be able to free ourselves from dlopen and issues like
this. 

Take care,

Peter Simons <address@hidden> writes:

> Camm Maguire writes:
> 
>  > I'm guessing that the problematic step here is the
>  > attempt to load code into pages in the executable's .data
>  > section, mprotect those pages +PROT_EXEC, and then
>  > execute the code. [...] My hunch is that these security
>  > patches have placed a similar obstacle in this sequence.
> 
> Alright, I finally managed to compile Axiom and the problem
> described above turned out to be what disturbed the build
> process all along. Here is how to fix it:
> 
>  1) Build ET_EXEC binaries by adding 
>      
>         -yet_exec -yno_propolice
> 
>     to CFLAGS. Instead of "-yno_propolice" the flag
>     "-fno-stack-protector" might also work, but should be
>     more portable. The patched GCC identifies itself as
>     follows:
> 
>         peti:/usr/local/src/axiom-current# gcc --version | head -1
>         gcc (GCC) 3.3.2 20031022 (Gentoo Linux 3.3.2-r2, propolice)
> 
>     Generally, if the compiler understands the
>     -fstack-protector flag, it's an indication that these
>     patches are active.
> 
>  2) Disable the stack protection features in the kernel
>     (PaX) for the compiled binaries with chpax(1). For
>     example:
>     
>         chpax -pEmrxs unixport/saved_gcl
> 
>     This command must be executed right after the binary has
>     been linked. If the binary is used before the chpax
>     call, the process will be killed:
> 
>         Nov 24 03:55:30 peti PAX: terminating task:
>             /usr/local/[...]/gcl-2.6.1/unixport/saved_gcl(saved_gcl):1297,
>             uid/euid: 1000/1000, PC: 085e7b00, SP: 5f3ed5ac
> 
>     And that is what disturbed the build process all the
>     time. (BTW: On some platforms chpax can be called by
>     root only; thus it would be best to make the exact shell
>     command configurable by a make variable, such as CHPAX,
>     so that people can set this to "sudo chpax" or
>     something.)
> 
> 
> Tim, there is one more problem: When I run
> ${AXIOM}/bin/axiom, clef returns the following error and
> terminates:
> 
>     clef trying to get terminal initial settings: Bad file descriptor
>     peti:/usr/local/src/axiom-current$ dup2 0 failed: Bad file descriptor
>     dup2 1 failed: Bad file descriptor
>     dup2 2 failed: Bad file descriptor
>     clef trying to dup2: Bad file descriptor
> 
> Peter
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah