back to article Boffins split on whether Spectre fix needs tweaked hardware

Processor security experts – including one cited in the Meltdown paper – are split on whether the resolution of the Spectre vulnerability may need to involve hardware modifications or the software defences being rolled out are adequate. The Meltdown vulnerability, which by contrast is already comprehensively defended against, …

  1. Chris Gray 1

    Non-timing side channels?

    The various processor facilities leave traces of data behind. But, are there side-channels that can access that data which do *not* depend on high-precision timers? I.e. if the use of a high-precision timer becomes privileged, is there still a way to retrieve the information by a non-privileged application? Assume that non-privileged applications cannot use pointer-fiddling, arbitrary casting, etc.

    1. Warm Braw Silver badge

      Re: Non-timing side channels?

      There are plenty of applications that need high-precision timers: media synchronisation, in-process threading, etc. Taking them away from applications isn't really an option - though if you did, you'd also have to "fuzz" the lower-resolution timers because otherwise an application can simply execute, say, increment instructions to pad out the longer period and use the resulting number to work out how long the rest of the operation took.

      The point of the processor is to run non-privileged, end-user applications. The operating system is just there to get multiple processes to play nicely together - it's not a repository for application code that processor bugs make unsafe to run.

      1. Anonymous Coward

        Re: Non-timing side channels?

        There are plenty of applications that need high-precision timers: media synchronisation, in-process threading, etc.

        They may need high precision timing, but perhaps not with a resolution of one clock cycle. And the register would not be removed, but just having access limited to it so that timing side channel attacks become harder.

    2. Anonymous Coward
      Anonymous Coward

      Re: Non-timing side channels?

      Preventing high precision timers in the userspace is the defacto spectre fix.

      Android never has them in userspace, so android devices aren't really affected anyway (although Google has belt and braces merged the kernel patches into pixel and nexus devices).

      iOS is mitigating by reducing timer accuracy in userspace

      Mozilla is reducing accuracy of timers in their JavaScript engine to mitigate JavaScript exploits on windows and Mac

    3. Michael Wojcik Silver badge

      Re: Non-timing side channels?

      Yes, there are side channels that aren't timing channels. Most of them are difficult to read purely from software, though; they're things like power consumption (very effective against many embedded systems) and EFI/RFI emissions. These side channels have been exploited in real-world, feasible PoCs, but at least they generally require some sort of physical proximity.

      Perhaps more importantly, timing side channels do not require high-precision timers. The successful PoC Javascript attack in the Spectre paper didn't use a high-precision timer; it used a WebWorker thread decrementing a counter in a shared array. There are many timer alternatives, even in Javascript; and remote (over the network) timing attacks have been successfully demonstrated.

      Also, a lower-resolution or jittery timer means you have to make more measurements to reach the same degree of confidence in the data. But when you're trying to extract something like a private key, password, or session token, getting the bits with, say, 80% certainty is still pretty good; it cuts your brute-force effort exponentially.

      Blocking access to high-precision timers is spot defense - it's just pruning off the low-hanging branches.

  2. Anonymous Coward
    Anonymous Coward


    Probably completely unrelated, but I notice that the newly announced Nokia 6 and Sony XA-2 phones use the Qualcomm 630. Which uses A53 cores which last time I looked were not on the vulnerability list.

    1. Anonymous Coward
      Anonymous Coward

      Re: ARM...

      A53 is in-order execution which makes it both not vulnerable and smaller/less expensive. The latter is why it would have been chosen for those phones; Nokia and Sony wouldn't have heard about the issues until fairly recently but even if they knew back in June when Intel did that's not enough time to be in the "selecting a CPU" stage of designing a phone that would be on the market in early 2018.

      1. Anonymous Coward
        Anonymous Coward

        Re: ARM...

        "A53 is in-order execution which makes it both not vulnerable and smaller/less expensive. "

        I know. I was merely drawing people's attention to the fact that there are Android 8 devices which don't have out of order execution. I'm sure you're right; but I would suspect that two of the smaller manufacturers could make a design decision within six months of launch, especially on parts not likely to have supply constraints, if they wanted to. It's not like Apple or Samsung with logistic chains most people would barely be able to comprehend.

  3. Mage Silver badge

    Perimeter Defence

    Block scripts: Use NoScript or uMatrix.

    Turn off stupid things on firewall, such as uPnP

    No remote content by default on email

    Not clicking on stupid attachments or links

    No autorun.

    Disable services you don't use.

    The dratted malware has to get ON the machine first. Side effect of above is that you likely won't get other zero days and might not even need AV, which is like a trigger happy SWAT team INSIDE the home/office/hotel. Check the guys at the doors, windows, ventilators, sewers and chimneys, stop shooting innocent stuff MEANT to be inside. User training.

    1. Destroy All Monsters Silver badge

      Re: Perimeter Defence

      Use QubesOS

      1. Tom Paine

        Re: Perimeter Defence

        Use OpenBSD.

        1. Anonymous Coward
          Anonymous Coward

          Re: Perimeter Defence

          OpenBSD (or HardenedBSD) on top of QubesOS, maybe.

          The idea is isolation!

    2. Tom Paine

      Re: Perimeter Defence

      Yes, we know. Put my shoes on and try explaining that to The Business.

  4. Tubz

    Chip manufacturers should be forced to recall and replace, just like other businesses, only way for them do the design work properly, hit them in the bank balance !

    1. Tom Paine

      Exercise for the poster: why is it that this is not being contemplated?

      1. theOtherJT

        I would imagine that one issue is that in a lot of cases the CPU in question is baked onto a board containing parts by huge numbers of different manufacturers, all of which work perfectly well, but would have to be replaced anyway. The cost of that starts to get kind of crazy and Intel may well argue that it's not THEIR fault that Gigabyte / Asus / Dell / HP / whoever soldered the processor to the motherboard, and that those manufacturers should bear part of the cost of any recall. In fear that that argument might actually hold water, those OEMs are reluctant to endorse a recall for the CPU because they don't want to end up with even part of the bill.

        The other issue is that literally every x86 chip made in the last 15 years is vulnerable, at least to spectre. There simply isn't the manufacturing capacity on the planet to replace that many chips.

  5. keithzg

    Not nostalgia, rather hope for the future

    You say "Haas laments that security in processor design was not baked in from the beginning – expressing nostalgia for the days of RISC processor development."

    But what he actually says is:

    "Generally speaking, I am a bit worried that security has been an afterthought with current designs. It might be top priority now but originally, security was more like nice-to-have. I dream (and made suggestions) of an architecture with security in its genes and thus closely follow the RISC-V development."

    He's clearly referring to the ongoing development of the BSD-licensed RISC-V architecture, rather than being nostalgic for older RISC CPU architectures.

  6. tim292stro

    Meltdown is not comprehensively protcted agaist.

    @El Reg "Meltdown = job done" is a BS thought right now. Even if Intel managed to develop a micro-code workaround to the design flaw, at boot this requires a BIOS flash to achieve. Good luck finding a vendor who is going to dust off the tempermental leased Intel development platforms to give that a try for every motherboard SKU they've released in the last 10 years... from my experience, Intel tells vendors to sod off after the first year of release, especially if there's no new money in it for them.

    Then there is the issue of Specter fixes, pushing the fix burden on software people is a fantastic way to get software people to hate your living guts. At the OS level the vendors are probably finding out right now that even they didn't fully understand all of the use-cases, and that's probably where we will get the drawn out reporting of major slow downs. It'll take a while for the individual application software vendors to touch their code again to optimize around the new kernel controls, so this story will linger for 5+ year IMHO.

    I'd wait the cast >final< judgement on the impact of the Meltdown/Specter bugs until the second fiscal quarter well after Jan 1 2018. By then you should be able to see Intel making stock charges to hold reserves for lawsuit settlements, machine performance contract breaches at the larger datacenters, and hits from the various computer manufacturers.

    1. Gene Cash Silver badge

      Re: Meltdown is not comprehensively protcted agaist.

      > this requires a BIOS flash to achieve

      Depends on the OS. If you've installed intel-microcode & iucode-tool on Debian, then the latest* microcode is installed at boot. They have amd64-microcode for the AMD crowd.

      * as of when you installed/updated the package. They come out with updates every 5-6 months in my experience.

    2. Deckard_C

      Re: Meltdown is not comprehensively protcted agaist.

      No protection against meltdown if you are running 32bit Windows.


      Q4: I have an x86 architecture, but I don’t see an update offered. Will I get one?

      A4: Addressing a hardware vulnerability through a software update presents significant challenges, and mitigations for older operating systems require extensive architectural changes. We are working with affected chip manufacturers to determine the best way to provide mitigations for x86 customers. These may be delivered in future updates.

  7. Lorribot

    Anyone know of any Itanium workstations, I could dual boot Windows server 2008 and OpenVMS for some safety by mainstream obscurity. Probably and old Linux distro out there for Itanium as well.

    1. Tom Paine

      At last - my GF!

      After decades of sarcasm and evil eyes, FINALLY a use for that MicroVAX under the stairs! \o/

      1. Anonymous Coward
        Anonymous Coward

        Re: At last - my GF!

        You can pull my DEC Alphas from my old, dead hands.

        1. Korev Silver badge

          Re: At last - my GF!

          If they try it then DEC them

  8. Pascal Monett Silver badge

    "plugging Spectre holes might become an ongoing process"

    Translation : we're all fucked for the duration. Microsoft is going to have years of faulty patch releases due to this, and everyone else is going to have to submit to regular panic attacks every now and then following just how well the media is going to do its follow-up on this subject.

    I really would like to think that retirement would get me out of the panic zone, but it seems that even a bear pit won't be enough now.

  9. This post has been deleted by its author

  10. FlamingDeath Silver badge

    Is this another case of the unintelligence and insecurity services leaning on a company to insert back doors into its products, I'm sure intel would be only too happy to assist for a small fee.

    IT security is broken, and will remain broken forever.

    Build me an indestructable bridge, do that, and proove me wrong

    1. Charles 9 Silver badge

      It's not G-men but rather accountants who are to blame here. If the money isn't in security, then it simply won't be there. The shareholders will insist on this.

      You want an indestructible bridge? Tell us how you can beat physics and make a bridge capable of withstanding a meteor strike on a shoestring budget.

  11. Anonymous Coward
    Anonymous Coward

    Interesting fix

    I may have found out how to patch SPECTRE/Meltdown even on non patchable systems.

    Seems that most of the problems are that the patch slows down chips too much, it can in fact be patched even on the Note 4/etc by periodically flushing unused areas of the chip with zeros or a PRNG based test pattern such as dummy data from the back camera in dark (ie case) mode.

    A bit like a TRIM command on SSD, same basic principle applies.

    1. Tom Chiverton 1

      Re: Interesting fix

      And their goes energy efficiency and throughput.

    2. Anonymous Coward
      Anonymous Coward

      Re: Interesting fix

      So your going to fix this by dumping cache periodically? Disabling cache altogether would mitigate cache timing attacks but that cache is there for a reason. This solution would potentially reduce every cache hit to the speed of memory access by ensuring cache is flushed is not the solution you are looking for.

    3. Michael Wojcik Silver badge

      Re: Interesting fix

      it can in fact be patched even on the Note 4/etc by periodically flushing unused areas of the chip

      I'm curious what you mean by "periodically" here. Note there are potential Spectre1 vulnerabilities between hyperthreads running on the same core, and within even a single process. So, are you going to "flush" on every context switch?

      And what are "unused areas"?

      with zeros or a PRNG based test pattern such as dummy data from the back camera in dark (ie case) mode

      A completely unnecessary complication.

      Look, it's nice that people are thinking about these things, but why are you referring to this as an "interesting fix" and prefacing it with "I may have found out how to patch"? There are plenty of people who understand CPU ISAs and microarchitectures who are looking closely at the family of spec-ex + side-channel vulnerabilities. I have no problem with people who don't understand those things making wild-ass guesses, but presenting them as possible fixes (and then getting upvoted, presumably by other people who don't understand them) just muddies the waters. Why not ask whether something is a feasible fix?

      1It's not an acronym. Please don't write in block capitals.

  12. Calin Brabandt

    Recall impossible?

    I don't know if a recall is impossible, but I know that many automobiles that functioned exactly as designed have been recalled on many occasions for lessor engineering blunders or oversights!

    1. Charles 9 Silver badge

      Re: Recall impossible?

      Lesser in what way? Faults in cars can get people KILLED.

  13. TWB

    Reboot of the PC market?

    Maybe this will 'force everyone' to upgrade to new machines saving the PC manufacturing sector - when new processors get released! It's a win-win!

    Cynical - moi?....

    1. Anonymous Coward
      Anonymous Coward

      Re: Reboot of the PC market?

      Well, it's certainly put off my replacing my Windows laptop for quite a while.

  14. eldakka Silver badge

    Would a separate privileged TLB help?

    From most of what I've read (on tech sites like The Register, not the actual exploit papers and so on), most of the attacks seem to be caused by the TLB having unprivileged and unprivileged memory references simultaneously in the TLB. Although meltdown makes this worse on effected processors by not enforcing security on speculative execution.

    What about splitting the TLB in future processors? Making a smaller (since it only needs the kernel memory references in it, not user processes as well) TLB that can only hold references for - and be accessed by - ring 0 threads? That way, any extra security that needs to be introduced around kernel memory (fiddling with timing for example) can be applied to access from the protected TLB.

    1. Michael Wojcik Silver badge

      Re: Would a separate privileged TLB help?

      most of the attacks seem to be caused by the TLB having unprivileged and unprivileged memory references simultaneously in the TLB

      That only applies to Meltdown, not to Spectre. There are plenty of security boundaries between different pieces of unprivileged (usermode) code. In the Spectre paper, they specifically show a Javascript exploit in a browser (so a malicious script could harvest session cookies and other sensitive data from other pages). Other obvious examples are shared systems where a malicious user steals data from other users, or from programs that deal with sensitive data such as PII, payment information, etc.

      What about splitting the TLB in future processors?

      That's basically what the Linux KPTI patches emulate, and the Intel PCID feature provides some hardware support to make TLB partitioning easier. So yeah, this is a mitigation strategy for Meltdown.

  15. Cuddles Silver badge

    Not much of a dispute

    "Meltdown is easy to exploit but relatively easy to patch. Spectre is tougher in both respects. Daniel Genkin, a postdoctoral researcher at the University of Pennsylvania and the University of Maryland, previously told El Reg that a lasting fix against Spectre would require a hardware redesign.

    Fogh disputed this during a phone interview with El Reg, adding that mitigations already in place are increasing the difficulty of mounting an attack."

    I must be missing the part where Fogh actually disputed anything. In saying that mitigations only increase the difficulty of an attack, he implicitly agrees that a hardware redesign is the only way to actually fix the problem entirely. That a recall of nearly all chips made in the last 15 years may be impractical doesn't mean new hardware isn't necessary, it just means it will be a slow, painful process before everything vulnerable has actually been fixed, since in most cases "fixed" is synonymous with "replaced".

  16. Naselus

    "AMD's reaction has been a complete disappointment."

    Intel's reaction was for the CEO to dump as much of his stock as contractually permitted prior to the bug becoming public, and this guy says AMD's reaction is disappointing because they implied his team had inside knowledge?

    1. whaas

      Re: "AMD's reaction has been a complete disappointment."

      No, this guy is disappointed by AMD's initial reaction because it provided very little information. It basically came down to 1=resolved by updates, 2=near-0 risk of exploitation, 3=zero vulnerability. So #1 is basically a SW bug (apparently, no HW-changes are required), #2 is very comforting (I guess Tepco in Japan said the same thing about their nuclear reactors), and with #3 they could have provided some hint as to why we should trust them.

      I see the allegation of insider knowledge as an attempt to distract from the problem: the focus should be on the guys responsible for the flawed design, not the messenger who reported it.

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

Other stories you might like

Biting the hand that feeds IT © 1998–2022