gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Axiom-developer] Re: [Gcl-devel] [Re: Executable memory: further pr


From: root
Subject: Re: [Axiom-developer] Re: [Gcl-devel] [Re: Executable memory: further programs that fail]
Date: Tue, 2 Dec 2003 08:25:43 -0500

Camm,

I believe you can query the exec-shield state by 

  cat /proc/sys/kernel/exec-shield

and probably fail to build if it is set to 1.
The user will have to be root to set it which is not required
otherwise unless they want to do a make install.

I can add it to the Axiom configure script.

I've raised objections to exec-shield on the fedora mailing
list (I'm a developer). The code has only been added in the last
two weeks so now is the time to complain. However the complaints
have been dismissed. I've read all the docs they pointed out to
me and nowhere is it explained how it helps security. It does 
hurt memory management but the basic response is "hey, nobody
REQUIRES memory to be contiguous". It's about like putting chairs
on the football field and claiming that there is nothing in the
rules that says this is illegal. Of course every team at every
game will have to play "around" the random chairs. 

I'm not sure how to fix unexec. It appears that a possible solution
will be to dynamically rebuild memory. One poster claimed that the
"randomized shared library locations" will only happen in a 100Meg
area. A possible strategy is to find the highest allocated byte
in the highest shared library, mark the area below as part of the
image and only allocate above that mark. Unexec could "save" the
shared libraries as part of the image even though they are relinked
again on restart.

In general I'm rather confused about the whole issue. I'll have to
read the unexec code in Emacs and get a real clue.

Tim




reply via email to

[Prev in Thread] Current Thread [Next in Thread]