back to article Meltdown/Spectre week three: World still knee-deep in something nasty

It is now almost three weeks since The Register revealed the chip design flaws that Google later confirmed and the world still awaits certainty about what it will take to get over the silicon slip-ups. The short version: on balance, some steps forward have been taken but last week didn't offer many useful advances. In the " …

  1. Anonymous Coward
    Anonymous Coward

    Had to disable Spectre mitigation

    Since patching my Office HP ProDesk PC with MS and BIOS updates, it was constantly logging this event:

    Event 19 Source WHEA-Logger

    A corrected hardware error has occurred.

    Reported by component: Processor Core

    Error Source: Corrected Machine Check

    Error Type: Internal parity error

    It has also had 6 BSODs with 4 different STOP codes since applying the updates. It doesn't even have the decency to fall over with the same error.

    Disabling the Spectre mitigation has stopped the WHEA events (hopefully the STOPs as well, time will tell), by setting the following DWORD to 1:

    HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management

    REG_DWORD FeatureSettingsOverride = 1

    So it seems we have to choose between stability and security, although this at least leaves the Meltdown mitigation in place. Hopefully Intel can push out a less crap microcode update at some point in the near future.

  2. J J Carter Silver badge

    Re: Had to disable Spectre mitigation

    Also need to set FeatureSettingsOverrideMask, both DWORDS should be 3 if my reading of documentation is correct

  3. Anonymous Coward
    Anonymous Coward

    Re: Had to disable Spectre mitigation

    The mask has to be 3 as it specifies which bits in the DWORD are relevant.

    If you set FeatureSettingsOverride to 3 it disables both Meltdown and Spectre mitigations. If you set it to 1 it only disables Spectre mitigation.

  4. Jonathan 27

    Re: Had to disable Spectre mitigation

    I've updated two systems with the full set of microcode and Windows patches, a Dell XPS 9550 and a desktop with a Gigabyte Z170-Gaming 7 and niether has experienced any blue screens. It's a pretty small sample however, and both systems have derivatives of the same CPU design i7-6700k and i7-6700HQ (sky lake 4 core). Those are my personal machines, we're leaving the business ones a while to see.

  5. Anonymous Coward
    Facepalm

    Re: Had to disable Spectre mitigation

    Typing

    $ grep . /sys/devices/system/cpu/vulnerabilities/*

    into a Linux terminal window now reveals whether you've ever used anything Unix-y before, or whether you just copy shit from stackoverflow and hope no-one notices. But we noticed. What's wrong with cat?

  6. Michael Wojcik Silver badge

    Re: Had to disable Spectre mitigation

    What's wrong with cat?

    That grep command line isn't quite the same as cat - it will only display non-empty lines, because "." requires at least one character on the line (and grep doesn't consider the terminating LF a character).

    So if the input contains a lot of blank lines, grep is probably more useful than cat.

    But yeah. Oldtimers may remember the Useless Use of Cat (UUOC) award that was frequently handed out on comp.os.unix; this is probably a case of No, This Time You Should Have Used Cat.

  7. streaky Silver badge

    Google and Intel;

    Mishandled all this right from the start. Google will get away with it because they don't make CPUs.. Intel, not so much.

    Some things should stay buried, at least until there are proper hardware fixes and Intel (or anybody else) shouldn't be selling CPUs still at this point that are still vulnerable, not least because there's nothing to sue for a replacement for, which I'm sure Intel knows. Long term it's going to hurt them though.

  8. Michael Habel Silver badge

    Re: Google and Intel;

    Perhaps we'll finally see ARM on the Desktop running some Linux variant? Otherwise I think Intel having a damned near monopoly in the CPU market will be enough to see them through.

    Yeah there is AMD... Perhaps if they can beat Intel to the punch they could get good again. But I fear the days of 3DNow are over for them.

  9. big_D Silver badge

    Re: Google and Intel;

    ARM is also affected, to a lesser degree, like AMD. Nobody comes out of this smelling like roses.

  10. DougS Silver badge

    Intel "shouldn't be selling CPUs?"

    Even if it can be fixed via software? Or would a fix that reduced performance by even 0.01% be unacceptable to you?

    Do you understand how long the design cycle is for making the type of architectural changes that would be required to fix this in hardware? Intel would have stopped selling CPUs in June (without explanation) and not start selling them again until the end of this year at the very earliest.

    What's the world supposed to do for CPUs in the meantime? Even if AMD's CPUs were 100% bug free, for many workloads they are slower than Intel CPUs with the fixes applied. So that's not exactly a good solution. But the bigger problem is that they can't possibly make enough to supply the market, and PC sellers can't just slot in an AMD CPU to their existing models. It would take 6-9 months for them to redesign them to accommodate AMD CPUs on an AMD motherboard with AMD drivers - though realistically we all know Intel would be telling them "we will have new CPUs for you before you can get those AMD machines out, so don't even bother trying" and by the time the PC OEMs figured out Intel was lying they'd have the new CPUs almost ready.

    Your suggestion would quite likely cause enough of a hit to the world economy to be noticeable in the GDPs of the US, EU, and China. Meltdown / Spectre are bad, but far from end of the world bad.

  11. big_D Silver badge

    Re: Intel "shouldn't be selling CPUs?"

    And it isn't just Intel.

    AMD, ARM, Apple, IBM, Oracle are all affected by Spectre, so there wouldn't be any chips for pretty much all mainstream hardware.

  12. ST Silver badge
    FAIL

    Re: Intel "shouldn't be selling CPUs?"

    > Even if it can be fixed via software?

    Spectre can't be mitigated in software, Genius.

    It could conceivably be mitigated in the compiler, but that would lead to an unacceptable performance penalty. I.e. flush the L1 I-cache on each and every single branch target. Or re-write each and every single branch target to emit an instruction that can't be executed speculatively.

    And I'm not even 100% certain that either of these would mitigate for the case of an unconditional branch such as call foo@plt.

    Either way, the performance penalty is very high, and it requires a full recompilation of all the software, because the cure is in the compiler's codegen. Not something that can be cured with a software patch.

  13. big_D Silver badge

    Re: Intel "shouldn't be selling CPUs?"

    I though Retproline (Return Trampoline) was the compiler mitigation and is built in as a flag on the current gcc version and causes a negligible performance hit.

  14. jmch Silver badge

    Re: Intel "shouldn't be selling CPUs?"

    "Even if it can be fixed via software? Or would a fix that reduced performance by even 0.01% be unacceptable to you?"

    It CAN'T be fixed by software. It can be (partly or mostly) mitigated. If it could be fixed with a 0.01% performance loss no-one would be kicking up the stink that they are, but reality is that it can be mitigated with a perforance hit of anywhere between 5-20% judging by reports I've seen.

    Can you imagine if you paid north of 30 grand for a car with 200 bhp, and the manufacturer says hey, the brakes might fail at any given moment, very unlikely to happen guv, but here's a fix and by the way, your car now has 160bhp not 200.

  15. jmch Silver badge

    Re: Intel "shouldn't be selling CPUs?"

    "What's the world supposed to do for CPUs in the meantime?"

    At least customers can have some informed consent on the chips they have been buying in last 6 months that Intel KNEW were borked (and possibly they knew of the flaw even before 6 months ago). I'd expect at least a discount / partial refund on any chips bought in the last 6 months. And given that Intel had 6 months to work on a software mitigation patch, isn't the least to be expected that it was properly tested? Maybe the Register jumped the gun by a couple of days, but the disclosure was due anyway, Intel should have thrown as much resources as it took to fix this on time.

    "Even if AMD's CPUs were 100% bug free, for many workloads they are slower than Intel CPUs with the fixes applied"

    I'm not an expert on chip performance is this confirmed anywhere? Anyone?

  16. Doctor Syntax Silver badge

    Re: Google and Intel;

    "Intel (or anybody else) shouldn't be selling CPUs still at this point that are still vulnerable"

    So what are they going to sell instead? What system level products are ready to take it? And who's going to roll out software recompiled for this mythical product?

    The reality is that users still need to get kit installed and can't wait several years for redesigned products to become available.

  17. Teiwaz Silver badge

    Re: Intel "shouldn't be selling CPUs?"

    What's the world supposed to do for CPUs in the meantime?

    Cue : Penny Farthing Logo.

    Maybe it's a good opportunity to slow down and take stock of where the world is headed rather than continue the knees bent, running about advancing behaviour blindly, up up the ziggurat lickity split...

    No takers? thought not.

  18. Brewster's Angle Grinder Silver badge
    Joke

    Re: Intel "shouldn't be selling CPUs?"

    >>Even if AMD's CPUs were 100% bug free, for many workloads they are slower than Intel CPUs with the fixes applied

    >I'm not an expert on chip performance is this confirmed anywhere? Anyone?

    Yup, it's been confirmed. By Intel's marketing department.

  19. Bronek Kozicki Silver badge

    Re: Intel "shouldn't be selling CPUs?"

    AMD is known to be not affected by Meltdown bug, which was also the most expensive (in terms of performance penalty) one to fix. This means that, suddenly, all the performance benchmarks comparing Intel (with crappy buggy speculative execution which allows user code crossing kernel boundary) against AMD ones (which would not allow such violation in its own, slightly less buggy, implementation of speculative execution) are no longer valid.

  20. Wade Burchette

    Re: Intel "shouldn't be selling CPUs?"

    Um ... Have you seen the benchmarks for Ryzen and Eypc? The only area where Intel has a clear advantage anymore is gaming, on everything else Ryzen goes toe-to-toe with Core i-whatever. And in servers, Eypc is actually was better dollar-for-dollar than anything Intel has to offer before these patches. You can buy 32 core Eypc processors for much much less than a 24 core Xeon. AMD is competitive again. The issue is perception and Intel's marketing. Intel helps fund commercials for companies which promote their product. This is a standard practice, because I have a friend in the HVAC business who has ads paid for by Carrier corporation for his business because he sells a lot of their units. AMD doesn't have the cash to overcome perception and marketing just yet.

    Another thing, it takes about 2 years from design to production for each new CPU. Assuming Intel learned about this in July of 2017 and started right away fixing it, that would put them at July 2019 before they have a fixed CPU. And that is pretending they also knew about Spectre at the time too. Pretending AMD learned about Spectre recently, that would put them in January 2020 before they have a patched CPU too.

    Intel does lie. What they have been telling people is that AMD is affected too, they have just not told them that AMD is not affected as much as Intel is.

  21. LeeE Silver badge

    Re: Google and Intel;

    "Some things should stay buried, at least until there are proper hardware fixes and Intel (or anybody else) shouldn't be selling CPUs still at this point that are still vulnerable..."

    That's an oxymoron because you can't do both; as soon as Intel (or anybody else) stopped selling vulnerable CPUs (which in this case would mean all CPUs) it would tell you that not only has something been buried but also where it has been buried.

  22. analyzer

    Re: Intel "shouldn't be selling CPUs?"

    Well that's a little more complex than the simple faster then.

    It kind of goes like this, Intel CPUs are 'on average' 30% faster than AMD Zen CPUs <--- the point where idiots stop reading <--- for single threaded workloads but there are workloads where AMD is faster. For multi threaded loads, AMD Zen CPUs are on average 13% faster than Intel but there are workloads where Intel are faster. So CPU choice is pretty much irrelevant except for outliers where one will seriously trounce the other.

    The curious thing regarding servers that I never see mentioned is the actual data throughput of the system containing the CPU. As the Intel Xeon sports 44 PCIe lanes vs the 128 lanes that the AMD Epyc provides and, typically, 6 PCIe lanes are dedicated to board specific functions, that leaves Intel with only 38 to play with vs AMDs 122. This would imply that the actual throughput of an Epyc based system could be far higher than a Xeon one.

  23. ST Silver badge
    Terminator

    Re: Intel "shouldn't be selling CPUs?"

    > causes a negligible performance hit.

    s/negligible//g

    Try it on your own and see how "negligible" it is. As in not negligible at all.

  24. big_D Silver badge

    Re: Intel "shouldn't be selling CPUs?"

    As analyzer says, it depends on what you are doing and whether you are an outlier usecase. In my case, I wasn't interested in single threaded performance, but performance for multiple virtual machines for testing on a desktop... Ryzen 7 was a no-brainer, 8 cores and 16 threads for around the price of a quad core Intel processor.

    This is the first rig I've had that doesn't slow down when running multiple VMs.

  25. ST Silver badge
    Terminator

    Re: Intel "shouldn't be selling CPUs?"

    Intel (with crappy buggy speculative execution which allows user code crossing kernel boundary)

    No. You got this 100% wrong. This is not what Spectre does. You are confusing Spectre with Meltdown.

    And it's not just Intel that has crappy buggy speculative execution.

    Every single chip that has speculative execution - which means all general-purpose chips designed and fabricated in the past 20+ years, with the exception of Itanium - is affected by Spectre.

    And no, it's not a matter of buggy or crappy. It was a design oversight, or short-sightedness if you will, at the time, combined with the notion that nobody is smart enough to figure this out, and with pressure from benchmarketing types.

    The Spectre vulnerability was being whispered around in interested circles much earlier than June 2017.

  26. Martin an gof Silver badge

    Re: Intel "shouldn't be selling CPUs?"

    AMD is competitive again

    It seems to me that AMD has been highly competitive in the low- and mid-range market for quite some time. While the per-thread performance of the A-series chips doesn't quite match that of low-end Intel chips, the package as a whole (i.e. when you include graphics, motherboards) for self-builders has worked out cheaper and better, which is why I have been building AMD-based machines for some years now. If the impact of Meltdown and Spectre mitigations really is lower on AMD than Intel, even the per-thread gap will be reduced.

    There is also less software which is purely single-threaded, meaning that it makes even more sense to go for AMD where you can get more cores for the same money.

    I've not been in the extreme high-performance end of the market, but it looks as if Ryzen is a very serious contender if ever I decide to build a gaming rig, or if I want to speed up Kdenlive (MELT) video rendering - this is CPU-bound and doesn't use the graphics card.

    M.

  27. ST Silver badge
    Terminator

    Re: Intel "shouldn't be selling CPUs?"

    > I wasn't interested in single threaded performance, but performance for multiple virtual machines for testing on a desktop

    Spectre has nothing to do with single-threaded vs. multi-threaded or running multiple VM's or anything like that.

    The Spectre vulnerability is very simple: in the context of a branch mispredict speculative execution, the instructions aren't retired.

    Mispredicted branches happen all the time, regardless of the number of threads, or whether you're running a VM or a relational database. What the software does is 100% irrelevant.

    If you disable speculative execution competely, the performance hit is staggering: it's in the 30% ballpark.

    Branches - conditional or unconditional - exist in every single type of software.

    Without branches you can't have if/else statements, for/while loops, return from a function or a function calling another function.

    OK, that's an over-simpification. You can have conditionals without branches, but that's a very complicated and inefficient way of doing conditional branches. You still end up in the same sore spot: huge performance hit.

  28. Random Handle

    Re: Intel "shouldn't be selling CPUs?"

    >Maybe it's a good opportunity to slow down and take stock

    First thing the CEO did.

  29. Anonymous Coward
    Anonymous Coward

    Re: Intel "shouldn't be selling CPUs?"

    "I though Retproline (Return Trampoline) was the compiler mitigation and is built in as a flag on the current gcc version and causes a negligible performance hit."

    Retpoline only helps with Spectre Variant 2, not Variant 1.

  30. FIA

    Re: Intel "shouldn't be selling CPUs?"

    Spectre can't be mitigated in software, Genius.

    [Snip software mitigation]

    And I'm not even 100% certain that either of these would mitigate for the case of an unconditional branch such as call foo@plt.

    And you'd be speculating what on an unconditional branch exactly?

  31. CrazyOldCatMan Silver badge

    Re: Intel "shouldn't be selling CPUs?"

    Even if it can be fixed via software?

    It can't. At best it can be mitigated, not fixed. Now I'm not suggesting that Intel stops producing processors, more that they be a lot more open about the effects of the bugs and their plans to fix it.

    The same holds (to a lesser extent) for the other processor manufacturers and OS vendors.

    And best of all, stop producing patches that make machines unstable or non-bootable.

  32. big_D Silver badge

    @ST Re: Intel "shouldn't be selling CPUs?"

    I think you are missing the context here.

    The discussion between analyzer and myself was whether Ryzen made AMD competitive again against Intel (before Meltdown and Spectre). That, before M/S Ryzen one on some edge cases, compared to Intel and vice versa.

    What you say is correct, but it has no bearing on the sub-conversation you refer to.

  33. big_D Silver badge

    @Randome Handle Re: Intel "shouldn't be selling CPUs?"

    >Maybe it's a good opportunity to slow down and take sell stock

    First thing the CEO did.

    There, FTFY.

  34. FIA

    Re: Intel "shouldn't be selling CPUs?"

    [...] benchmarks comparing Intel (with crappy buggy speculative execution which allows user code crossing kernel boundary) against AMD ones (which would not allow such violation in its own, slightly less buggy, implementation of speculative execution)

    Lets be fair here, neither chip has buggy speculative execution. This isn't a bug, the chips work as expected; it's a side channel attack, the processor leaks information that after A LOT of trial an error can be used to figure out what's in certain memory locations. It's just that trial and error on a CPU can be quite quick... and the internet allows it to be done remotely, often without the users knowledge.

    I know it's only a small point, but a lot of the press, especially the less technical press are making it out like this is a huge bug that should've been noticed, rather than a perfect storm of unintended side effects that's taken 20 years to figure out.

    It's like how posting your holiday photos whilst on holiday make your house more attractive to thieves. It's not your intention, or a 'bug' in Facebook, it's just an unintended consequence.

    The reality is, the more complex systems become the more things like this will appear.

  35. ST Silver badge
    FAIL

    Re: Intel "shouldn't be selling CPUs?"

    > And you'd be speculating what on an unconditional branch exactly?

    Do you even understand speculative execution, or are you just doing clueless blabbing on the Internet because you have a keyboard?

    I'm betting on clueless blabbing. Go back to writing Excel macros.

  36. Anonymous Coward
    Anonymous Coward

    @ST Re: Intel "shouldn't be selling CPUs?"

    Spectre has nothing to do with single-threaded vs. multi-threaded or running multiple VM's or anything like that.

    (S)he didn't suggest that it did, the comment was in response to allegations that AMD was always slower than intel, and the poster pointed out that for the use case in question, running multiple VMs, AMD gave better performance.

    Slow down & read the comment fully before jumping in with a response.

    Mispredicted branches happen all the time,

    They do indeed, the big question for Spectre is whether you can train the branch predictor such that you can be fairly sure which way it will jump. If you can, you have a Spectre exploit. The compiler & code mitigations involve making it too difficult to usefully train the predictor, not in suppressing the predictions. That's why the performance hit may be tolerable.

  37. Anonymous Coward
    Anonymous Coward

    Re: Intel "shouldn't be selling CPUs?"

    Do you even understand speculative execution,

    Better that you do, or perhaps you just have a problem with English? If a branch is unconditional (as you wrote) there is no speculation involved, since there's only one option the branch can take.

    I'm betting on clueless blabbing. Go back to writing Excel macros.

    Maybe you should get some sleep, or go back to a forum where your arrogant know-all attitide is likely to be better tolerated.

  38. ST Silver badge
    FAIL

    Re: Intel "shouldn't be selling CPUs?"

    > If a branch is unconditional (as you wrote) there is no speculation involved

    Wrong. There is. See ret.

    > [ ... ] go back to a forum where your arrogant know-all attitide is likely to be better tolerated.

    Spare me the pontificating.

  39. Anonymous Coward
    Anonymous Coward

    Re: Intel "shouldn't be selling CPUs?"

    Wrong. There is. See ret.

    Not an unconditional branch, since the destination isn't 100% known.

  40. JeffyPoooh Silver badge
    Pint

    Re: Intel "shouldn't be selling CPUs?"

    ST suggested, "It could conceivably be mitigated in the compiler..."

    What if the bad guy uses the old (unmitigated) compiler, or even (gasp!) In-line Assembler ?

    I'm not sure that the basic concept of securing the world's CPUs in "the" (?) complier makes much sense.

  41. ST Silver badge

    Re: @ST Intel "shouldn't be selling CPUs?"

    > The compiler & code mitigations involve making it too difficult to usefully train the predictor, not in suppressing the predictions.

    One of the proposed compiler-based mitigations for Spectre involves inserting an otherwise useless loop containing pause instructions (on Intel) for each and every single branch target. This will suppress speculative execution, because pause cannot be executed speculatively.

    Not all ISA's have pause, so what applies to Intel won't apply to other ISA's.

    So, my question is: what is the difference - in practical terms - between making it too difficult to usefully train the predictor and suppressing the predictions?

  42. ST Silver badge
    FAIL

    Re: Intel "shouldn't be selling CPUs?"

    > Not an unconditional branch, since the destination isn't 100% known.

    Wrong again. The return register is always known. And if you're dealing with a large struct, where one or more struct elements would be returned outside the return register, these registers are also always known.

  43. ST Silver badge

    Re: Intel "shouldn't be selling CPUs?"

    > What if the bad guy uses the old (unmitigated) compiler, or even (gasp!) In-line Assembler?

    That's exactly what makes Spectre so toxic. It doesn't even require any kind of special (i.e. root) privileges to work.

    Imagine some innocent-looking program that runs as a "regular" user, and exploits Spectre. It won't leave any trace at all.

  44. Bronek Kozicki Silver badge

    Re: Intel "shouldn't be selling CPUs?"

    @ST you are right and I am right - I was referring to Meltdown (not to Specre) so we agree on this. The speculative execution on its own can also cause Spectre "class" of bugs which are cheaper (performance wise) to work around, as compared to Meltdown one. The numbers I keep seeing on lwn.net for Specre are consistently under 5% (usually around 1%), but numbers for Meltdown easily exceed 10% if your system is doing little more IO or other kernel-related activities. This is why I believe that AMD (not being affected by Meltdown) have now huge performance win against Intel, which is not reflected by old benchmarks, at all. On related note - I wonder if GPU intensive application (i.e. games) need context switch to communicate with the GPU. If so, then gaming benchmarks are going to be affected a lot, too.

    You are also right on explaining that speculative execution issue is not just "implementation", it is more of a design issue. Just let me have that simplification, ok?

  45. Chronos Silver badge
    Thumb Up

    Re: Intel "shouldn't be selling CPUs?"

    Maybe it's a good opportunity to slow down and take stock of where the world is headed rather than continue the knees bent, running about advancing behaviour blindly, up up the ziggurat lickity split...

    I could only give this one upvote when it deserves three: One for the philosophy, and one each for the Python and Dwarf references.

    The fact that this came about in the blind pursuit of speed über alles makes the performance hit all the more ironic. Had this been any other sector but the whale-song-fuelled tech industry where "we do because we can," where all ideas are delivered in a Californian accent complete with uptalk and riddled with buzzwords we'd be seeing a massive land-shark mobilisation by now. Hell, even governments would be salivating at the punitive fines they could levy for the amount of customer-fuckery this has generated.

    We do need to take a step back, not only to examine the efficacy of harder, better, faster, stronger but also what the current plethora of technical advances such as automation and convenience is doing to humanity's ability to survive. We're already only a few megawatts away from looting and anarchy. Do we push on and make that looting, anarchy and extinction?

  46. ST Silver badge

    Re: Intel "shouldn't be selling CPUs?"

    Just let me have that simplification, ok?

    I think we're both saying the same exact thing, just using different words.

  47. GreenReaper
    Mushroom

    Re: Intel "shouldn't be selling CPUs?"

    It's really not a bad time, as the market is pushing its all-time highs. Intel's probably not the only stock that'll be melting down in 2018.

  48. JohnFen Silver badge

    Re: Intel "shouldn't be selling CPUs?"

    "And no, it's not a matter of buggy or crappy. It was a design oversight"

    It was indeed a design oversight, and a subtle enough one that it's hard to blame the engineers for it. However, it's still a bug -- and therefore the implementation is buggy.

  49. JohnFen Silver badge

    Re: Intel "shouldn't be selling CPUs?"

    "This isn't a bug, the chips work as expected"

    I suppose that depends on how you define "bug". By my definition, this is definitely a bug (unless being vulnerable to a side-channel attack was intended) -- a bug in design rather than execution, but a bug nonetheless.

    "a lot of the press, especially the less technical press are making it out like this is a huge bug that should've been noticed"

    I agree that this is a mischaracterization by the press. This was a very subtle thing, and it's hard to fault engineers for not noticing it.

  50. Anonymous Coward
    Anonymous Coward

    Re: Intel "shouldn't be selling CPUs?"

    ST suggested, "It could conceivably be mitigated in the compiler..."

    What if the bad guy uses the old (unmitigated) compiler, or even (gasp!) In-line Assembler ?

    It's not the bad guy's code you worry about. He wrote it, so he has no need for tricks to see what it is doing. It's the code under attack that needs protection.

    The problem with one of the Spectre variants is that the bad guy can write code which trains the branch predictor in certain circumstances (for certain addresses), then when the code under attack reaches a relevant branch he can use that trained prediction to leak information he shouldn't be able to get at.

    The compiler changes are to modify the attacked code, not the attacker's code, so that it can't be influenced by the attacker. Blocking all prediction would work, but have an extreme performance hit, so the combination of new microcode & compiler changes is supposed to allow critical code to be protected while minimizing the hit. Far from simple, and a PITA if every kernel & VM needs to be recompiled with the new compiler.

    The fix doesn't need to be perfect, though. Just as crypto doesn't need to be unbreakable, just too hard to break in a reasonable time, the Spectre mitigation just needs to make the attack too slow to be useful. If the attack on mitigated code creates a side channel that can only leak, say, 1 bit every 5 minutes, it will likely take too long to get anything useful before the next restart, reboot or other significant change.

Page:

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2018