back to article We need to go deeper: Meltdown and Spectre flaws will force security further down the stack

Around 2003, a computer security portent that had been cheerlessly simmering away for years suddenly came to the boil. This was an era stricken by malware attacks on a scale few had prepared for, running software beset with flaws some vendors seemed disinclined to acknowledge let alone fix. Vulnerabilities, including high- …

  1. Anonymous Coward

    "we will see more technologies that sit between the hardware and the software."

    Which would only serve to create another attack-vector wouldn't it ?

    With governments wanting backdoors to people's encrypted devices and security agencies hoarding vulnerabilities, how can you expect security when there are a whole bunch of people actively working against you ?

    1. Doctor Syntax Silver badge

      Re: "we will see more technologies that sit between the hardware and the software."

      "security agencies hoarding vulnerabilities"

      But not hoarding them well enough to keep them out of the hands of the malware authors.

  2. lsces

    Which Hardware?

    "at some point you need to upgrade your hardware"

    Do we know just what hardware is affected as yet? I run AMD processors and it's not particularly clear if these need the 'slow down in processing' that some Intel powered machines are now encumbered with.

    1. admiraljkb

      Re: Which Hardware?

      @lsces -

      the 10-30% slowdown is related to the fix for the "Meltdown" variant, which is Intel only, and the worst of it (ala when you lose ~30% performance) is related to storage IO. The Spectre fix slowdowns so far aren't significant.

  3. nagyeger

    Oh joy. Added complexity...

    My wife half-expects that at some point the sum total of IT/networking/power distribution will become so complex and (for want of another term) balkanised into specialisms, that it essentially becomes impossible for humanity as a whole to maintain it, and then something will break and we'll be back to heating with wood and communicating with pen an ink (or maybe IT jobs will become more critical to society than doctors/nurses and we'll all die from treatable diseases??).

    When you add in obsolescence, shortening product-lifecycles and lost/outdated skill-sets (is anyone anywhere employed as a thermionic valve designer any more? How many people can read amd64 assembler compared to the numbers who could write 6502 or Z80 30 years ago?) then I tend to agree with her.

    1. Anonymous Coward

      Re: Oh joy. Added complexity...

      We would be close to that... look at Apple. Certain specs/builds have unreplaceable keyboards that fail after 8 months, GPUs after 12 etc.

      It would take 1 model/life cycle of their tech to have a fatal flaw and 100% of their products are gone overnight. Lol.

      But thankfully we do have alternatives. Like those laptops that cost £/$1700 less, and last 3 to 4 times longer. ;)

  4. beardman

    Intel x86 considered harmful

    Back in 2015 Joanna Rutkowska published a paper ( and pretty much predicted that attention will turn to hardware in search for new vulnerabilities. It's compelling, because owning a system at this level is more persistent, less visible and harder to get rid of.

  5. Nick Ryan Silver badge

    Security is not something that can be patched in later


    Security is not something that can be patched in later

    Read. Then read again.

    Either design security in from the start or expect a lifetime of ball-ache problems such as are those now being discovered in x86 (and by extnension AMD64 instruction set) processors, similar to what have been repeatedly cropping up in the higher application layers for years. The techniques used in the Meltdown and Spectore exploits is very similar to those used to attack websites and web applications. The PC has evolved from a standalone system with a single administrative (trusted) user running a single process to a networked system running multiple processes, with different users and different access levels. Unfortunately all of this was bodged on top and not designed in from the start. Expect pain, expect a lot of it and expect a lot more to come until things are rather radically changed to support security from the bottom up.

    1. Anonymous Coward
      Anonymous Coward

      Re: Security is not something that can be patched in later

      Problem is, security interferes with getting the job done (unless security IS your job), and the first priority of any job is to get the f'ing job done.

    2. eldakka

      Re: Security is not something that can be patched in later

      > such as are those now being discovered in x86 (and by extnension AMD64 instruction set) processors,

      The recent exploits (Spectre, Meltdown, Intel's ME problems and so on) have absolutely nothing, at all, to do with the x86 instruction set or with processors that implement the x86 instruction set specifically.

      Spectre and Meltdown are to do with speculative execution. A CPU-engineering - completely instruction set agnostic - technique to increase performance. It is bugs in the design and implementation of these features that have caused these issues.

      Similar techniques are implemented in PowerPC, SPARC, ARM and other more esoteric (or more niche) architectures.

      IBM has been releasing firmware patches to deal with these issues on PowerPC hardware (I work with PowerPC hardware). ARM has as well for their affected (only some of the most recent designs, all older ARM designs prior to about 2 years ago were all in-order execution) chips. I don't deal with SPARC (well, not in 5 or so years) so am unaware of what is specifically happening in that sphere.

      These are electronics engineering problems, not x86 problems.

      Like with Spectre and Meltdown, Intel's ME issue isn't an x86 instruction set issue. It is an implementation problem with a general purpose - non-instructoin set specific - CPU-design paradigm, embedding an isolated control-processor into the platform.

      1. Nick Ryan Silver badge

        Re: Security is not something that can be patched in later

        True, if optimisations aren't implemented with security timing exploits in mind then they will affect whatever chipset has them. However I didn't claim the x86 was the only instruction set suffering from these problems, it is the most prevalent and obviously impactful one (especially given cloud and shared host use in general) and my point is that the entire PC (WinTel) execution stack was cobbled together with security only tacked on as a last minute afterthought.

        1. Charles 9

          Re: Security is not something that can be patched in later

          OUR point is that security will ALWAYS be tacked on as an afterthought because the first priority will ALWAYS be "Get the Bloody Job DONE." Unless security IS your job, security will NEVER be the first priority. Put it this way. You can BS around a wrong answer, you can't BS around a missed deadline.

  6. a_yank_lurker

    History Rhyming?

    Reading the post, is it striking how the same underlying problem exists all over the IT landscape. Each area does not think basic security problems should be address until slapped upside the head with a baseball bat (aluminum not wood).

    1. croky

      Re: History Rhyming?

      "basic security problems" ... basic ?!?! for whom ? Lol ! Either you're an expert on the IT subject (if that means anything at all) or a wannabe with a big mouth. "Basic" ... love the generalization, they're smart, you know ? Lolol !!!

  7. Anonymous Coward

    The dangers of a monoculture

    "AV company BitDefender .. last year announced Hypervisor Introspection (HVI), a data centre security technology developed in conjunction with Citrix that protects virtualized servers from the thorny problem of malware exploiting shared memory."

    And no doubt, we'll need another 'technology' to protect HVI from getting hacked. What these innovators need to do is come up with a 'computer' design that can successfully isolate one processes memory from the other.

    "In 2003, security professionals suddenly grasped the size of the challenge facing them and its long-term consequences for development and software management."

    Unless like Rip van Winkle, these security professionals were asleep for decades, they would of been aware of such security issues a lot sooner. DEC Corporation hacked in 1979, AT&T's computers hacked in 1981, Los Alamos National Laboratory hacked in 1983, and so on.

    As in nature, is it wise to run your ecosystem on a very small genetic pool, as in when a virus comes along most of the population gets wiped out. Here's an article by a chap that got fired for saying something similar:

    CyberInsecurity: The Cost of Monopoly

    1. Charles 9

      Re: The dangers of a monoculture

      "And no doubt, we'll need another 'technology' to protect HVI from getting hacked. What these innovators need to do is come up with a 'computer' design that can successfully isolate one processes memory from the other."

      Which is practically impossible because processes have no practical use without the ability to communicate with each other. And it's that communication channel that is, was, and always will be a point of vulnerability.

    2. RandSec

      Re: The dangers of a monoculture

      "What these innovators need to do is come up with a 'computer' design that can successfully isolate one processes memory from the other."

      Probably we need to distinguish different types of "process," as in those which must be running close together for performance, and those which could run independently. The independent processes obviously could be on completely separate hardware, instead of on a single CPU with a single huge virtual memory.

      We also need to be concerned about the way malware infects the OS and perhaps multiple BIOS chips, to affect each and every session. Even replacing the motherboard and reinstalling the OS may not clean the problem unless all other BIOS chips are clean at the same time. Apparently NSA can infect hardware disk drive controllers, which means by now some malware writers can as well. Who among us could detect that, and if we cannot, how can we know we are not infected? Why is our equipment not built to be checked?

      1. Charles 9

        Re: The dangers of a monoculture

        "Why is our equipment not built to be checked?"

        Because that's the first thing they would defeat and fake. Who checks the checkers?

  8. -tim

    More to come?

    There are people who have exploited this to read the entire details of the hidden "security" processors and they are busy writing papers for the next next security conference or selling 0day exploits. If you can get data into L1 cache and can convince a second core that it needs the data real bad, it will get scribbled back to RAM and that makes it game over particularly if the cache line has the permission tables for the master virtual memory table.

    1. Brian Miller

      Re: More to come?

      The biggest problem is developers have the illusion that plain text is secure. It isn't, ever. Even a drive that is locked in a safe isn't secure when the safe gets cracked and the drive gets lifted.

      The best solution I've seen is to use a cryptographic accelerator and the plain text keys and passwords are never to be found in system memory. You can't read something that's sitting over an isolated bus.

      Unfortunately there are too many developers that believe that permissions equate to security. If they even go that far, that is.

      1. Charles 9

        Re: More to come?

        Not even by tapping the bus? The greatest weakness of encryption is that our brains can't grok encrypted content. Therefore, in order to be useful, content MUST be decrypted at some point. The bad guys simply have to wait for that point.

  9. ThatOne Silver badge

    That doesn't sound good for our wallets

    > "While patching is good, that doesn't address the core issue which is at some point you need to upgrade your hardware,"

    Oh my. We had the planned obsolescence due to failing hardware, now he invented planned obsolescence due to security issues...

  10. Anonymous Coward
    Anonymous Coward

    "Popping a cherry on the turd of woe"

    Excellent! Can I use it?

  11. croky

    Keep milking it, reg. Just keep milking it ...

  12. EnviableOne

    Security By Design and Default

    Its baked into GDPR, things have to change, we know the momment time pressures come in, the first three things to go are documentation, testing and security.

    But by changing our ways of working, so security isnt the afterthought, its just the way we do things, will lead to more efficient, more secure, programming and less patches and hapier customers who will pay more.

    If you design in the security in the first place, using never conditions, error handling, input validation, not hardcoding passwords etc. then it solves a lot of the issues before they become vulnerabilities.

    and the whole speculative execution thing, if Intel had just asked should we, rather than just can we, it would

    1. Charles 9

      Re: Security By Design and Default

      Don't be so sure. Remember, Intel has investors to please and customers to satisfy, and security MUST come second to "Get the Bloody Job Done", and it's easier to BS around a wrong answer than a missed deadline so fast trumps right.

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