What Happened to 4.14 kernel?

[rhumbliner]

I've gone thru the required procedure using profile 22

Code: Select all

 [22]  default/linux/amd64/17.0/no-multilib *

and now the only kernel available to me is 4.9.49-r1

Code: Select all

*  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: Select all

{s13:~} uname -r
4.12.12-gentoo

Is this normal? Must I revert to an older kernel?

TIA

[fedeliallalinea]

Is this normal? Must I revert to an older kernel?

Kernel 4.12 and 4.14 have been masked recently https://archives.gentoo.org/gentoo-dev/ ... 0259f2ac3e

[asturm]

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 [topic=1072934]Profile 17.0[/topic]. 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]

[rhumbliner]

Kernel 4.12 and 4.14 have been masked recently https://archives.gentoo.org/gentoo-dev/ ... 0259f2ac3e

Thank you! Somehow this got by me.

[Tony0945]

Kernel 4.12 and 4.14 have been masked recently https://archives.gentoo.org/gentoo-dev/ ... 0259f2ac3e

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?

[NeddySeagoon]

Tony0945,

It seems its Gentoos gcc

[Tony0945]

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: Select all

KBUILD_CFLAGS  += $(call cc-option,-fno-stack-check,)

[Hu]

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.

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: Select all

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.

[asturm]

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.

[pablo_supertux]

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?

[Tony0945]

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/sy ... oo-sources to the earlier link.

[EasterParade]

I am running 4.14.8-gentoo-r1 and it is not masked, just keyworded.
I'd rather keep it (?)

[asturm]

Sure, just keep it if it works for you.

[charles17]

Look at https://www.kernel.org/ 4.14 is stable, just not longterm ...

Code: Select all

Longterm release kernels

Version Maintainer          Released 	Projected EOL
4.14 	Greg Kroah-Hartman  2017-11-12  Jan, 2020

[Tony0945]

Code: Select all

Longterm release kernels

Version Maintainer          Released 	Projected EOL
4.14 	Greg Kroah-Hartman  2017-11-12  Jan, 2020

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.

[pablo_supertux]

@Tony0945 thank for clarifying this, that make sense.

[Naib]

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"

[Carnildo]

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.

[proteusx]

How can one disable

the gentoo compiler having some shit-for-brains "feature"

Do we need to add -fno-stack-check to the CFLAGS?

[jburns]

1) Use sys-kernel/gentoo-sources-4.14.10-r1 
or
2) See http://lkml.iu.edu/hypermail/linux/kern ... 02522.html

[ct85711]

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).

[proteusx]

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.

[Tony0945]

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: Select all

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: Select all

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.

[tld]

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

[paulj]

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).