News Linus Torvalds is "fed up with buggy hardware and completely theoretical attacks" — Linux kernel creator lashes out ahead of proposed kernel code...

[Admin]

Linus Torvalds speaks out against pre-emptive kernel code changes due to buggy or exploited CPUs.

Linus Torvalds is "fed up with buggy hardware and completely theoretical attacks" — Linux kernel creator lashes out ahead of proposed kernel code... : Read more

 

[Heat_Fan89]

I agree with him 100% on theoretical attacks, it really gets tiring.

 

[chaz_music]

I agree wholeheartedly with Linus. The PC industry focuses solely on speed and time to market, with little to no consideration on safety, security, user abuse, and other important actors. This is how we ended up with USB 1.0 (major flop). But note: the user does not spend money usually for safety or speed. When a new CPU or motherboard series comes out, there are many first adopters who will buy something without waiting to see if others find a bug with it. Reliability engineers will say "Don't buy rev one of anything".

And it isn't just computers . How about the Kia starter hack, or other cars allowing starting the engine using the CAN bus with a simple command? I never design hardware without thinking through the safety and security of the application. especially user abuse. Those damn users will mess your day up. So will maligned players.

Wait until someone figures out how to send a fake signal to your car's pedestrian detection system while going down the highway. And hope the person behind you doesn't plow into your bumper.

In many cases, this is plainly due to bonehead or lazy concept engineering. I once found a SCADA device (in a power grid application) sending clear ASCII as part of the control signalling. Open ASCII. Sweet. The power grid engineer who was with me when we found this couldn't stop his profanity for 10 minutes.

In the PC world, this would likely be fixed with an OS update.

 

[DS426]

I agree with him but I'd still expect that security-oriented software devs are creating the mitigations for theoretical attacks and CVE's and then a core group of Linux maintainers decide on whether the mitigation is turned on or off by default. Using Intel is an example, they would create or at least oversee the patch and then discuss with Linus on the gang on real-world likelihood and impact.

This doesn't need to be an emotional affair (though I completely understand Linus lashing out) -- there's an intelligent, orderly, controlled series of people, processes, and procedures to balance all this out.

 

[-Fran-]

I agree with him but I'd still expect that security-oriented software devs are creating the mitigations for theoretical attacks and CVE's and then a core group of Linux maintainers decide on whether the mitigation is turned on or off by default. Using Intel is an example, they would create or at least oversee the patch and then discuss with Linus on the gang on real-world likelihood and impact.

This doesn't need to be an emotional affair (though I completely understand Linus lashing out) -- there's an intelligent, orderly, controlled series of people, processes, and procedures to balance all this out.

I'll latch onto the bold part: is that really the case though?

Most of us that work closely to the hardware and always get showered with "security first!111!!!!!" slogans know that managers still like to rush the turds out and press software (SecDevOps mainly) teams to get it out, everything else be damned.

So, given my own personal experience in my limited view of the Industry, I have to ask if that is really the case.

The best counter example outside of my own experience would be the CrowdStrike and multiple AntiVirus vendor stupidity which has lead to unfunny outcomes for many.

Regards.

 

[JamesJones44]

And it isn't just computers . How about the Kia starter hack, or other cars allowing starting the engine using the CAN bus with a simple command? I never design hardware without thinking through the safety and security of the application. especially user abuse. Those damn users will mess your day up. So will maligned players.

Sadly, being able to execute critical vehicle functions with CAN protocol commands is way more common than people know. SOME companies put critical commands behind an algorithm wall, but most of those algorithms are not super sophisticated, with some time and willingness many could be cracked.

 

[Jeeman]

I agree with him 100% on theoretical attacks, it really gets tiring.

So most mitigations since 2018 from Spectre and Meltdown all the way to today are generally not necessary and an unnecessary load on CPU resources thus slowing down the system?

 

[frankieXZ]

Gosh, this is not news. Linus is a s/w guy afterall and we've seen his tantrums over decades.

Hardware guys (and firmware): software is spaghetti code, buggy and slow as *** and needs a reboot
Software guys (incl Linus): hardware is buggy overheats, crashes and needs a reboot.
Math guys: you're using the logic or language wrong
Physics guys: chuckles (knowing stability of ADC converters)

I sure would entertain a kernel other than Linux (sure less than MSFT, but headaches do exists), but it's hard to compete with free.

 

[-Fran-]

Gosh, this is not news. Linus is a s/w guy afterall and we've seen his tantrums over decades.

Hardware guys (and firmware): software is spaghetti code, buggy and slow as *** and needs a reboot
Software guys (incl Linus): hardware is buggy overheats, crashes and needs a reboot.
Math guys: you're using the logic or language wrong
Physics guys: chuckles (knowing stability of ADC converters)

I sure would entertain a kernel other than Linux (sure less than MSFT, but headaches do exists), but it's hard to compete with free.

