* QA Notice: The following files contain writable and executable sections * Files with such sections will not work properly (or at all!) on some * architectures/operating systems. A bug should be filed at * http://bugs.gentoo.org/ to make sure the issue is fixed. * For more information, see http://hardened.gentoo.org/gnu-stack.xml * Please include the following list of files in your report: * Note: Bugs should be filed for the respective maintainers * of the package in question and not hardened@g.o. * !WX --- --- usr/lib64/libx265.a:const-a.asm.o * !WX --- --- usr/lib64/libx265.a:cpu-a.asm.o * !WX --- --- usr/lib64/libx265.a:ssd-a.asm.o * !WX --- --- usr/lib64/libx265.a:mc-a.asm.o * !WX --- --- usr/lib64/libx265.a:mc-a2.asm.o * !WX --- --- usr/lib64/libx265.a:pixel-util8.asm.o * !WX --- --- usr/lib64/libx265.a:blockcopy8.asm.o * !WX --- --- usr/lib64/libx265.a:pixeladd8.asm.o * !WX --- --- usr/lib64/libx265.a:dct8.asm.o * !WX --- --- usr/lib64/libx265.a:sad16-a.asm.o * !WX --- --- usr/lib64/libx265.a:intrapred16.asm.o * !WX --- --- usr/lib64/libx265.a:ipfilter16.asm.o * !WX --- --- usr/lib32/libx265.a:const-a.asm.o * !WX --- --- usr/lib32/libx265.a:cpu-a.asm.o * !WX --- --- usr/lib32/libx265.a:ssd-a.asm.o * !WX --- --- usr/lib32/libx265.a:mc-a.asm.o * !WX --- --- usr/lib32/libx265.a:mc-a2.asm.o * !WX --- --- usr/lib32/libx265.a:pixel-util8.asm.o * !WX --- --- usr/lib32/libx265.a:blockcopy8.asm.o * !WX --- --- usr/lib32/libx265.a:pixeladd8.asm.o * !WX --- --- usr/lib32/libx265.a:dct8.asm.o * !WX --- --- usr/lib32/libx265.a:sad16-a.asm.o * !WX --- --- usr/lib32/libx265.a:intrapred16.asm.o * !WX --- --- usr/lib32/libx265.a:ipfilter16.asm.o * !WX --- --- usr/lib32/libx265.a:pixel-32.asm.o Reproducible: Always
Created attachment 388496 [details, diff] Mark assembly files with no executable stack.
Any chance you could post this patch to upstream?
Created attachment 396360 [details, diff] x265-1.4-noEXEstack.patch The original patch did not apply cleanly to x265-1.4. This version is rebased against that version.
Created attachment 399182 [details, diff] x265-1.5-noEXEstack.patch Patch rebased against x265-1.5
(In reply to Samuli Suominen from comment #2) > Any chance you could post this patch to upstream? please do; as far as I am concerned, I will not apply this patch until upstream merges it
(In reply to Paolo Pedroni from comment #4) > Created attachment 399182 [details, diff] [details, diff] > x265-1.5-noEXEstack.patch > > Patch rebased against x265-1.5 Seems to do the trick for me! Thanks!
Created attachment 403650 [details, diff] x265-1.7-noEXEstack.patch Patch rebased against x265-1.7
(In reply to Paolo Pedroni from comment #7) > Created attachment 403650 [details, diff] [details, diff] > x265-1.7-noEXEstack.patch > > Patch rebased against x265-1.7 Thank you so much! Any chance to push this upstream?
(In reply to Attila Tóth from comment #8) > (In reply to Paolo Pedroni from comment #7) > > Created attachment 403650 [details, diff] [details, diff] [details, diff] > > x265-1.7-noEXEstack.patch > > > > Patch rebased against x265-1.7 > > Thank you so much! > Any chance to push this upstream? I have no idea if the original poster of the patch (Andrew John Hughes, see comment #1) is taking care of that.
I haven't had the time to look into upstreaming it.
(In reply to Paolo Pedroni from comment #7) > Created attachment 403650 [details, diff] [details, diff] > x265-1.7-noEXEstack.patch > > Patch rebased against x265-1.7 The patch did not applied cleanly for me. I attach a version, which was modified a little bit to be clean on my systems.
Created attachment 403700 [details, diff] modified patch to be clean on some systems
Created attachment 414412 [details, diff] x265-1.8-noEXEstack.patch Patch for x265-1.8
(In reply to Paolo Pedroni from comment #13) > Created attachment 414412 [details, diff] [details, diff] > x265-1.8-noEXEstack.patch > > Patch for x265-1.8 Thanks!
Created attachment 414556 [details, diff] x265-1.8-noEXEstack.patch modified version I've made some cleanup and added a chunk to handle loopfilter.asm as well.
(In reply to Alexis Ballier from comment #5) > (In reply to Samuli Suominen from comment #2) > > Any chance you could post this patch to upstream? > > please do; as far as I am concerned, I will not apply this patch until > upstream merges it Isn't it possible to include the patch in a way making it conditional to either pic or hardened USE flags?
Created attachment 414576 [details, diff] note-GNU-stack fix cleaner note-GNU-stack patch
Created attachment 424412 [details, diff] x265-1.9-noEXEstack.patch Patch for x265-1.9
(In reply to Paolo Pedroni from comment #18) > Created attachment 424412 [details, diff] [details, diff] > x265-1.9-noEXEstack.patch > > Patch for x265-1.9 Works for me! Thanks again: Dw.
Created attachment 442190 [details, diff] x265-2.0-noEXEstack.patch This is all that's really needed to fix this problem in 2.0 (it probably works in 1.8 and 1.9 as well).
(In reply to Paolo Pedroni from comment #20) > Created attachment 442190 [details, diff] [details, diff] > x265-2.0-noEXEstack.patch > > This is all that's really needed to fix this problem in 2.0 (it probably > works in 1.8 and 1.9 as well). Works for me (portage user patch mechanism), thx again!
did someone forward the patch upstream?
Since nobody else has done it, I've opened a PR upstream here: https://bitbucket.org/multicoreware/x265/pull-requests/30/ensure-x86-asm-is-marked-nowrite-noexec-on/diff
(In reply to Paolo Pedroni from comment #20) > Created attachment 442190 [details, diff] [details, diff] > x265-2.0-noEXEstack.patch > > This is all that's really needed to fix this problem in 2.0 (it probably > works in 1.8 and 1.9 as well). Patch works for x265-2.3 as well. I used the user patch mechanism, simple. Thx!
Created attachment 485360 [details, diff] x265-2.5-noEXEstack.patch Former patch for x265-2.0 ported to x265-2.5.
Created attachment 521050 [details, diff] Backported fix from x265 2.7 x265-2.5-noEXEstack.patch also applies to x265 2.6 cleanly. However it's only partially fixing the upstream bug, which is that the assembler defines either "elf32" or "elf64" but the x86 assembly source is still using "elf". If I'm reading it right the unfixed part causes some symbols that should be hidden inside the library to be visible. Upstream fixed the bug in their 2.7 release in a slightly different way, in the same commit where they changed from the YASM assembler to NASM. here: https://bitbucket.org/multicoreware/x265/commits/9eabffb26dd62e4f48c5679594ae13690eb9d221 Here's a backport of that upstream 2.7 fix to 2.6. It is only the part that fixes the "elf" issue, without the other changes in the same file in that 2.7 commit.
(In reply to gen2dev from comment #26) > Upstream fixed the bug in their 2.7 release in a slightly different way, in > the same commit where they changed from the YASM assembler to NASM. here: > > https://bitbucket.org/multicoreware/x265/commits/ > 9eabffb26dd62e4f48c5679594ae13690eb9d221 > > Here's a backport of that upstream 2.7 fix to 2.6. It is only the part that > fixes the "elf" issue, without the other changes in the same file in that > 2.7 commit. should be fixed now then
