Slashdot Mirror
Linux 4.19 Preparing Better CPU Security Mitigations, New EROFS File-System (phoronix.com)
An anonymous reader writes: Linus Torvalds released on Sunday Linux 4.19-rc1 that he describes as a "fairly frustrating merge window" following the new features landing over the past two weeks. What does this "pretty big release" offer? Phoronix's Linux 4.19 feature overview sheds light on more Spectre CPU mitigations for x86/POWER/s390, the new EROFS read-only Android file-system, a Raspberry Pi voltage driver, ThinkPad calculator key support, an in-kernel GPS subsystem, the Google GASKET driver framework, virtual kernel mode-setting, Qualcomm Adreno 600 series support, and many other improvements.
I got a preview of the security Code:
if (cpu_vendor == intel) {
disable_L1_cache();
disable_L2_cache();
disable_L3_cache();
disable_instr_cache();
disable_data_cache();
disable_branch_prediction();
disable_hyperthreading();
if (ultra_secure_mode == true) {
for (i=1;i=num_cores-1;i++) {
disable_core(i);
}
}
}
one can expect a heavy performance penalty, but the power consumption should go way down, so we have that going for us.
Only buy AMD.
Anons need not reply. Questions end with a question mark.
That's probably why a single kernel doesn't do all this shit. The source is there for all these features, but each kernel is customized with conditional compilation controlled by the .config file at build time.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
... has literally *nothing* to do with the kernel. There is *zero lines* of systemd code in the kernel. You can't even troll competently. Sad ... Bigly sad.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
You can order disks here: https://www.osdisc.com/
You can actually compile what you don't want out of the kernel you know... ah nevermind, most of the kernel is just drivers anyway, and there's even USB support for the human body so it is really a frakenkernel.
New ERO file-system, not mentioned in TFA, what can that be...
Slashdot, fix the reply notifications... You won't get away with it...
That's probably why a single kernel doesn't do all this shit. The source is there for all these features, but each kernel is customized with conditional compilation controlled by the .config file at build time.
While that's true most will use their distro's precompiled kernel which obviously has most things enable to support all the possible use cases their customers have. I guess it works to keep experimental code in the tree but not in the default build, but once it's lifted to "production code" I think a lot of people will get it by default.
Live today, because you never know what tomorrow brings
That is not correct. The Linux kernel supports over 30 hardware architectures so it is impossible to build it with most options enabled. Furthermore many options are suboptions. With over 1000 choices, many of which are mutually exclusive there is literally no way to build a Linux kernel with "most options enabled." Finally, most drivers are built as modules, which technically aren't "enabled" they way you are using the term unless they are loaded at runtime. Since you never built a kernel from source in your life (or you would know this) it is best to remain silent and be thought the fool you are than to open your mouth and remove all doubt as you have done.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
very well said. sadly most folks who use x86/x86-64 distros don't see the delineation as clearly as the embedded folks. these projects spend months patching linux drivers to a specific SoC/SoM and know precisely where the kernel stops - and their fallback is busybox for what most people recognize as the OS. Patching/customizing linux is not for the faint hearted (and I've come to hate their use of macros with some passion) but one of the sad side effects of (the usability of) Ubuntu is that we have a lot of linux "experts" who don't seem to know where the kernel actually stops. I sometimes with building your own linux kernel went more mainstream - would maybe polish some of the stuff more and teach folks what exactly the kernel does.
Message passing was stupid and therefore ultimately failed. Let's move on.
The summary left out a pretty important point from the article, in my opinion:
The USB Type-C display mode alternate driver was merged to the mainline kernel for stepping up the DP Type-C support, but more work on integrating with the DRM drivers is still being tackled.
So what this means, is that you have a dongle or monitor cable with USB-C on one end, and DisplayPort on the other end.
This is important, because I expect to see new laptops coming out, that only have USB-C/Thunderbolt 3. The obvious existing ones are from Apple, but I expect that more laptops will come out with no other ports except USB-C/Thunderbolt 3.
8 of 13 people found this answer helpful. Did you?
And now everyone builds their own custom message queue to do IPC. Message passing isn't a bad idea, it's a bad idea to use it for *everything*
"First they came for the slanderers and i said nothing."
well, computers aren't simple things anymore, should a single cpu do all the things it does today? compared to the old days (oh my) where it was possible for one person to know all the ins & outs of a whole machine, or where the circuit diagrams were included in the manual. impossible today.
that said, the linux kernel isn't as bad as you make it out to be. a lot of stuff is left to handle specifically in userland, i think it is even the preference of Linus to move anything out of the kernel that is not really needed. there have been several big examples of this in the last 27 years when things that were initially part of the kernel were moved out.
On a long enough timeline, the survival rate for everyone drops to zero.
By looking at the name of EROFS I thought we will finally have a dedicated porn filesystem. So disappointed.
Yes you were & are.
Linux has been modular for decades, so you only include what you use. So if you don't use the filesystem or the patch, you don't install the filesystem or patch.
Interactions should only be with the local subsystem, so a hundred modules of a hundred thousand makes no difference. You're still only looking at core functions (kernel core functions plus local API). The subsystem takes care of security, etc.
With kernel threads, non-interacting code blocks don't need to risk blocking each other.
Because context switches are the things that kill performance, reducing context switches by having all of a module in the kernel rather than half in is a good approach. Exokernels (where only essential code is ring 0) are only faster if you're not having to make a lot of calls across. Microkernels are generally slower than monolithic, modular or eco.
At this point, the cost of mitigating the Intel bugs is more than the cost of recalling the chips or the cost of using formal methods to prevent such bugs arising to begin with. This shows why doing it right is better than doing it cheaply. (Something I've said for the past 30 years.)
Frankly, I'm not impressed with the improvements of the last few releases. Zero copy was introduced both with Von Jacobson Channels and the RDMA Consortium, again many decades ago. It should be standard for all I/O subsystems. I'm also still waiting for the plugable scheduler, as no individual scheduler is right for all systems.
And if people really want a lighter kernel, then have the filesystem and network subsystems standalone. If you can upload them on to a sufficiently advanced disk controer/network card respectively, you can offload all that work and use message passing to mask where it's running. Decentralization. Reduces the consequence of bad CPUs, you can't interfere with code that isn't running on it, and might improve performance as the CPU isn't hogged.
Some parts of the kernel may be buggy or vulnerable to regression. If they can be rewritten in Verified C, or so that they can be praised with Why3, you can start to develop theorems that will establish if the code is behaving as you'd expect.
Lost track of whether SGI's kernel debugger was fully integrated with the mainline. If not, why not and can someone please bring it up to date and get it looked at properly?
Same with Web10g, the network profiling system. We could do a lot with that if it were, ummm, used by people and not hiding in obscurity.
What's the story with badmem? Now that cheapo space missions are going to be common, Linux needs to support the ability to be used in a slowly degrading computer.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
What's the deal with the GPS subsystem that was mentioned for 4.19?
What can this subsystem do and why does it have to be in the kernel?
And yes, I buy AMD where I can.
Depends on what you've mapped it to...
The summary left out a pretty important point from the article, in my opinion:
The USB Type-C display mode alternate driver was merged to the mainline kernel for stepping up the DP Type-C support, but more work on integrating with the DRM drivers is still being tackled.
Slight confusing:
* DP = DisplayPort: https://www.displayport.org/displayport-over-usb-c/
But if you transpose them:
* PD = PowerDelivery: http://www.usb.org/developers/powerdelivery/
Of course you can connect a display using DP to a laptop, and also have the screen have PD to charge the battery.
Now with 150% more recycled pixels!
#DeleteFacebook
Everyone builds their own message queue because there aren't any known good message queue libs, only standards which don't really fit anyone but pretending to be usable for everything.
The best message queue libs I've seen have always been internal company projects, and even they weren't generic enough, and were regularly bypassed for higher efficiency.
It's the same as any other protocol. We need very generic tools to properly explain specific protocols for specific tasks.
And the part of protocol design where we fail most is layering and extension. When underlying protocols have even minor design flaws, it makes layering impractical and generates yet another protocol to add to the confusion.
I believe in dividing up software (into processes) as much as possible in userspace, but the interfaces need to be simultaneously human- and machine-accessible for the division to carry any reasonable cost/benefit-ratio since it's already hard to keep people from baking things together when they are in a hurry.
I had similar thoughts, but I'm not really sure why there aren't any good message queue libs. It doesn't make sense.
"First they came for the slanderers and i said nothing."