Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 628576 - sys-kernel/gentoo-sources-4.12.5: CONFIG_CC_STACKPROTECTOR_REGULAR -fstack-protector not supported by compiler failure
Summary: sys-kernel/gentoo-sources-4.12.5: CONFIG_CC_STACKPROTECTOR_REGULAR -fstack-pr...
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Kernel Bug Wranglers and Kernel Maintainers
URL:
Whiteboard:
Keywords:
: 627326 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-08-22 07:43 UTC by Peter Ulrich
Modified: 2017-09-19 23:10 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
output when running genkernel (output.txt,8.27 KB, text/plain)
2017-08-22 07:43 UTC, Peter Ulrich
Details
emerge --info (emerge_info.txt,7.72 KB, text/plain)
2017-09-04 10:54 UTC, Matt
Details
Requested GCC Test Output (gcc_test.txt,4.88 KB, text/plain)
2017-09-05 18:09 UTC, Matt
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Ulrich 2017-08-22 07:43:06 UTC
Created attachment 490046 [details]
output when running genkernel

$ genkernel --version
3.4.52.4
$ genkernel --no-install --mrproper all
fails (almost instantaneously)
(see attachment)
Comment 1 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2017-09-04 05:39:44 UTC
Please reopen with your emerge --info output.

Your gcc is not supporting -fstack-protector, which is weird, because that's standard in gentoo for a long time now.
Comment 2 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2017-09-04 05:44:34 UTC
*** Bug 627326 has been marked as a duplicate of this bug. ***
Comment 3 Matt 2017-09-04 10:53:24 UTC
My original report: https://bugs.gentoo.org/show_bug.cgi?id=627326

Adding my emerge --info attachment.


