blas-atlas has executable stacks in usr/lib64/libatlas.so.0.0.0
Created attachment 97152 [details] log from scanelf from portage
Hi Olivier, Thanks and, unfortunately, this is a know issue with all recent blas-atlas versions and on my "to-do" list. Since atlas does compile-time assembly code generation based on CPU and timings this is non-trivial to fix since it requires modification of the code generator itself not "simply" a piece of assembly somewhere. I will have to ping upstream and make them aware of it. Hopefully, they are able/willing to look into this. Best, Markus
The "executable stack" warning can arise from several places. Where there is assembler code that doesn't use executable heap or stack, but simply doesn't contain a PT_GNUSTACK marking, it should be fixed (see http://www.gentoo.org/proj/en/hardened/gnu-stack.xml). From what I see in the scanelf log, I wouldn't be surprised if most of the objects that are being flagged have this issue; I'd guess a lot of those objects are built from asm sources that don't have the appropriate PT_GNUSTACK marking. Where code does actually require executable stack (for example uses nested functions that refer to data in the caller's scope, or does run-time code generation onto the stack by design) then it's not really a bug, and it's just a matter of setting QA_EXECSTACK to the objects that require it (relative to ${D}); e.g. QA_EXECTACK="usr/lib64/libatlas.so.0.0.0" That said, if the code can be patched simply to avoid it without impacting performance, we find that often upstream will accept such a patch. As an additional item, if the code provides an alternative to the run-time code generation (e.g. through a configure option), the hardened project would appreciate it if this option be set conditional on USE=hardened - for hardened profile systems we sacrifice speed if it means we can eliminate run-time code generation. For non-hardened users the option would be a bad idea, as they would lose performance for no benefit - hence doing it conditional on USE=hardened. An example here is media-libs/mesa, which as an option "ASM_API" which when disabled, falls back to a slower dispatch algorithm that doesn't generate code at runtime.
(In reply to comment #3) > The "executable stack" warning can arise from several places. Hi Kevin, Thanks a lot for your detailed answer. The compile time code generation is what makes atlas one of the most efficient blas/cblas implementation out there and as such can't be turned off. However, we have blas/lapack-reference as a (slower) alternative which doesn't suffer from this (last time I checked that is). I've fixed several packages in the past that had a missing PT_GNUSTACK marking, but in the case of atlas this doesn't mean finding the offending asm but hacking the code the generates the asm which is a lot more tricky. In any case, the upstream developer is a very nice guy and I'll ask him if this is intentional for whatever reason and if not if we can fix it. I'll post back once I know more. Thanks, Markus
(In reply to comment #4) > in the case of atlas this doesn't mean finding the offending > asm but hacking the code the generates the asm which is a lot more tricky. Or you could add -Wa,--noexecstack to the Makefile for the appropriate libraries. This may be a more painless solution.
(In reply to comment #5) > Or you could add -Wa,--noexecstack to the Makefile for the appropriate > libraries. This may be a more painless solution. That's a very bad idea! The code does need executable stack so the marking must remain there as long as that is the case. The correct fix (assuming upstream don't want to change the way it works, which I expect to be the case) is to inform portage's QA checks which files need executable stack. The QA check isn't there to ban all executable stack code, but to ensure only code that actually needs it is so marked. People who want absolutely no executable code (e.g. hardened servers) can set QA_STRICT_EXECSTACK and emerge will fail regardless. It's not Gentoo's job to do major modifications to code, so setting QA_EXECSTACK in the ebuild is the right thing to do. A comment next to it saying that the alternative blas/lapack-reference is available, which is slower but doesn't need executable stacks, would be useful.
(In reply to comment #6) > The code does need executable stack so the marking > must remain there as long as that is the case. My bad, didn't realise exec stacks were necessary
Closing this bug since blas-atlas-3.7.11 has been superseded by blas-atlas-3.8.* and will be removed from the tree soon. Thanks, Markus
