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

News
By
published

"Let's put the onus on where the blame lies, and not just take any random [****] from bad hardware and say 'oh, it *might* be a problem'"

Linus Torvalds, creator and frequent maintainer of the open source Linux kernel
(Image credit: Lf Asia on 500px.com (via WikiMedia Commons))

Linux creator and kernel maintainer Linus Torvalds recently made outspoken comments on the Linux kernel mailing list thread criticizing changes made to the kernel purely to account for buggy hardware and theoretical attacks, per Phoronix. This was prompted by proposed code that Torvalds pointed out likely wouldn't work with Intel Arrow Lake and Lunar Lake CPUs due to their use of Linear Address Masking (LAM), an Intel feature allowing software to use untranslated address bits for metadata within 64-bit linear addresses.

"Honestly," Linus Torvalds starts his reply, "I'm pretty damn fed up with buggy hardware and completely theoretical attacks that have never actually shown themselves to be used in practice."

He continues, "So I think this time we push back on the hardware people and tell them it's *THEIR* damn problem, and if they can't even be bothered to say yay-or-nay, we just sit tight."

Finally, Torvalds declares angrily, "Because dammit, let's put the onus on where the blame lies, and not just take any random shit from bad hardware and say 'oh, but it *might* be a problem.'"

Yesterday morning, Intel engineer Kirill Shitemov also commented on that thread, clarifying that "LAM brings own speculation issues that is going to be addressed by LASS. There was a patch to disable LAM until LASS is landed, but it never got applied for some reason." Per Phoronix, "LASS is the Linear Space Separation Support as a new security feature to prevent malicious virtual address space accesses across user/kernel mode."

This seems to address Linus' concerns at least somewhat, but of course, we'll need long-term hindsight to determine how much this actually changes Linux kernel maintenance moving forward.

Torvalds' comments do add some additional Free and Open Source Software (FOSS)-centric context to the widespread controversies around Intel's 13th and 14th Gen CPU failures and widespread. Performance-impacting CPU security mitigations, though. Unlike these giant tech companies that are at least being paid to deal with these things, FOSS developers are under constant pressure to update projects to be compatible with hardware that is sometimes genuinely defective in its design.

Christopher Harper
Christopher Harper
Contributing Writer

Christopher Harper has been a successful freelance tech writer specializing in PC hardware and gaming since 2015, and ghostwrote for various B2B clients in High School before that. Outside of work, Christopher is best known to friends and rivals as an active competitive player in various eSports (particularly fighting games and arena shooters) and a purveyor of music ranging from Jimi Hendrix to Killer Mike to the Sonic Adventure 2 soundtrack.

20 Comments Comment from the forums
  • Heat_Fan89
    I agree with him 100% on theoretical attacks, it really gets tiring.
    Reply
  • 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.
    Reply
  • 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.
    Reply
  • -Fran-
    DS426 said:
    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.
    Reply
  • JamesJones44
    chaz_music said:
    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.
    Reply
  • Jeeman
    Heat_Fan89 said:
    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?
    Reply
  • 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.
    Reply
  • -Fran-
    frankieXZ said:
    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.
    Reply
  • jlake3
    chaz_music said:
    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.
    Reply
  • 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.
    Reply