Created attachment 431130 [details] arm-test-failure build.log test failures on amd64 and arm hardened
Created attachment 431132 [details] amd64-test-failure build.log amd64 build log
These do not fail on the default profile, so I don't think this should block stabilization.
(In reply to William Hubbs from comment #2) > These do not fail on the default profile, so I don't think this should > block stabilization. The two failures are different. I'm not sure what's causing the arm failure, but the amd64 failure is cause for concern. The error error while loading shared libraries: cannot make segment writable for relocation: Permission denied indicates that the linker is trying to rewrite text for a relocation, aka a TEXTREL, which is bad for security and sharing of pages in memory. TEXTRELs are usually caught by scanelf as part of our QA checks. While these are revealed by the hardened toolchain, I don't think its the fault of the toolchain per se. Does go work primarily with non-PIC code? While I don't know if you want to make this a blocker to stabilization or now, we should understand what's going on here.
(In reply to Rick Farina (Zero_Chaos) from comment #1) > Created attachment 431132 [details] > amd64-test-failure build.log > > amd64 build log can I have emerge --info for this system. also, can you look in dmesg's for any clues as to what's going on at the kernel level during the build. i assume you're using a pax-hardened kernel.
(In reply to Anthony Basile from comment #3) > (In reply to William Hubbs from comment #2) > > These do not fail on the default profile, so I don't think this should > > block stabilization. > > The two failures are different. I'm not sure what's causing the arm > failure, but the amd64 failure is cause for concern. The error > > error while loading shared libraries: cannot make segment writable for > relocation: Permission denied > > indicates that the linker is trying to rewrite text for a relocation, aka a > TEXTREL, which is bad for security and sharing of pages in memory. TEXTRELs > are usually caught by scanelf as part of our QA checks. While these are > revealed by the hardened toolchain, I don't think its the fault of the > toolchain per se. Does go work primarily with non-PIC code? I'm honestly not sure about that. what I would do if I were you is join #go-nuts on freenode and see if you can get an answer from them. > While I don't know if you want to make this a blocker to stabilization or > now, we should understand what's going on here. I agree that we want to know what is going on with this bug; I wasn't planning on closing it. I definitely don't want to block stabilization, because there is another important vulnerability fixed in 1.6.1 which affects all earlier versions. That is covered in bug #579314.
(In reply to William Hubbs from comment #5) > I definitely don't want to block stabilization, because there is another > important vulnerability fixed in 1.6.1 which affects all earlier versions. > That is covered in bug #579314. yeah i saw that after i wrote this, so you're right, move ahead with stabilization.