There's plenty other options if you want to use them, besides the Linux one. The biggest "competitor" to it is FreeBSD. From the actual OS perspective, there's even more. Not Unix based, but most are for research or very specific and not FOSS.

Regards.

 

[jlake3]

I agree wholeheartedly with Linus. The PC industry focuses solely on speed and time to market, with little to no consideration on safety, security, user abuse, and other important actors. This is how we ended up with USB 1.0 (major flop). But note: the user does not spend money usually for safety or speed. When a new CPU or motherboard series comes out, there are many first adopters who will buy something without waiting to see if others find a bug with it. Reliability engineers will say "Don't buy rev one of anything".

And it isn't just computers . How about the Kia starter hack, or other cars allowing starting the engine using the CAN bus with a simple command? I never design hardware without thinking through the safety and security of the application. especially user abuse. Those damn users will mess your day up. So will maligned players.

Wait until someone figures out how to send a fake signal to your car's pedestrian detection system while going down the highway. And hope the person behind you doesn't plow into your bumper.

There is definitely still plenty of potential for first model year weirdness, but both Kia's starter hack and CAN vulnerabilities are kinda weird as examples of a "rev one" problem.

The Kia issue is the result of Hyundai/Kia sticking with physical keys and ignition cylinders while everyone else was moving more quickly towards electronic authentication and push-button start, and creating a bad design by further cheapening down already old tech. As a user, the physical key would have looked like a continuation of what worked, where the push button would have looked like rev one of something new. And it didn't blow up publicly until more than 10 years after the first affected models were made.

CAN is a 40 year old protocol at it's core, which was initially only used for components buried deep in the vehicle where if you could get to them to launch an attack, you already had full control of everything. No one expected in the 1980's that it was going to be used for checking headlight status, or that you'd have such portable devices to hack it. The headlight module designers 40 years later probably should have known CAN was a bad idea for that application, but users aren't going to know that a car has the first generation of CAN networked headlights and thus should avoid it.

 

[Mama Changa]

Good on you Linus, I've felt the same for years and refuse to apply these hardware patches where possible. I'm only talking PC. Obviously some of these vulnerabilities coiuld be exploited in different settings, but for the vast majority of desktop users it's scaremongering at best.

 

[Kamen Rider Blade]

There's plenty other options if you want to use them, besides the Linux one. The biggest "competitor" to it is FreeBSD. From the actual OS perspective, there's even more. Not Unix based, but most are for research or very specific and not FOSS.

I honestly wish FreeBSD would've been the popular Open Source OS instead of Linux.

It's sad that Linux is the one that ended up more popular for whatever reason.

 

[mitch074]

Gosh, this is not news. Linus is a s/w guy afterall and we've seen his tantrums over decades.

Hardware guys (and firmware): software is spaghetti code, buggy and slow as *** and needs a reboot
Software guys (incl Linus): hardware is buggy overheats, crashes and needs a reboot.
Math guys: you're using the logic or language wrong
Physics guys: chuckles (knowing stability of ADC converters)

I sure would entertain a kernel other than Linux (sure less than MSFT, but headaches do exists), but it's hard to compete with free.

He did work at Transmeta for quite a while - I wouldn't dismiss his hardware voodoo so readily.

 

[mitch074]

I honestly wish FreeBSD would've been the popular Open Source OS instead of Linux.

It's sad that Linux is the one that ended up more popular for whatever reason.

So did Linus originally, actually. But BSD developed far too slowly to ever become viable commercially.

 

[SeaTech]

Anybody else notice a problematic typo: The intel engineer's name in the article is not Kirill Shitemov...but instead Kirill Shutemov ...smh of course 'u' is right next to 'i' on the keyboard, but this is quite an unfortunate oversight.

 

[bit_user]

I sure would entertain a kernel other than Linux (sure less than MSFT, but headaches do exists), but it's hard to compete with free.

As others have mentioned, Linux isn't the only free kernel out there.

P.S. I loved the rest of your post! It's funny because it's true!
: D

I honestly wish FreeBSD would've been the popular Open Source OS instead of Linux.

It's sad that Linux is the one that ended up more popular for whatever reason.

The two things Linux has going for it are the GPL license and critical mass. The former effectively forces everyone to upstream their patches. The latter means that if Linux doesn't support your hardware, software, protocol, etc., it's not going anywhere. Because of this, you can build a single kernel that supports a wide range of different hardware, peripherals, protocols and features.

This is why the BSD's can never compete. The best they can do is narrowly focus on a specific range of hardware and uses cases, mostly just commodity stuff. They just will never have the broad range of hardware & software support that Linux has.

 

[JamesJones44]

