| 1 |
On Mon, 07 May 2007 12:08:15 +0200 |
| 2 |
pageexec@××××××××.hu wrote: |
| 3 |
|
| 4 |
> On 3 May 2007 at 14:47, Miguel Sousa Filipe wrote: |
| 5 |
> |
| 6 |
> > In LISP, data and code are one and the same, so all hardened |
| 7 |
> > profiles believe that any LISP environment is "violating" simple |
| 8 |
> > principles such has"executing data". |
| 9 |
> > |
| 10 |
> > Having heap and stack without execution permissions invalidate the |
| 11 |
> > use of LISP .. since it needs do execute data. |
| 12 |
|
| 13 |
Just to clarify here; IIRC the LISP compilers keep data for a function |
| 14 |
adjacent to the function code in the memory map. Since the data needs |
| 15 |
to be writable, this usually means the code has to be as well, since |
| 16 |
they're on the same pages. So it's not so much that it needs |
| 17 |
"executable data", but that it needs its code areas to be writable. |
| 18 |
Not only does this conflict with some basic assumptions about processes |
| 19 |
made by the kernel, it makes them expensive on embedded systems (since |
| 20 |
you cannot run the code from ROM). |
| 21 |
|
| 22 |
> > I've don't recall being able to use lisp on setups where the process |
| 23 |
> > heap is not executable. But I could be proven wrong... |
| 24 |
> |
| 25 |
> runtime code generation is very well possible under hardened setups, |
| 26 |
> it's just that it must be enabled explicitly for the apps that need |
| 27 |
> it, it's no longer granted by default. on gentoo/PaX setups you'd |
| 28 |
> use paxctl -m which is normally done by the ebuild, see e.g., java. |
| 29 |
> |
| 30 |
> however there're programs which need this exemption during build |
| 31 |
> already - that case requires more work to handle as we have to |
| 32 |
> figure out where and how to patch the build system of the given |
| 33 |
> package. there're also issues with text relocations, some of which |
| 34 |
> require serious programming work to fix (see e.g., bug 134403). |
| 35 |
|
| 36 |
(note; 134403 is about Caml - ML-ish rather than LISP as such) |
| 37 |
|
| 38 |
See also bug #154887. SBCL for example just assumes that all space is |
| 39 |
readable, writable and executable. IIRC everything built by SBCL also |
| 40 |
needs all the protections relaxed. |
| 41 |
|
| 42 |
I've had a go several times at the various LISP compilers, and came to |
| 43 |
the conclusion that it was going to be a lot of work for little gain. |
| 44 |
They're non-trivial to deal with, and we haven't had much interest |
| 45 |
expressed by hardened users so far. |
| 46 |
|
| 47 |
-- |
| 48 |
Kevin F. Quinn |
Archives