Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Intel Security

Linus Torvalds Says Intel Needs To Admit It Has Issues With CPUs ( 271

troublemaker_23 shares an article from ITWire: Linux creator Linus Torvalds has had some harsh words for Intel in the course of a discussion about patches for two bugs that were found to affect most of the company's processors... Torvalds was clearly unimpressed by Intel's bid to play down the crisis through its media statements, saying: "I think somebody inside of Intel needs to really take a long hard look at their CPUs, and actually admit that they have issues instead of writing PR blurbs that say that everything works as designed... Or is Intel basically saying 'we are committed to selling you shit forever and ever, and never fixing anything'?" he asked. "Because if that's the case, maybe we should start looking towards the ARM64 people more."
Elsewhere Linus told ZDNet that "there's no one number" for the performance drop users will experience after patches. "It will depend on your hardware and on your load. I think 5 percent for a load with a noticeable kernel component (e.g. a database) is roughly in the right ballpark. But if you do micro-benchmarks that really try to stress it, you might see double-digit performance degradation. A number of loads will spend almost all their time in user space, and not see much of an impact at all."
This discussion has been archived. No new comments can be posted.

Linus Torvalds Says Intel Needs To Admit It Has Issues With CPUs

Comments Filter:
    • CentOS's kernel-plus 7.4 boots fine under Xen 4.9 running with Fedora 27, all with the latest patches.

      RHAT doesn't give a damn about Xen. Maybe they didn't break it intentionally on 7.4 but they didn't test it either. 'Cause nobody like Amazon uses Xen, right?

      But buy their KVM product, it's much less prone to [their] breakage. Hah. Debian isn't hostile to Xen, nor is Arch.

      • I think that the bad kernel package has been withdrawn.

      • Redhat's support is very selective these days. There is a clear imperative to more quickly support products that they can wrap a support contract around like RHEL. I understand that since they've got Wall Street to please, salaries to pay, etc., but it would not be a lot of extra effort to also support the free products in their ecosystem at a similar cadence. As a result, I have been weaning applications off Redhat products. The availability of support is great, but the vast majority of my applications

    • I like this comment "Don't these kernel updates get any testing? I realize that CentOS may have very limited resources for testing, but doesn't Red Hat test these updates?".
      What? Maybe it compiled just fine!
  • Or is Intel basically saying 'we are committed to selling you shit forever and ever, and never fixing anything'?" he asked. "Because if that's the case, maybe we should start looking towards the ARM64 people more."

    Not sure how much Intel really cares about threats from the free Linux community - vs Microsoft, etc... To quote Rick Sanchez, "What -- What's this supposed to accomplish? We have infinite grand-kids. You're trying to use Disney bucks at a Caesar's Palace here."

    • Not sure how much Intel really cares about threats from the free Linux community - vs Microsoft, etc...

      Do they care about selling CPUs? Do they care about the competition who clearly has the advantage now? If they do they better get their shit together and stop pissing off the IT guys that will make or break them.

      • by jwhyche ( 6192 )

        What advantage are you talking about and what competitor? Do you mean AMD? I'm sure you do and yes you would be correct they have a slight advantage now but the funny thing is I don't see them running to exploit it. An advantage is nothing if you don't exploit it and that is just what I'm seeing AMD not do.

    • Threats from who?
      [Intel] was the largest corporate sponsor of new contributions to the Linux computer operating system, according to a report Wednesday morning from the Linux Foundation []

      Intel is a big part of that community.

      They were the top corporate contributor in 2015 and 2016. Before that they were second to Redhat. Before that they were third to Redhat and Novell.

    • by Tough Love ( 215404 ) on Saturday January 06, 2018 @08:59PM (#55877439)

      Or is Intel basically saying 'we are committed to selling you shit forever and ever, and never fixing anything'?" he asked. "Because if that's the case, maybe we should start looking towards the ARM64 people more."

      Not sure how much Intel really cares about threats from the free Linux community - vs Microsoft, etc...

      Out of touch much? Intel now derives a large and expanding portion of its revenue from Linux servers, versus the shrinking Wintel market. Intel cares every much about its image in the Linux community, it is very easy to drive devs away to ARM and AMD. Intel has done a respectable job of keeping that brain drain under control and anything else would just be suicidal.

      • by jwhyche ( 6192 )

        Out of touch much? Intel now derives a large and expanding portion of its revenue from Linux servers, versus the shrinking Wintel market

        From what I've been seeing over the last 10 years this observation matches what I've been seeing. Not just with intel but with server sales from Dell and IBM too.

        Back in 2008 I priced out 150 dell 2950 for a datacenter. The price automatically included a windows license for each server. It it took me 2 weeks to pound it through some thick skulls that we didn't want or going to pay the microsoft tax.

        I priced out a few dozen Dell servers a few years back. When I ordered them with Linux on them nobod

  • by BlueCoder ( 223005 ) on Saturday January 06, 2018 @04:31PM (#55876383)

    The kernel memory read issue was 90% a design decision to improve performance. I would argue that it should actually be an option in the BIOS. The fact the AMD didn't do this with zen to match Intel is what is really interesting. Intel did a little cheat to improve performance but AMD didn't and chose caution.

    To me it's not a clear cut case if you brought a class action into court. The engineers cheated a bit but didn't think it would turn into such a security hole. I can just imagine the closing arguments... point is computers are complicated and not necessarily a guaranteed thing except that they can compute.

    • Re: (Score:3, Insightful)

      by Anonymous Coward

      the Intel bug does not look like an intentional design decision to me, more like an oversight. the performance win speculating over security domain page boundaries can not be that large, I would guess it should be 1% loss.
      IMHO someone just did not really think all the details and consequences of this boundary case thru, ...

    • by Mal-2 ( 675116 )

      It doesn't matter if Intel intended to open up a security hole or not. The tort system in the U.S. is one of strict liability. If something goes wrong with your product, and you didn't explicitly say NOT to do that, then you're on the hook. It doesn't matter what your intentions were, only the result.

    • Your subject line is idiotic. There is nothing minor about millions of computers having authentication secrets exposed.

    • The air in your room is constantly computing, the electrons in all matter
      on earth are constantly computing.

      The point with processors like Intel's is that it is easier to control
      the computation with standard, widely available methods (software). This bug inhibits this control. Which was their only point to begin with, as compared to "computation" devices like air.

  • by epine ( 68316 ) on Saturday January 06, 2018 @04:35PM (#55876401)

    So you decide to speculate a future instruction.

    It happens to be a load.

    The address is [ebp+eax]. A recent instruction had the same address field, so you speculate that it remained the same.

    Now you need to translate the address. The translate might be in the TLB, but you check, and for some reason it isn't.

    So you decide to speculatively trigger TLB load.

    Finally, you get a physical address back. A previous write instruction is not yet translated, but it seems unlikely it will translate to the same address, so you decide to speculate the load and you make a cache line request from L1.

    It might be in L1, but it isn't. So you decide to speculate again, and request it from L2. Not in L3, either, so finally you speculate the load all the way to external memory. When the cache line returns, you speculatively cache this at all levels. Then you speculatively store the value into the target register. The final step was the least dangerous, because you can dump this later, no harm to the abstract state. But the concrete side effects on the TLB and the three layers of cache are not so easily reversed. In theory, the concrete state doesn't leak into the abstract state. Because we simply don't like to think about time (time, above all things, being never simple; hint: functional programming has no time, only progress).

    Not all speculative architectures are created equal. There are many opportunities for an architecture to Just Say No.

    With cache coherence, you have the MESI protocol [] (and its bewildering shoe full of second cousins).

    One could apply the same concept of "exclusive" to the page tables, an exclusively mapped page being one mapped only onto into the current process and security context. If TLB speculation hits a different kind of beast, abandon speculation. Same thing with cache fill. Concrete side effects thereby only accrue from speculation to exclusive resources. Share-nothing usually solves most problems in computer science (except performance, which is mainly defined in the time domain).

    I'm gong to abandon the back of my envelope here, One has to think really damn hard to take this to the next logical level, and frankly, I don't have a damn to spare right this very minute.

    But please, advance the conversation beyond:

    [_] has speculation
    [_] does not have speculation

    Because that is Intel's diabolical trap, for as long as their PR department can continue to get away with tugging their wool in broad daylight.

    • I got to thinking about Google's clever Retpoline from the other day.
      Google Says CPU Patches Cause 'Negligible Impact On Performance' With New 'Retpoline' Technique []

      The problem is, this is not invariant under peephole optimization. These instruction sequences need to be handled by the compiler through a very literal minded end-game code generation pass.

      Which got me to thinking about RETGUARD gadgets.

      RETGUARD, the OpenBSD next level in exploit mitigation, is about to debut []
      Retguard: OpenBSD/Clang []

      I know, both

      • Are speculative gadgets a problem here? If so, Google's clever patch is going to need a sump pump bolted on the side.

        Sure, speculative gadgets are a problem... which is why the Retpoline solution has to be applied to every binary in the system. And it has to be implemented in the code generation back-end. The back-end has to scan for potential gadgets and retpoline them.

        And then you get into the whole problem of deterministic compilation [] in order to be certain that the executable you build contains the necessary mitigations (or some tricky post-compile analysis I sure don't wish to develop myself).

        That's an easy problem for Google and, I expect, other big cloud systems. Google builds everything itself, including compilers. If you're big enough and have the engineering resources, that makes sense for lots of other reasons anyway.

        For everyone else,

  • by mrflash818 ( 226638 ) on Saturday January 06, 2018 @07:13PM (#55877015) Homepage Journal

    The severity of the FDIV bug is debated. Intel, producer of the affected chip, claims that the common user would experience it once every 27,000 years while IBM, manufacturer of a chip competing with Intel's Pentium, claims that the common user would experience it once every 24 days.[citation needed] Though rarely encountered by most users (Byte magazine estimated that 1 in 9 billion floating point divides with random parameters would produce inaccurate results),[3] both the flaw and Intel's initial handling of the matter were heavily criticized by the tech community.

    In December 1994, Intel recalled the defective processors. In January 1995, Intel announced "a pre-tax charge of $475 million against earnings, ostensibly the total cost associated with replacement of the flawed processors."[1] []

  • His quote: "Or is Intel basically saying 'we are committed to selling you shit forever and ever, and never fixing anything'?"

    I think the record until now clearly shows that Intel's CPU products have actually been generally pretty good and that they actually do release fixes for their fuckups.

    Let's put this into perspective: its a security hole not a major functional failure. People are having to get amazingly creative in finding new ways to break into anything. Basically anything even slightly complex has p

  • Ryzen my friends (Score:4, Informative)

    by Tough Love ( 215404 ) on Saturday January 06, 2018 @07:48PM (#55877163)

    Meanwhile, enjoying my Ryzen, largely unaffected by Meltdown or Spectre [] in spite of some well meaning or self-serving FUD to the the contrary. Yes, I got an early part with the segfault bug, but AMD RMAed without fuss when presented with appropriate []>test data to eliminate the possibility of bad motherboard, memory or overclocking. Quite different attitude compared to Intel! And the Ryzen is sweet - 16 high performing CPU threads, tiny power consumption at idle and respectable under full load. Integer performance, iow, compiling is stellar and floating point is not shabby. Basically, Ryzen out-cores Intel's competing i7 parts by a wide margin, acquits itself well in single-core too and draws so little power that the CPU fan is off or barely turning for most normal desktop usage. And when all 16 threads are going full blast, iow doing real work, total system power is around 120 watts, the system still runs nearly silent. Can't say enough good things about it.

    If you do step up to Ryzen, be aware of two things: 1) Check the production week stamped on the CPU, it has the form 17xx where xx is the week... make sure this is higher than week 25, otherwise run to verify the segfault bug and get an RMA promptly from AMD's only support site, if you see it. Windows users need to boot Linux to do this, get a live iso on a usb stick to do this in maximum comfort, and preferably, just overwrite Windows when done :-) Most of that early production is sold out already, so the chance of getting a bad part is slim, but be aware. Windows users for the most part don't seem to see any issue even with the early parts. Good for them, but it goes along with significantly lower performance without the upgrade to LInux :-) 2) Be aware that Ryzen has no on-board GPU, in spite of the fact that your Ryzen motherboard has video connectors... these are for AMD's APUs, which use the same socket. Respectable chips in their own right especially in terms of value for money, but when you run Ryzen you need to run a discrete GPU too. This is what you want anyway, because what is the point of crippling your high end desktop processor with a mickey mouse embedded GPU? To be specific: AMD's fattest APU has eight compute units (512 stream processors) vs 64 in the current Vega part, plus uses processor memory instead of higher bandwidth dedicated graphics memory.

    Of course, what I really want is a threadripper... that's next.

  • Intel has said they are working together with oem partners blah blah but i have yet to see their microcode patches posted on their website. I build my own machine, i can't contact Lenovo (who haven't even acknowledged most of their products are vulnerable)

    • In this case the CPU cannot be patched. This defect is permanent, it can never be fixed in the current processors. When new processors come out (assuming the next gen uses the same socket -- a crap shoot) you could replace the CPU. The fix is for the OSes to basically compensate and work around the defects - which may have moderate to severe performance penalties depending on CPU and what you are doing. What Intel is saying is actually a lie, they are helping the OS or "bios" vendors basically duct tape
    • You believed their lies. There is no microcode fix. The processor is flawed and needs to be replaced.
  • by Tom ( 822 )

    Since this news broke, I've been sitting on one question that bothers me, and I can't figure out the answer:

    How much would this kind of global, hard-to-find, not-so-hard-to-exploit-once-you-know-what-to-look-for issue been worth to an interested party in 1995?

Adding manpower to a late software project makes it later. -- F. Brooks, "The Mythical Man-Month"