Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Saturday May 01, @10:17AM   Printer-friendly [Skip to comment(s)]

Defenseless:

Venkat's team discovered that hackers can steal data when a processor fetches commands from the micro-op cache.

"Think about a hypothetical airport security scenario where TSA lets you in without checking your boarding pass because (1) it is fast and efficient, and (2) you will be checked for your boarding pass at the gate anyway," Venkat said. "A computer processor does something similar. It predicts that the check will pass and could let instructions into the pipeline. Ultimately, if the prediction is incorrect, it will throw those instructions out of the pipeline, but this might be too late because those instructions could leave side-effects while waiting in the pipeline that an attacker could later exploit to infer secrets such as a password."

Because all current Spectre defenses protect the processor in a later stage of speculative execution, they are useless in the face of Venkat's team's new attacks. Two variants of the attacks the team discovered can steal speculatively accessed information from Intel and AMD processors.


Original Submission

Display Options Threshold/Breakthrough Reply to Article Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
  • (Score: 2) by driverless on Saturday May 01, @12:02PM (24 children)

    by driverless (4770) on Saturday May 01, @12:02PM (#1145081)

    What makes it slightly unusual is that it affects AMD as well. And probably other CPUs with a uOP cache as well.

    • (Score: 4, Insightful) by coolgopher on Saturday May 01, @12:20PM (22 children)

      by coolgopher (1157) Subscriber Badge on Saturday May 01, @12:20PM (#1145094)

      Speculative execution a bad idea.

      News at 11.

      • (Score: 2, Interesting) by Anonymous Coward on Saturday May 01, @01:30PM (12 children)

        by Anonymous Coward on Saturday May 01, @01:30PM (#1145106)
        So maybe we should just drop it entirely? It takes up space on the die through added complexity , wastes energy executing instructions that will never be used, and increases design costs.

        The same case can be made for dropping cpu support for external swap space. Most people don’t need it, it adds to the complexity of the chip and the OS, and is a security hole. Just buy more ram if you really need it.

        Kind of silly making things less efficient and more complicated than we need to, and we’re paying the price.

        • (Score: 2, Insightful) by Anonymous Coward on Saturday May 01, @02:29PM

          by Anonymous Coward on Saturday May 01, @02:29PM (#1145113)

          Better add an instruction to disable/reenable it. This way, hardcore crypto stuff (all the 0.0001% of it) could enjoy better security, and everything else, take advantage of faster execution.

        • (Score: 0, Insightful) by Anonymous Coward on Saturday May 01, @02:36PM (3 children)

          by Anonymous Coward on Saturday May 01, @02:36PM (#1145117)

          wastes energy executing instructions that will never be used,

          Never? You're so full of crap. If you're right there wouldn't be performance drops turning the stuff off etc.

           

          • (Score: 0) by Anonymous Coward on Saturday May 01, @05:38PM

            by Anonymous Coward on Saturday May 01, @05:38PM (#1145162)

            How much are we talking about? The much vaunted Hyperthreading(tm) does squat.

          • (Score: 0, Redundant) by Anonymous Coward on Saturday May 01, @06:21PM (1 child)

            by Anonymous Coward on Saturday May 01, @06:21PM (#1145175)
            You. Speculatively execute both branches, then ALWAYS throw away one branch. So you always have instructions you execute but never use the result. That’s the whole point of speculative execution - throwing out half the work done.
            • (Score: 0) by Anonymous Coward on Sunday May 02, @07:42AM

              by Anonymous Coward on Sunday May 02, @07:42AM (#1145337)

              Try to keep up if your brain is not too old and slow. OP claimed it's a waste of energy to do such stuff. But it's not a waste of energy if the resulting performance increase is worth it.

        • (Score: 5, Informative) by Immerman on Saturday May 01, @04:24PM (6 children)

          by Immerman (3985) on Saturday May 01, @04:24PM (#1145145)

          >So maybe we should just drop it entirely?
          You... really don't want to do that.

          Edit: I just realized I somehow went of on an introductory-concepts tangent that you probably don't need. Since I already did the work I'll leave it below for anyone interested.

          The TL;DR version: If you're using instruction pipelining to dramatically improve performance, as virtually all modern CPUs do, then speculative execution is necessary to keep things from slowing to a crawl every time you make a lot of conditional jumps in rapid succession - like when comparing two strings, looking up data in a container structure, etc. And speculative execution requires very little additional hardware - you can just (for example) assuming all conditional jumps succeed and continuing to feed the pipeline as though they were non-conditional jumps. The only additional hardware needed is whatever is necessary to "undo" the partial execution of mis-guessed instructions in the pipeline, if necessary.

          There's also all sorts of branch prediction stuff that many modern processors do, to try to out-guess the programmer/compiler's prediction of which code path is most likely - that can get quite complicated - but that's not an inherent part of speculative execution., and I suspect

          Intro level:

          Are you familiar with the concept of instruction pipelining? Basically a single instruction in a modern processor takes many CPU cycles to execute as a series of sub-tasks. Requesting needed values from memory, waiting for them to arrive, preparing registers, etc.

          If we say there's ten steps per instruction, and you executed only one instruction at a time from start to finish at a time, your computer would run at 1/10th the speed. It actually runs 10x faster because all modern desktop processors use pipelining to execute many instructions simultaneously: As Instruction 1 finishes step 1 and moves on to step 2, the hardware needed for step 1 is freed up, and can start executing step 1 for instruction 2. And so on and so forth. The reality is a fair bit more complicated, but that's the general idea.

          It's sort of like a buffet line where everyone wants a serving of ten different dishes - you could let one person at a time through the entire line to fill their plate before the next person could start, but it's far faster to let ten people through at a time so that each person can be taking a serving from a different dish before moving on and making room for the next person at the same dish.

          The problem comes with branching - any time the computer encounters a loop, or if statement, or any other sort of conditional branch, it's like your buffet line splits into two parallel lines waiting behind you - those who should eat if you're getting a brownie as the last dish, and those who should eat if you get ice cream instead. Without speculative execution the queues behind you stops moving as soon as you enter the buffet. They just stand there waiting until you get to the very last dessert station and it's decided which queue gets to eat.

          That's going to really slow down progress, especially if there's a lot of decisions like that to be made one right after the other, which actually happens a lot for software - e.g. if you want to know if two names are the same you ask are the first letters the same? If so, are the second? The third? There's only a couple instructions to compare one letter pair in the "buffet line" at a time, and progress slows to a crawl while the buffet stands mostly empty.

          Speculative execution just says "look, we've got infinite food, what's limiting us is our ability to get people through the buffet line...that's currently standing almost empty. So, just let one of the waiting lines get started, and if we pick the wrong one we just send them away and are no worse off.

          In its most basic non-predictive form there's no additional hardware needed - you might for example just assume all conditional jumps will succeed and let the corresponding instructions start working their way through the "buffet line". I'm not sure if it's still true, but in the early days of pipelining the rule of thumb was to write all your code so that all if statements,etc, were most likely to evaluate as true. The compiler would then arrange the binary code so that was the "default path", and speculative execution could use your foreknowledge to beat the odds when "guessing" which line to let through.

          • (Score: 0) by Anonymous Coward on Saturday May 01, @05:41PM

            by Anonymous Coward on Saturday May 01, @05:41PM (#1145163)

            Need a dipshit version. And use a car analogy next time to increase interest.

          • (Score: -1, Flamebait) by Anonymous Coward on Saturday May 01, @06:34PM (4 children)

            by Anonymous Coward on Saturday May 01, @06:34PM (#1145180)

            Don’t be a dipshit. Most people don’t need the performance gains for most workloads. Maybe we should go back to when an instruction was an instruction was an instruction. And you executed what the programmer wrote.

            Most computers general purpose cpus spend most of their cpu time either in and idle or low power state waiting for external events. Even phones are offloading work to special auxiliary processors as a cheaper way to improve performance, and lower battery drain.

            • (Score: 3, Insightful) by Immerman on Saturday May 01, @07:31PM (1 child)

              by Immerman (3985) on Saturday May 01, @07:31PM (#1145202)

              >Don’t be a dipshit. Most people don’t need the performance gains for most workloads. Maybe we should go back to when an instruction was an instruction was an instruction.

              From pipelining? They really do. We absolutely can go back, but it would mean your computer would take 10x as long to do anything. All those steps still need to be done regardless, pipelining just means the hardware for step 1 doesn't sit idle while you're doing steps 2 through 10. It became popular precisely because it granted truly huge performance gains.

              Predictive execution itself isn't such a big gain under many workloads - maybe things without a lot of conditional branching might only take maybe 30% longer. But comparison or lookup operation, or anything with tight inner loops (like image processing) would slow to a crawl without predictive execution. That includes pretty much any database operation, game-loading times, image manipulation, etc. *Everybody* uses branch prediction on a regular basis.

              • (Score: 0) by Anonymous Coward on Saturday May 01, @08:25PM

                by Anonymous Coward on Saturday May 01, @08:25PM (#1145216)

                Don't need speculative execution. In fact, even hinting of branch target (branch-likely, branch-notlikely conditionals) are falling out of favour in RISC architectures. Maybe having a 40 step pipeline is the problem. Looking at you, Intel. Oh, and bring back the much loved branch-delay slot! Then almost all branching has no stalls.

            • (Score: 3, Interesting) by shortscreen on Saturday May 01, @11:48PM (1 child)

              by shortscreen (2252) Subscriber Badge on Saturday May 01, @11:48PM (#1145241) Journal

              Are most people renting out VMs to untrusted third parties? Because if they aren't doing that, and are just plain ol' users of single-user devices, then malware can already do worse things for them than read some memory outside of its process space.

              I won't be holding my breath for a sudden wave of high-end CPUs on the second-hand market.

              • (Score: 0) by Anonymous Coward on Sunday May 02, @09:22AM

                by Anonymous Coward on Sunday May 02, @09:22AM (#1145341)

                People are using computers wrong.

      • (Score: 3, Informative) by KilroySmith on Saturday May 01, @03:43PM (5 children)

        by KilroySmith (2113) on Saturday May 01, @03:43PM (#1145134)

        >>> Speculative execution a bad idea
        Uhh, yeah, so let's all go back to the architecture of the Pentium MMX circa 1994, because that's the last generation that didn't do speculative execution.

        You do realize that a CPU without speculative execution is going to have significantly lower performance than one with? Like, perhaps, one quarter the performance?

        • (Score: 1, Informative) by Anonymous Coward on Saturday May 01, @05:58PM

          by Anonymous Coward on Saturday May 01, @05:58PM (#1145168)

          Depends on the workload, but yeah 1/4 performance is probably generous for a mainstream CPU. Even bottom end 8 bit RISC microcontrollers do prefetch and naive branch prediction because it nearly doubles their performance. Speculative execution is just the next logical step after that and anything with a cache needs it. I'd also like to point out that this, Spectre, and Meltdown are all cache timing attacks. The existing mitigation technique of forbidding precision timers should work here as well.

        • (Score: 0) by Anonymous Coward on Saturday May 01, @06:45PM (1 child)

          by Anonymous Coward on Saturday May 01, @06:45PM (#1145184)
          What does 1/4 performance really mean in today’s world? It means that today’s cpus and operating systems are shit when it comes to using their multiple cpus. Bloat extracts more of a penalty than the cpu can ever give back. If we were to insist on less bloat in operating systems, in programs, and especially in bullshit like bloated browsers, game runtimes and shit like Java we would be far ahead.

          Today’s cpus are an acknowledgment that today’s programmers don’t know jack shit. We need a new rule - for every line of code you add you have to remove 2. Maybe in 20 years we’d be in a saner situation.

          • (Score: 1, Touché) by Anonymous Coward on Saturday May 01, @09:15PM

            by Anonymous Coward on Saturday May 01, @09:15PM (#1145223)

            We need a new rule - for every line of code you add you have to remove 2. Maybe in 20 years we’d be in a saner situation.

            No, the only effect will be 800000-character lines.

        • (Score: 4, Interesting) by HiThere on Saturday May 01, @08:09PM

          by HiThere (866) on Saturday May 01, @08:09PM (#1145213) Journal

          Wrong approach. With no speculative execution, etc., you have much simpler processors, so you can fit more CPUs in the same chip area. This give you true isolation, and lets you still gain the same throughput if you're willing to pay for the inefficiency. Alternatively, you can run more processes at the same time, though each one is slower. This approach does have it's own costs, as spinning off separate processes and awaiting the results isn't free, but it's not comparable to just disabling the cache.

          --
          Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
        • (Score: 2) by driverless on Sunday May 02, @06:48AM

          by driverless (4770) on Sunday May 02, @06:48AM (#1145329)

          Two thoughts on this, firstly I think saying you'll get a quarter of the performance is optimistic, I'd expect maybe a tenth once you've eliminated all possible and potential sources of side channels, possibly even more.

          Secondly, saying "one tenth the performance" doesn't give an good indication of the level of impact this will have. Think of it as "instead of a $50M data centre, we'll need to spend half a billion dollars to get the same result". Assuming the infrastructure is available to support ten data centres when you had one planned.

          The other thing is that for 99% of all users these vulns are irrelevant. My laptop or phone aren't made any less secure by having speculative execution. Umpty bajillion embedded devices aren't made any less secure by having it, since they only run one thing anyway. The only thing that's really affected is DRM and similar consumer-hostile technology (long may the vulns continue!) and people renting time on someone else's CPU, for which you shouldn't expect any security anyway.

      • (Score: 2) by fakefuck39 on Saturday May 01, @06:30PM (2 children)

        by fakefuck39 (6620) on Saturday May 01, @06:30PM (#1145179)

        to make calculations fast, you use what's called a pipeline. you break up the large task into small parts, so faster to calculate each little part, then you put them into a queue. imagine you need to take apart a table - one big task. now give two guys a wrench and they each have to only take a part half the table - you get done faster.

        the key is to keep that pipeline full all the time. you have different types of workers - a few that handle memory access, a few that only count integers, a few that handle floating point math. so a guy w/ a phillips head, a guy with a flathead, and a guy with a wrench. you want all those working, all the time. if you run out of bolts, the guy has nothing to do while the other 2 work - you're now moving 1/3 slower.

        so you find a little dude to look for the right tasks for those 3 to do. very little extra work, very little extra silicone. his job is to make sure all are working in parallel all the time. problem is, he doesn't know the future, so he makes a guess. if you have two operations in order: 2+2 and 2.2*2.8, you know you run them at the same time. Except you're not sure if you need to know what 2+2 is, but you might. Your option is to Definitely have the integer math unit do nothing a few cycles (definite cpu slowdown due to not doing work), or give him work that you possibly won't need (possible cpu slowdown due to wasted work).

        Wasted work may or may not be a problem. Most computer use we don't care about a few extra watts, and prefer extra speed. Now, you may define "bad idea" by making energy waste the most important metric. Not only is that not important to most people, you'd be wrong. Let's say you want to view a webpage. Is it less energy to: waste a watt to get that page shown faster, or waste several few watts while you're sitting there extra time waiting for it to load, staring at a lit screen?

        You should watch different news.

        • (Score: 1, Insightful) by Anonymous Coward on Saturday May 01, @06:52PM (1 child)

          by Anonymous Coward on Saturday May 01, @06:52PM (#1145187)
          Why not get rid of most of the shit in a webpage, starting with JavaScript, and 3rd party resources like ads, instead. Fewer security holes and no waiting for pages to render because they’d be a lot simpler while containing as much content the user actually wants.

          Tackle the problem at the source. If Facebook and Google and Twitter are less profitable as a result, exactly how is that my problem?

    • (Score: 2, Informative) by fakefuck39 on Sunday May 02, @01:18AM

      by fakefuck39 (6620) on Sunday May 02, @01:18AM (#1145251)

      tl;dr: people keep looking up stories on hacker news and reposting them here. it's a new thing, roll with it.

      So, here's an idea - if you know what you're talking about, go to the actual discussion with others who know what they're talking about. This discussion here will be unqualified unsuccessful autistic old incels providing clown-insight into CPU design after reading a wiki article.

      https://news.ycombinator.com/item?id=27000570 [ycombinator.com]

  • (Score: 1, Funny) by Anonymous Coward on Saturday May 01, @01:49PM (1 child)

    by Anonymous Coward on Saturday May 01, @01:49PM (#1145109)

    What moron let TSA put code in our CPUs? We can only hope that the CIA's code doesn't go rogue too.

    • (Score: 2, Insightful) by Anonymous Coward on Saturday May 01, @06:56PM

      by Anonymous Coward on Saturday May 01, @06:56PM (#1145190)
      More to the point, what morons let JavaScript from all over the place onto our cpus? Oh right, “web designers”. Waste of skin and cpu.
(1)