Slashdot Mirror


'Next Generation' Flaws Found on Computer Processors (reuters.com)

An anonymous reader shares a report: Researchers have found eight new flaws in computer central processing units that resemble the Meltdown and Spectre bugs revealed in January, a German computing magazine reported on Thursday. The magazine, called c't, said it was aware of Intel's plans to patch the flaws, adding that some chips designed by ARM Holdings, a unit of Japan's Softbank, might be affected, while work was continuing to establish whether Advanced Micro Devices chips were vulnerable. Meltdown and Spectre bugs could reveal the contents of a computer's central processing unit -- designed to be a secure inner sanctum -- either by bypassing hardware barriers or by tricking applications into giving up secret information.

6 of 144 comments (clear)

  1. Direct article link by isj · · Score: 4, Informative

    here (German)

    1. Re:Direct article link by Misagon · · Score: 4, Informative
      --
      "We mustn't be caught by surprise by our own advancing technology" -- Aldous Huxley
  2. Re:not buying any more new computers & gadgets by Anonymous Coward · · Score: 2, Informative

    really? Okay, they overstated it -- speculative execution isn't just a marketing gimmick, but they *did* cheap out on implementation which is why AMD was less affected.

    There are, of course, worse marketing gimmicks. Like pretending that the number of virtual cores is the same as physical cores. Anyone with technical knowledge knew better, but marketing was careful to let consumers draw wrong conclusions. Even Intel's own white paper cited a best case performance improvement with hyperthreading was ~30% (I don't recall the exact figure) and a naive implementation actually had a (minute) performance loss. By the time it was put into pentiums the hardware assured there was never any loss, but mostly there is no performance benefit to hyperthreading and definitely there is none if you are doing embarrassingly parallel tasks.

    But it is hard to overcome marketing. I do 3d rendering and tried to educate others, encourage them to do their own tests (and shared mine). The tests showed what I already knew: that performance with hyperthreading was identical to without.

    Ignoring the very real marketing impact and shortcuts for performance reasons just exacerbates the problems.

  3. Re: not buying any more new computers & gadg by Anonymous Coward · · Score: 2, Informative

    AMD Ryzen 1700, the previous gen, has, 8 cores, 16 threads, 3+ ghz base, 4ghz burst. 65watts.
    It's not much faster than my 8120fx, but it has twice the threads for half the watts.

    So its 4x as fast per watt and fits in Tiny itx builds.

  4. Re:Not a language issue by complete+loony · · Score: 3, Informative

    Right, each of the variants use that same model; code that is executed speculatively, reads from memory. Your code can see some side effect, and work out what values are in that memory. To extend that simple description slightly to the currently known variants;

    Meltdown (CVE-2017-5754). Speculatively executed code can bypass features of Intel CPU's that would normally prevent you from reading the kernel memory of the operating system. The workaround to this problem required changes to how the kernel swaps from "user mode" to "kernel mode", making this process much slower.

    Spectre-V1 (CVE-2017-5753). Untrusted code, like JIT compiled Javascript, running inside the same process as trusted code, speculatively executes a read from an array that's out of bounds. This can read any memory that the trusted process can normally read. The linux kernel includes a JIT compiler, so you could use this flaw to read any memory from the kernel. A work-around for this is specific to each program that combines trusted and untrusted code and would probably make every read from an array slower.

    Spectre-V2 (CVE-2017-5715). This one is hard to explain in a simple way, but I'll try. For some types of assembly branch instructions, you can train the CPU into branching somewhere the program wouldn't normally go. You use this to trick a trusted program into speculatively reading it's own secrets from memory (which it does normally have permission to do). Then your program can see the effects of this execution. The trusted program could be any another program, the OS kernel, or even running in another VM. It just has to be running on the same physical CPU. A work-around can be built into every compiler, by avoiding using these assembly instructions in every trusted program.

    Note that you can combine Meltdown & Spectre-V1 so that Javascript can read from kernel memory. Lots of discussions of these issues have been very murky and confusing, often getting the specific details mixed up. Like which issue can be used to read from the kernel, and which of Intel and AMD is vulnerable.

    --
    09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
  5. Re:not buying any more new computers & gadgets by TheRaven64 · · Score: 3, Informative

    Speculative execution was an idea that the CPU evaluates the two possible future state of itself then discard the outcome that doesn't happen

    I know of a couple of research processors that have worked that way, but nothing in production. It doesn't really scale, because typical C code has a branch (on average) every 7 instructions, but a modern processor can have almost 200 instructions in flight at a time. If you execute both paths (assuming branches are simple conditional branches and not computed jumps), you need to be able to handle both instruction streams for every speculative operation. That means doubling the resources every 7 instructions and you quickly run out of transistors.

    Speculative execution is about guessing what instructions you're going to run next[1] and running it as soon as you have its input operands available, then throwing away all of the state associated with the results if you guessed wrong. This is why branch mispredicts are expensive: the pipeline spends some time executing the wrong thing, then some more time discarding any of the state. The root cause of meltdown and spectre is that 'all of the state' turns out to be more than expected. In the simple case, values are loaded into (or evicted from) the cache as a result of speculatively executed instructions. This can be worked around by fetching values into some separate cache space and only writing them back to the main cache when the instructions are committed. In the more complex case, the time taken to execute and cancel the instructions varies depending on the values. That's much harder to address, because you can't simply roll back time to a little bit earlier...

    [1] In most processors, anyway. The Alpha did value speculation, so would guess the results of instructions and guessing the address of the next instruction was just a special case of this. Fortunately, no one does that anymore - Spectre on the Alpha would have been so much worse than on anything from Intel.

    --
    I am TheRaven on Soylent News