CAN is a 40 year old protocol at it's core, which was initially only used for components buried deep in the vehicle where if you could get to them to launch an attack, you already had full control of everything. No one expected in the 1980's that it was going to be used for checking headlight status, or that you'd have such portable devices to hack it. The headlight module designers 40 years later probably should have known CAN was a bad idea for that application, but users aren't going to know that a car has the first generation of CAN networked headlights and thus should avoid it.

Most autos use CAN 2.0 (developed in the early 90s) or CAN FD (developed in early 2010s). They are architecturally different than the original CAN version and have better provisions for modern day issues than the original 1980s version. CAN is also mandated to be used in many countries for ODBII/Diagnostic communications at a minimum (US, EU, Japan, etc.). For that reason many use it throughout the vehicle unless it's a low cost/speed ECU which typically uses LIN or high speed which uses optical networks (MOST, FlexRay, even Ethernet in a growing number of cases).

Still, the point about customers is very valid, they aren't going to know what version a car is running or that an ECU supplier or vehicle manufacture has poor security and allows for an attack.

 

[AkroZ]

I honestly wish FreeBSD would've been the popular Open Source OS instead of Linux.

It's sad that Linux is the one that ended up more popular for whatever reason.

BSD was in a long lawsuit between Beckerley and AT&T, many fork of BSD was made (FreeBSD is just one of them), the futur was uncertain. This has given Linux the time to develop and it was unified, people have switch from BSD to Linux.
Nowaday Linux development is fragmented in teams when FreeBSD is managed by one team. This make FreeBSD functionalities more coherents than Linux but it is more difficult to keep up the pace.

Note: Mac OS X is a merge of FreeBSD (based on BSD of Bill Joy), Mach (Richard Rashid and Avie Tevanian) and NextStep (Steve Jobs).
GNU/Linux is a merge of GNU (Richard Stallman) and Linux (Linus Torvald inspired by Minix of Andrew Tanenbaum). GNU/Linux is what we call commonly as Linux.

 

[bit_user]

Note: Mac OS X is a merge of FreeBSD (based on BSD of Bill Joy), Mach (Richard Rashid and Avie Tevanian) and NextStep (Steve Jobs).

Apple's own developer docs say they took only a few specific parts from BSD, I think people tend to overplay this aspect. A close read of this doc, last updated more than a decade ago, basically lays out what they took and how much they'd already changed about it.

https://developer.apple.com/library.../apple_ref/doc/uid/TP30000905-CH214-TPXREF101
​

The same guide explains how their kernel has evolved from Mach 3.0:

https://developer.apple.com/library.../apple_ref/doc/uid/TP30000905-CH209-TPXREF101
​

As for the NextSTEP influence, MacOS X basically is NextSTEP. That's where the FreeBSD and Mach stuff came from, in the first place!

GNU/Linux is a merge of GNU (Richard Stallman) and Linux (Linus Torvald inspired by Minix of Andrew Tanenbaum). GNU/Linux is what we call commonly as Linux.

Linux is the kernel. GNU provided the userspace tools, compiler, and C library. Linus also adopted GPL as the license for the kernel, which probably turned out to be the single most important decision in Linux' success.

Linux doesn't have to be used with the GNU stuff. For instance, Google ripped out all of it and replaced it with other userspace components, in Android.

Even in mainstream distros, the GNU components are slowly dropping away. There's a Rust-rewrite of the standard UNIX commandline utilities, there's the LLVM/Clang compiler and other C Libraries... Before long, it probably wouldn't be too hard to make a desktop Linux distro that looks and feels pretty standard, but lacks all GNU components.

 

[Kamen Rider Blade]

BSD was in a long lawsuit between Beckerley and AT&T, many fork of BSD was made (FreeBSD is just one of them), the futur was uncertain. This has given Linux the time to develop and it was unified, people have switch from BSD to Linux.
Nowaday Linux development is fragmented in teams when FreeBSD is managed by one team. This make FreeBSD functionalities more coherents than Linux but it is more difficult to keep up the pace.

Note: Mac OS X is a merge of FreeBSD (based on BSD of Bill Joy), Mach (Richard Rashid and Avie Tevanian) and NextStep (Steve Jobs).
GNU/Linux is a merge of GNU (Richard Stallman) and Linux (Linus Torvald inspired by Minix of Andrew Tanenbaum). GNU/Linux is what we call commonly as Linux.

Is there any chance we can convince more of the Linux community to come back to BSD, either FreeBSD or OpenBSD?

 

[bit_user]

Is there any chance we can convince more of the Linux community to come back to BSD, either FreeBSD or OpenBSD?

I have no idea, but I think the main commercial interests are going to stay on Linux and that's the main thing that counts. They're the ones doing most of the hardware support and network stack work. In fact, I'll bet the overwhelming number of kernel patches are now by companies, with most of the rest probably coming from university-backed researchers.

That's not to say FreeBSD can't grow from where it's at. I'm sure you can find people in the community who do advocacy and talk to them.