View previous topic :: View next topic |
Author |
Message |
rhumbliner n00b
Joined: 15 Nov 2004 Posts: 59 Location: Las Vegas
|
Posted: Sun Dec 31, 2017 3:57 pm Post subject: What Happened to 4.14 kernel? |
|
|
I've gone thru the required procedure using profile 22
Code: | [22] default/linux/amd64/17.0/no-multilib * |
and now the only kernel available to me is 4.9.49-r1
Code: | * sys-kernel/gentoo-sources
Latest version available: 4.9.49-r1
Latest version installed: 4.9.49-r1
Size of files: 92,004 KiB
Homepage: https://dev.gentoo.org/~mpagano/genpatches
Description: Full sources including the Gentoo patchset for the 4.9 kernel tree
License: GPL-2 freedist
|
but I'm currently running 4.12.12-gentoo
Code: | {s13:~} uname -r
4.12.12-gentoo |
Is this normal? Must I revert to an older kernel?
TIA |
|
Back to top |
|
|
fedeliallalinea Administrator
Joined: 08 Mar 2003 Posts: 30915 Location: here
|
|
Back to top |
|
|
asturm Developer
Joined: 05 Apr 2007 Posts: 8936
|
Posted: Sun Dec 31, 2017 4:08 pm Post subject: |
|
|
The kernel issue is completely off-topic here, please look at one of the various existing bugs about that.
[Moderator note: this post, and the two above it, were originally posted in Profile 17.0. Per asturm's post, the post that starts this thread was off-topic in that thread, so I moved it and the responses to it out to a separate thread. -Hu] |
|
Back to top |
|
|
rhumbliner n00b
Joined: 15 Nov 2004 Posts: 59 Location: Las Vegas
|
Posted: Sun Dec 31, 2017 7:08 pm Post subject: Re: What Happened to 4.14 kernel? |
|
|
Thank you! Somehow this got by me. |
|
Back to top |
|
|
Tony0945 Watchman
Joined: 25 Jul 2006 Posts: 5127 Location: Illinois, USA
|
Posted: Sun Dec 31, 2017 7:29 pm Post subject: Re: What Happened to 4.14 kernel? |
|
|
Quote: | The last update that 4.12 got from upstream was 2017-09-20,
and upstream is no more backporting security fixes since then.
Because of this, we will proceed to mask 4.12. |
Three months ago! How ancient! How old is the kernel that some Ubuntu user installed last year? I for one am rather sick of the "kernel of the week" obviously inadequately tested kernels coming out of kernel.org lately. Kernels used to be updated every six months to a year and 2.2 lasted quite a while alongside the radically different 2.4 The present kernels should be marked as "release candidates" by upstream rather than as "stable".
Because upstream is not issing updates anymore is no reason to mask a package, else half the tree would be masked. Have we fallen into the Microsoft update daily paradigm? |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54237 Location: 56N 3W
|
Posted: Sun Dec 31, 2017 7:34 pm Post subject: |
|
|
Tony0945,
It seems its Gentoos gcc _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
Tony0945 Watchman
Joined: 25 Jul 2006 Posts: 5127 Location: Illinois, USA
|
Posted: Sun Dec 31, 2017 7:55 pm Post subject: |
|
|
NeddySeagoon wrote: | It seems its Gentoos gcc |
Thanks for the link. Apparently it only affects Intel cpu's because I had these kernels running on two k10's and a Kaveri with no problem.
Can't this be implemented as an "r" revision with a patch to the ebuild rather than masking the whole kernel?
Code: | KBUILD_CFLAGS += $(call cc-option,-fno-stack-check,) |
|
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21633
|
Posted: Sun Dec 31, 2017 8:37 pm Post subject: Re: What Happened to 4.14 kernel? |
|
|
Tony0945 wrote: | Three months ago! How ancient! How old is the kernel that some Ubuntu user installed last year? I for one am rather sick of the "kernel of the week" obviously inadequately tested kernels coming out of kernel.org lately. Kernels used to be updated every six months to a year and 2.2 lasted quite a while alongside the radically different 2.4 The present kernels should be marked as "release candidates" by upstream rather than as "stable". | As a general rule, the upstream maintainers refuse to differentiate bug fixes from security fixes, and instead categorize all fixes as "must upgrade" fixes. This leads to the problem that if you want any security fixes, you need to pull everything marked as a fix of any sort because it might be a security fix (unless you want to spend substantial programmer effort determining it is not a security fix, and you get to do this for each of the dozens of patches in each stable kernel). Combine this with the frequent difficulty of determining whether a fix (whether security or other) impacts code you use and it becomes difficult to identify kernels you can skip if you want all applicable security fixes. (You might get lucky and the fix only affects people who use some feature that you compiled out, hence applying the patch to your kernel has no impact on the generated code because you never built the bad code in the first place.) The threat model for these updates is that malicious actors can rapidly weaponize any vulnerability, and will become aware of the vulnerability $soon, where $soon ranges from "when the bug (not the fix!) was first added" to "within a few days of the fix being posted," depending on how lucky you are. If your threat model is less severe (e.g. "all my local users run only trusted code"), you can probably skip some classes of security fix - but good luck figuring out whether all the fixes in a given release fit within that more relaxed threat model, since first you need to find which fixes are even security relevant and applicable to your system, then filter those for whether you expect someone might try to exploit them.
I'd love to see some tooling that could at least address the question "Given this patch, and my kernel configuration, will applying this patch and rebuilding result in a kernel that is functionally different than the unpatched kernel?" That omits the harder steps relating to finding important patches, but is a useful first filter. If the patch doesn't change the compiled code, it can't possibly be security relevant to that configuration. Tony0945 wrote: | NeddySeagoon wrote: | It seems its Gentoos gcc |
Thanks for the link. Apparently it only affects Intel cpu's because I had these kernels running on two k10's and a Kaveri with no problem.
Can't this be implemented as an "r" revision with a patch to the ebuild rather than masking the whole kernel?
Code: | KBUILD_CFLAGS += $(call cc-option,-fno-stack-check,) |
| Probably it could. I think the mask was put in before anyone knew what caused the problem, so it was an emergency mask to prevent users breaking their kernels while debugging was done. |
|
Back to top |
|
|
asturm Developer
Joined: 05 Apr 2007 Posts: 8936
|
Posted: Sun Dec 31, 2017 8:42 pm Post subject: Re: What Happened to 4.14 kernel? |
|
|
Tony0945 wrote: | Because upstream is not issing updates anymore is no reason to mask a package, else half the tree would be masked. Have we fallen into the Microsoft update daily paradigm? |
Kernel packages are not like other packages. Nothing is forcing you to change your kernel image even if that version is masked. But Gentoo for sure will not keep them for an unlimited time available for install when upstream discloses security vulnerabilities or other issues. |
|
Back to top |
|
|
pablo_supertux Advocate
Joined: 25 Jan 2004 Posts: 2931 Location: Somewhere between reality and Middle-Earth and in Freiburg (Germany)
|
Posted: Tue Jan 02, 2018 2:15 pm Post subject: |
|
|
There is one thing I don't get about the versioning here: For a normal package 4.12 would be a newer version, 4.9 and older. Why doesn't this apply to gentoo-sources? I read the archived mail of gentoo-dev, but this doesn't make sense to me. Why is 4.14.x not maintained upstream but 4.9 is? _________________ A! Elbereth Gilthoniel!
silivren penna míriel
o menel aglar elenath,
Gilthoniel, A! Elbereth! |
|
Back to top |
|
|
Tony0945 Watchman
Joined: 25 Jul 2006 Posts: 5127 Location: Illinois, USA
|
Posted: Tue Jan 02, 2018 2:48 pm Post subject: |
|
|
pablo_supertux wrote: | There is one thing I don't get about the versioning here: For a normal package 4.12 would be a newer version, 4.9 and older. Why doesn't this apply to gentoo-sources? I read the archived mail of gentoo-dev, but this doesn't make sense to me. Why is 4.14.x not maintained upstream but 4.9 is? |
Look at https://www.kernel.org/ 4.14 is stable, just not longterm like 4.4 and 4.9, eventually 4.14 will disappear like 4.11, 4.12, and 4.13
Mainline development is on 4.15 which so far has only RC release candidates, i.e. it is truly "testing". For production use you want a longterm support kernel that will have bug fixes backported. For hobby use you want 4.14 or 4.15 depending on how adventurous you are.
4.14 IS maintained upstream and the Gentoo tree has a new version roughly every week. Compare https://packages.gentoo.org/packages/sys-kernel/gentoo-sources to the earlier link. |
|
Back to top |
|
|
EasterParade l33t
Joined: 26 Jul 2003 Posts: 938
|
Posted: Tue Jan 02, 2018 2:50 pm Post subject: |
|
|
I am running 4.14.8-gentoo-r1 and it is not masked, just keyworded.
I'd rather keep it (?) |
|
Back to top |
|
|
asturm Developer
Joined: 05 Apr 2007 Posts: 8936
|
Posted: Tue Jan 02, 2018 3:15 pm Post subject: |
|
|
Sure, just keep it if it works for you. |
|
Back to top |
|
|
charles17 Advocate
Joined: 02 Mar 2008 Posts: 3664
|
Posted: Tue Jan 02, 2018 3:19 pm Post subject: |
|
|
|
|
Back to top |
|
|
Tony0945 Watchman
Joined: 25 Jul 2006 Posts: 5127 Location: Illinois, USA
|
Posted: Tue Jan 02, 2018 7:55 pm Post subject: |
|
|
Ah! A Stable release may or may not also be a mainline kernel. Reading the whole page you cited it makes sense. Thank you for the clarification. |
|
Back to top |
|
|
pablo_supertux Advocate
Joined: 25 Jan 2004 Posts: 2931 Location: Somewhere between reality and Middle-Earth and in Freiburg (Germany)
|
Posted: Tue Jan 02, 2018 10:50 pm Post subject: |
|
|
@Tony0945 thank for clarifying this, that make sense. _________________ A! Elbereth Gilthoniel!
silivren penna míriel
o menel aglar elenath,
Gilthoniel, A! Elbereth! |
|
Back to top |
|
|
Naib Watchman
Joined: 21 May 2004 Posts: 6051 Location: Removed by Neddy
|
Posted: Tue Jan 02, 2018 10:57 pm Post subject: |
|
|
NeddySeagoon wrote: | Tony0945,
It seems its Gentoos gcc | I like how changing a default gcc option uncovering an unexpected "feature" of the kernel build is a Gentoo issues not "thanks, we should look into this" _________________
Quote: | Removed by Chiitoo |
|
|
Back to top |
|
|
Carnildo Guru
Joined: 17 Jun 2004 Posts: 594
|
Posted: Wed Jan 03, 2018 2:06 am Post subject: |
|
|
Naib wrote: | NeddySeagoon wrote: | Tony0945,
It seems its Gentoos gcc | I like how changing a default gcc option uncovering an unexpected "feature" of the kernel build is a Gentoo issues not "thanks, we should look into this" |
It's a Gentoo issue because Gentoo is applying a compiler feature to a portion of the kernel that is inherently incompatible with that compiler feature.
As I understand it, the "-fstack-check" feature inserts code to signal to the kernel that an application's stack is being extended. However, for reasons of security, predictability, and resource consumption, the kernel doesn't manage its stack the way an application does. If you try to apply application-style stack management to it, bad things happen. |
|
Back to top |
|
|
proteusx Guru
Joined: 21 Jan 2008 Posts: 338
|
Posted: Wed Jan 03, 2018 3:28 am Post subject: |
|
|
How can one disable
Quote: | the gentoo compiler having some shit-for-brains "feature" |
Do we need to add -fno-stack-check to the CFLAGS? |
|
Back to top |
|
|
jburns Veteran
Joined: 18 Jan 2007 Posts: 1214 Location: Massachusetts USA
|
|
Back to top |
|
|
ct85711 Veteran
Joined: 27 Sep 2005 Posts: 1791
|
Posted: Wed Jan 03, 2018 4:44 am Post subject: |
|
|
From reading that entire thread, it seems this is most specifically an issue if you are using the hardened profile, I don't think it is much of an issue for the regular profile (unless -fstack-check is added for the regular profile too). |
|
Back to top |
|
|
proteusx Guru
Joined: 21 Jan 2008 Posts: 338
|
Posted: Wed Jan 03, 2018 2:38 pm Post subject: |
|
|
Does anyone know if -fstack-check is set for non-hardened profiles?
These things are now buried under layers of labyrinthine eclasses.
Not easy to tell what is happening. |
|
Back to top |
|
|
Tony0945 Watchman
Joined: 25 Jul 2006 Posts: 5127 Location: Illinois, USA
|
Posted: Wed Jan 03, 2018 2:49 pm Post subject: |
|
|
All I can think of is a local ebuild that compiles something innocuous like "main(){exit(0);}" and looking at the screen output.
EDIT:
Froze an emerge with CTRL-S Found this line Code: | x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -fno-strict-aliasing -Wstrict-prototypes -Wall -D_GNU_SOURCE -c ping.c -DUSE_OPENSSL -o ping.o
|
There is a new kernel so I'll compile that too and try to catch the gcc lines, If you are not upgrading a kernel you can always rebuild your current kernel.
EDIT2:
Kernel compiles with stuff like Code: | CC drivers/acpi/acpica/utxferror.o
| I have no idea what's buried in the CC macro. Hopefully, someone more adept than I knows how to expand it. |
|
Back to top |
|
|
tld Veteran
Joined: 09 Dec 2003 Posts: 1816
|
Posted: Wed Jan 03, 2018 4:55 pm Post subject: |
|
|
I had already gone to kernel 4.14.8-r1 on this machine with no problems. On my MythTV frontend which is currently on 4.12.12 I use the nVidia drivers, and I see here that that might be a problem...though I'm still unclear as to whether that's all just with hardened profiles(??). That creates a bit of a dilemma for me on that machine, because I no longer have a 4.9 version of my .config file...so I see no good way to go back to 4.9.x. What I'll probably do is to just stay on 4.12.12, even when it gets removed from portage, until a stable 4.14 is available...at least I think that's my safest option.
Tom |
|
Back to top |
|
|
paulj Guru
Joined: 30 Sep 2004 Posts: 513 Location: Wales, UK
|
Posted: Wed Jan 03, 2018 7:48 pm Post subject: |
|
|
My laptop and desktop are both on gentoo-sources-4.12.12. I don't have the .config files for an earlier version any more - after all, this was a stable kernel. I am considering going to the latest unstable 4.14 branch, and if that doesn't work, staying with 4.12.12 until a newer stable kernel is available. I haven't seen any issues with 4.12.12, but of course I understand the security implications if there are no longer any backports for security issues (hence the attempt to go to 4.14). |
|
Back to top |
|
|
|