Matt Domsch wrote regarding gcl (GNU Common Lisp):
gcl-2.6.7-18.fc9 [u'440913 ASSIGNED'] (build/make) gemi,green
I would rather like to let die. It is a pain and does not build anymore on any architecture. Maybe someone have a try with it?
From: G?rard Milmeister gemi@bluewin.ch
Tried that too. However that Fedora memory management and security features get in the way.
Dropping gcl is a bad idea. gcl generates much better code in many cases; dropping makes Fedora bad for running Common Lisp (CL) applications. There are a lot of CL programs, and CL is still important; "Practical Common Lisp" was published 2005 and was a really popular book.
For example, performance figures for ACL2 are here: http://www.cs.utexas.edu/users/moore/acl2/current/new.html#performance gcl is 20% faster on 64-bit, and 32% faster on 32-bit,, compared to the next-best implementation available on Fedora.
This may illustrate a larger security issue: the Fedora memory management/security features appear to be tuned for C/C++ programs. Unfortunately, they interfere with running programs written in some other languages. It's especially silly when the language design prevents the problem anyway. Take a look at the rant here, where Axiom explains how to run on Fedora: http://axiom.axiom-developer.org/axiom-website/patches/20080527.01.tpd.patch Axiom's solution is completely disable a lot of security functions for the ENTIRE system, not just for that one program. That's not good.
I think it'd better to create an SELinux security context that grants additional memory privileges that can be used ONLY when the program actually _NEEDS_ those privileges (e.g., it uses a gcl runtime requiring additional privileges). You could document a "recipe" for how to create such a thing would be a good idea - but you'd need to recreate it for every program compiled by gcl, ugh. I think it'd be better to have a standard context for this case (the current "unconfined" really is confined; maybe the new one is "really_unconfined"?). Having some processes less confined is better than disabling the security mechanisms for the entire system.
--- David A. Wheeler
On Fri, 05 Sep 2008 16:54:43 -0400 (EDT) "David A. Wheeler" dwheeler@dwheeler.com wrote:
Matt Domsch wrote regarding gcl (GNU Common Lisp):
gcl-2.6.7-18.fc9 [u'440913 ASSIGNED'] (build/make) gemi,green
I would rather like to let die. It is a pain and does not build anymore on any architecture. Maybe someone have a try with it?
From: G?rard Milmeister gemi@bluewin.ch
Tried that too. However that Fedora memory management and security features get in the way.
Dropping gcl is a bad idea. gcl generates much better code in many cases; dropping makes Fedora bad for running Common Lisp (CL) applications. There are a lot of CL programs, and CL is still important; "Practical Common Lisp" was published 2005 and was a really popular book.
For example, performance figures for ACL2 are here: http://www.cs.utexas.edu/users/moore/acl2/current/new.html#performance gcl is 20% faster on 64-bit, and 32% faster on 32-bit,, compared to the next-best implementation available on Fedora.
This may illustrate a larger security issue: the Fedora memory management/security features appear to be tuned for C/C++ programs. Unfortunately, they interfere with running programs written in some other languages. It's especially silly when the language design prevents the problem anyway. Take a look at the rant here, where Axiom explains how to run on Fedora: http://axiom.axiom-developer.org/axiom-website/patches/20080527.01.tpd.patch Axiom's solution is completely disable a lot of security functions for the ENTIRE system, not just for that one program. That's not good.
I think it'd better to create an SELinux security context that grants additional memory privileges that can be used ONLY when the program actually _NEEDS_ those privileges (e.g., it uses a gcl runtime requiring additional privileges). You could document a "recipe" for how to create such a thing would be a good idea - but you'd need to recreate it for every program compiled by gcl, ugh. I think it'd be better to have a standard context for this case (the current "unconfined" really is confined; maybe the new one is "really_unconfined"?). Having some processes less confined is better than disabling the security mechanisms for the entire system.
This is the approach taken for mono and java, which have similar issues.
If you use a context type of java_exec_t for something using the gcl runtime, does it work?
Paul.
--- David A. Wheeler
Paul Howarth wrote:
On Fri, 05 Sep 2008 16:54:43 -0400 (EDT) "David A. Wheeler" dwheeler@dwheeler.com wrote:
I think it'd better to create an SELinux security context that grants additional memory privileges that can be used ONLY when the program actually _NEEDS_ those privileges (e.g., it uses a gcl runtime requiring additional privileges). You could document a "recipe" for how to create such a thing would be a good idea - but you'd need to recreate it for every program compiled by gcl, ugh. I think it'd be better to have a standard context for this case (the current "unconfined" really is confined; maybe the new one is "really_unconfined"?). Having some processes less confined is better than disabling the security mechanisms for the entire system.
Indeed. The SELinux approach is not to disable such features for a whole system, but to provide fine-grained access control for those parts that need it.
This is the approach taken for mono and java, which have similar issues.
If you use a context type of java_exec_t for something using the gcl runtime, does it work?
Is it every program created by gcl that needs this access, or just gcl itself?
Andrew.
On Fri, 2008-09-05 at 16:54 -0400, David A. Wheeler wrote:
Dropping gcl is a bad idea. gcl generates much better code in many cases; dropping makes Fedora bad for running Common Lisp (CL) applications. There are a lot of CL programs, and CL is still important; "Practical Common Lisp" was published 2005 and was a really popular book.
I am not unwilling to continue with GCL. However I would need some help from people knowing about these issues (on several architectures) and how to fix them. BTW, SELinux is only one issue. GCL doesn't compile even with SELinux disabled (randomized addresses etc...)
Gérard Milmeister wrote:
On Fri, 2008-09-05 at 16:54 -0400, David A. Wheeler wrote:
Dropping gcl is a bad idea. gcl generates much better code in many cases; dropping makes Fedora bad for running Common Lisp (CL) applications. There are a lot of CL programs, and CL is still important; "Practical Common Lisp" was published 2005 and was a really popular book.
I am not unwilling to continue with GCL. However I would need some help from people knowing about these issues (on several architectures) and how to fix them.
OK.
BTW, SELinux is only one issue. GCL doesn't compile even with SELinux disabled (randomized addresses etc...)
Hmm. This is because GCL saves its compiled code and expects it to be loaded at the same address?
Andrew.
Here are my findings:
(at home: Fedora-9 i386, gcl-cvs 20080908) - SELinux is disabled - using the bundled binutils instead of the system ones (configure --enable-locbfd --disable-statsysbfd) - building everything with -O2 (-O3 is normally hardwired) then GCL builds completely.
This also works in a local mock rawhide build. However a scratch build using koji fails. I found that there is a difference in the memory layout between local (kernel 2.6.14) and koji (2.6.18) and GCL tries to do some funny things (such as generating its own ld script) which probably makes it fail ultimately. In particular it tries to detect some memory layout parameters such as stack ceiling (0xffffffff on koji, 0xbfffffff locally, why is this?) and "shared library/C stack ceiling to heap" (sic) (herefore it looks at the last address used in `ldd /usr/bin/awk`!!!).
Apropos SELinux: When loading an image dump (made using unexec known from emacs) GCL tries to change protection using mprotect. It is possible to configure the garbage collector to omit this step. Image loading then proceeds, but loading compiled Lisp modules later fails again due to mprotect. There is probably no way to circumvent this without making far reaching modifications to GCL memory management itself. Therefore creating a security context for GCL is probably the only way to make GCL work smoothly in the mid-term (provided we can get non-selinux builds to work).
This is as far as I have come currently, I hope that together we may work out solutions.
Regards, Gérard
On Mon, Sep 08, 2008 at 06:04:35PM +0200, Gérard Milmeister wrote:
On Fri, 2008-09-05 at 16:54 -0400, David A. Wheeler wrote:
Dropping gcl is a bad idea. gcl generates much better code in many cases; dropping makes Fedora bad for running Common Lisp (CL) applications. There are a lot of CL programs, and CL is still important; "Practical Common Lisp" was published 2005 and was a really popular book.
I am not unwilling to continue with GCL. However I would need some help from people knowing about these issues (on several architectures) and how to fix them.
See what libffi does, in particular the SELinux related stuff in closures.c.
Jakub
Jakub Jelinek wrote:
On Mon, Sep 08, 2008 at 06:04:35PM +0200, Gérard Milmeister wrote:
On Fri, 2008-09-05 at 16:54 -0400, David A. Wheeler wrote:
Dropping gcl is a bad idea. gcl generates much better code in many cases; dropping makes Fedora bad for running Common Lisp (CL) applications. There are a lot of CL programs, and CL is still important; "Practical Common Lisp" was published 2005 and was a really popular book.
I am not unwilling to continue with GCL. However I would need some help from people knowing about these issues (on several architectures) and how to fix them.
See what libffi does, in particular the SELinux related stuff in closures.c.
That's a really nasty solution, though. We'd have to get agreement from upstream for this: it would not be good for us to maintain a fork.
Andrew.