M.
Comment 4 Matt 2017-09-04 10:54:05 UTC
Created attachment 492246 [details]
emerge --info
Comment 5 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2017-09-05 16:59:40 UTC
Matt:
Can you please show me the output of:
# gcc-config -l
# echo 'int main() {}' >/tmp/stacktest.c && gcc-5.4.0 -fstack-protector  /tmp/stacktest.c -o /tmp/stacktest -v ; echo $?
Comment 6 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2017-09-05 17:00:28 UTC
If you aren't still using gcc 5.4.0 as your current GCC, please update the version as needed.
Comment 7 Matt 2017-09-05 18:09:01 UTC
(In reply to Robin Johnson from comment #5)
> Matt:
> Can you please show me the output of:
> # gcc-config -l
> # echo 'int main() {}' >/tmp/stacktest.c && gcc-5.4.0 -fstack-protector 
> /tmp/stacktest.c -o /tmp/stacktest -v ; echo $?

$ gcc --version
gcc (Gentoo 5.4.0-r3 p1.3, pie-0.6.5) 5.4.0

$ gcc-config -l
 [1] i686-pc-linux-gnu-5.4.0 *

I'm attaching the output of your GCC test after submitting this comment.


M.
Comment 8 Matt 2017-09-05 18:09:30 UTC
Created attachment 492674 [details]
Requested GCC Test Output
Comment 9 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2017-09-05 18:18:16 UTC
That output shows the -fstack-protector worked fine; so why did the kernel decide that it's not supported???

I'm moving this bug to the kernel team, because it's not a genkernel issue.

kernel team:
CONFIG_CC_STACKPROTECTOR_REGULAR is set by default in genkernel. It seems that for two systems now, the kernel outputs:
"Cannot use CONFIG_CC_STACKPROTECTOR_REGULAR: -fstack-protector not supported by compiler"
Yet using the compiler manually with -fstack-protector works fine.
Comment 10 Mike Pagano gentoo-dev 2017-09-05 20:17:03 UTC
If this is not reproducible without genkernel, I'm not sure what I can do here.
Comment 11 Mike Pagano gentoo-dev 2017-09-05 21:49:26 UTC
Hi, Robin,

Adding you back as I hope you can help me.
When I run the command on amd64, stackp-flag does not get set.

When I run it on x86 (like reporter, it does get set).

When stackp-flag is non empty (x86) it falls into the error around line 1086 in the Makefile:

ifdef stackp-name
   ifeq ($(call cc-option, $(stackp-flag)),)
     @echo Cannot use CONFIG_CC_STACKPROTECTOR_$(stackp-name): \
           $(stackp-flag) not supported by compiler >&2 && exit 1
   endif
endif

The question is how stackp-flag is empty for amd64  

Still looking here
Comment 12 Mike Pagano gentoo-dev 2017-09-05 22:02:45 UTC
No, I'm wrong.

The following function gives different values on x86 vs amd64:



ifeq ($(call cc-option, $(stackp-flag)),)

amd64:
stackp-name: REGULAR stackp-flag -fstack-protector

x86:
stackp-name: REGULAR stackp-flag -fstack-protector

but on amd64 the call function works, but on x86 it does not.
Comment 13 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2017-09-07 22:09:58 UTC
(In reply to Mike Pagano from comment #12)
> No, I'm wrong.
> 
> The following function gives different values on x86 vs amd64:
> 
> 
> 
> ifeq ($(call cc-option, $(stackp-flag)),)
> 
> amd64:
> stackp-name: REGULAR stackp-flag -fstack-protector
> 
> x86:
> stackp-name: REGULAR stackp-flag -fstack-protector
> 
> but on amd64 the call function works, but on x86 it does not.

Which do you mean by function:
the entire ifeq function evaluation, or just the cc-option call?

I'm trying to find an x86 system that exhibits the problem, so I can poke at why. The one system I do have, doesn't exhibit it at all,  but isn't an exact match to the gcc version.
Comment 14 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2017-09-07 23:41:14 UTC
Ok, this is something specific to the kconfig that shipped with old genkernel. Using genkernel-3.5.0.8 or newer and it works fine.

I think something else that ends up in the gcc options is causing a failure when -fstack-protector is also added.

Since the kernel doesn't print the commands options during cc-option evaluation, it's not so trivial to evaluate.

I'm tempted to just close this bug, as genkernel-3.5 has lots of changes to go with the newer kernel sources. You'd need 3.5.2.0 for recent glibc changes as well.
Comment 15 Matt 2017-09-08 01:13:20 UTC
(In reply to Robin Johnson from comment #14)
> Ok, this is something specific to the kconfig that shipped with old
> genkernel. Using genkernel-3.5.0.8 or newer and it works fine.
> 

Well, folowing that logic, I bumped genkernl to 3.5.2.0-r1 (which wanted app-misc/pax-utils to be >=1.2.2 and sys-apps/util-linux to be static-libs).  I put 4.13.0 sources on here (no easily "not conflict" with my running 4.12.10).  The kernel is now building.  It's still going so I can't say to 100% certain I won't get bit by some other oddity, but it's going which is a LOT more than it was.

THANK YOU!

M.

P.S.
Yes I know I need to move away from x86 and to _64.  I'm just trying to decide what to do.  This _hardware_ is indeed 64 bit.  It's just this machine and I have been through quite a lot for a loooong time:

me@aragorn ~ $ ls -lt --full-time /etc/ssh/ | tail -n5
-rw-r--r-- 1 root root    349 2002-10-17 16:45:54.000000000 -0400 ssh_host_key.pub
-rw------- 1 root root    883 2002-10-17 16:43:11.000000000 -0400 ssh_host_rsa_key
-rw-r--r-- 1 root root    240 2002-10-17 16:43:11.000000000 -0400 ssh_host_rsa_key.pub
-rw------- 1 root root    672 2002-10-17 16:42:48.000000000 -0400 ssh_host_dsa_key
-rw-r--r-- 1 root root    620 2002-10-17 16:42:48.000000000 -0400 ssh_host_dsa_key.pub


Yes those dates are real.  Same install, obviously many different hardwares in that time.  I did the initial install with a Gentoo CD of an RC for 1.0.  Seriously:

me@aragorn ~ $ ls -l --full-time /README.maintainer 
-rw-r--r-- 1 root root 3473 2002-05-08 15:19:08.000000000 -0400 /README.maintainer

me@aragorn ~ $ tail -n4 /README.maintainer 
Best Regards,

Daniel Robbins
drobbins@gentoo.org

;-)
Comment 16 Mike Pagano gentoo-dev 2017-09-08 12:17:04 UTC
(In reply to Robin Johnson from comment #13)
> (In reply to Mike Pagano from comment #12)
> > No, I'm wrong.
> > 
> > The following function gives different values on x86 vs amd64:
> > 
> > 
> > 
> > ifeq ($(call cc-option, $(stackp-flag)),)
> > 
> > amd64:
> > stackp-name: REGULAR stackp-flag -fstack-protector
> > 
> > x86:
> > stackp-name: REGULAR stackp-flag -fstack-protector
> > 
> > but on amd64 the call function works, but on x86 it does not.
> 
> Which do you mean by function:
> the entire ifeq function evaluation, or just the cc-option call?
> 
> I'm trying to find an x86 system that exhibits the problem, so I can poke at
> why. The one system I do have, doesn't exhibit it at all,  but isn't an
> exact match to the gcc version.

I'm fine with your plan to do the bump and move on with this one.
But I do have an x86 system I can give you access to if you like that does exhibit the behavior. Not sure it's worth your effort.
Comment 17 Mike Pagano gentoo-dev 2017-09-19 23:10:52 UTC
Robin, I'm going to close this with the workaround that users can just upgrade genkernel.

If you want to reopen and take assignment of it, please do.