SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I guess I don't understand how new kernels are built.
I would think that the developers would start with what they have achieved with the previous version and build on it.
OTOH, given what we have seen with the 4.14.x series I'm starting to think they are starting from scratch with each new series. How else can one kernel be so much different, for better or worst, than another?
I assume you mean developed, not built...
But you can think of the mainline being similar to -current. It is constantly developed. Then, they'll call a freeze for new features where they'll only accept bug fixes when they're prepping a new release and once that new version is released, things are opened back up for submissions. Things can be added and removed, just as development with Slackware can contain new programs, remove old ones, or contain upgrades. The kernel developers will continue to patch that release as needed, sometimes by backporting a change from mainline (just like how something from -current can be used in 14.2). Other bugs may be limited to that specific kernel version.
In regards to the 4.14.x series, it was announced well in advance that this was going to be an LTS release. Many developers try to get their changes submitted for an LTS release, even if not completely finished or bug free, expecting to just iron out the wrinkles in the subsequent patch releases. But if they can get that change in for an LTS, it means more people will be likely to see/use it since the kernel will be used for a lot of projects for a long time. This push by developers can lead LTS releases to be a bit buggier initially, with the kinks being worked out as new patches are released.
Sometimes those pushes aren't allowed by kernel maintainers because they're too buggy/broken/incomplete. This is likely why the big AMDGPU code didn't make it in 4.14. It needed a bit of extra time, but it finally got added in 4.15.
One strong indication not mentioned by the first article above is that Andy Lutomirski has made several technical comments on the original LWN article without contradicting the words "all the markings of a security patch being readied under pressure from a deadline".
Along with the two block subsystem fixes we've been waiting for there's also a new config option: CONFIG_PAGE_TABLE_ISOLATION (enabled by default). Rumour has it that it's purpose is to address a hardware security issue with intel processors whose details are being kept embargoed. I guess we'll find out more eventually, for now the links in 55020's post above will have to suffice.
I now see the following during boot on my Broadwell i3: Kernel/User page tables isolation: enabled
Basically, KPTI (kernel page-table isolation) prevent the userspace to bypass the KASLR (kernel address space layout randomization) via side-channel attacks, while using the current Intel processors.
The AMD ones are immune to this illness but the page-table isolation is always good (the userspace do not see the kernel anymore).
Last edited by Darth Vader; 01-02-2018 at 03:00 PM.
The suggestion from some of the links that 55020 provided is that there might be a little more to this than just a KASLR bypass, and the KPTI is not without a performance impact from what I've read so far, but I'm waiting for more details to come to light before I settle on a final position. For now, I'm going to leave it at the default 'enabled' value.
The suggestion from some of the links that 55020 provided is that there might be a little more to this than just a KASLR bypass, and the KPTI is not without a performance impact from what I've read so far, but I'm waiting for more details to come to light before I settle on a final position. For now, I'm going to leave it at the default 'enabled' value.
OMFG! Now I read about the performance impact of this KPTI; around 30% ...
We must have AMD specific kernels, and leave the Intel fans to be "happy".
Ouch, I am also Intel user too.
Yeah, you are right. It is a hardware vulnerability little like an old aged elephant. Everyone patches the kernels; from Windows and MacOS/X to Linux and BSD.
Last edited by Darth Vader; 01-02-2018 at 09:00 PM.
Does anyone who tried the new kernel notice a visible slowdown? AFAIK The expected slowdown for typical workloads is expected to be much less (around 5%). One of the patches in the 4.14.11 Changelog mentions dosemu and Wine as being "significantly" affected.
AMD processors are not subject to the types of attacks that the kernel
page table isolation feature protects against. The AMD microarchitecture
does not allow memory references, including speculative references, that
access higher privileged data when running in a lesser privileged mode
when that access would result in a page fault.
Disable page table isolation by default on AMD processors by not setting
the X86_BUG_CPU_INSECURE feature, which controls whether X86_FEATURE_PTI
is set.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
arch/x86/kernel/cpu/common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index c47de4e..7d9e3b0 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -923,8 +923,8 @@ static void __init early_identify_cpu(struct cpuinfo_x86 *c)
setup_force_cpu_cap(X86_FEATURE_ALWAYS);
- /* Assume for now that ALL x86 CPUs are insecure */
- setup_force_cpu_bug(X86_BUG_CPU_INSECURE);
+ if (c->x86_vendor != X86_VENDOR_AMD)
+ setup_force_cpu_bug(X86_BUG_CPU_INSECURE);
fpu__init_system(c);
The Magic Words are: CPU BUG!
And I am glad to see that that KPTI is automatically disabled for AMD processors.
Last edited by Darth Vader; 01-03-2018 at 07:34 AM.
Does anyone who tried the new kernel notice a visible slowdown? AFAIK The expected slowdown for typical workloads is expected to be much less (around 5%). One of the patches in the 4.14.11 Changelog mentions dosemu and Wine as being "significantly" affected.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
