back to article Another Meltdown, Spectre security scare: Data-leaking holes riddle Intel, AMD, Arm chips

Computer security researchers have uncovered yet another set of transient execution attacks on modern CPUs that allow a local attacker to gain access to privileged data, fulfilling predictions made when the Spectre and Meltdown flaws were reported at the beginning of the year. In short, these processor security flaws can be …

  1. Long John Brass Silver badge
    Facepalm

    And in other news

    Apparently there is a new form of this attack call "Port Smash"

    I seems to work by timing the use of the various LU blocks in modern Hyper-threaded CPUs

  2. Michael Wojcik Silver badge

    Re: And in other news

    Rings a bell.

  3. Long John Brass Silver badge
    FAIL

    Re: And in other news

    Bugger! sorry; Must have missed that one :(

    My bad

  4. swm

    Speed vs. Security

    The chips are doing exactly what they were supposed to do. Namely, burn for speed. If you want real security you have to physically separate different classes of users and not run them on the same chip/computer/memory system etc. My reaction to all of this is I want my computer to be fast and will secure it at the edge.

  5. Walter Bishop Silver badge
    Terminator

    Re: Speed vs. Security

    > My reaction to all of this is I want my computer to be fast and will secure it at the edge.

    'Secure at the edge' would give a false sense of security as once it's breached they have full reign over your computer. Better to have multiple encrypted data path within the computer and processes that are designed to function in a compromised environment. The innovators are really going to have to massively improve their game to defend against networked computer attacks into the future.

  6. Charles 9 Silver badge

    Re: Speed vs. Security

    But that inevitably entails sacrifices in speed: sacrifices users apparently aren't prepared to make. Better to be on-time than wrong because one can BS around a wrong answer but can't around a missed deadline.

  7. Anonymous Coward
    Anonymous Coward

    Re: Speed vs. Security

    "Better to have multiple encrypted data path within the computer and processes that are designed to function in a compromised environment"

    How about instead accepting that the current hardware is not secure and should not be trusted with sensative data.

    Whilst I agree that absolute security does not exist, it must be said that the current hardware manufacturers have chosen to degrade what security there was to be found in earlier systems.

    Since many people earn their crust via computing then it is going to take a long time and a lot of pain before this situation changes. Especially since computers in the workplace have replaced people and skills have been lost during the original transistion, meaning that reversing the trend is going to be vastly more expensive than pretending that all is still well, hence the poopooing of the discovery of yet another CPU design fail.

    It would be nice if the problem was addressed before it becomes a major issue but since those who could act are being paid not to, then everyone else has a lot of pain in their future that will continue until people again believe that putting all your eggs in one basket is a bad move.

  8. Charles 9 Silver badge

    Re: Speed vs. Security

    "It would be nice if the problem was addressed before it becomes a major issue but since those who could act are being paid not to, then everyone else has a lot of pain in their future that will continue until people again believe that putting all your eggs in one basket is a bad move."

    Unless you can only afford ONE basket. Then having all your eggs in there is preferable to trying to carrying them in your arms.

  9. Anonymous Coward
    Anonymous Coward

    Re: Speed vs. Security

    @ "Unless you can only afford ONE basket. Then having all your eggs in there is preferable to trying to carrying them in your arms."

    Ah, the old "change costs too much" ignoring that it is already costing to much already and that without change it will only ever increase in cost. So it is your belief that ignoring problems never makes them worse?

    So it is your opinion that we wait until the wheels fall off and then stand around saying "who'd thunkit" instead, good plan genius

  10. Charles 9 Silver badge

    Re: Speed vs. Security

    It really does cost too much. For many, they couldn't afford it even if they wanted to, their margins are THAT thin. It may be a delicate situation, but that's the hand they're dealt.

  11. This post has been deleted by its author

  12. Orv Silver badge

    Re: Speed vs. Security

    If you want real security you have to physically separate different classes of users and not run them on the same chip/computer/memory system etc.

    Which is why these are of particular concern to cloud hosting providers. An important requirement for cloud systems is that a program running in on user's VM shouldn't be able to observe what's going on in another user's VM.

  13. nagyeger
    Coat

    Just imagine...

    Just imagine that inside your box there were 2 devices. One which you trusted and only ran code that you'd actually installed yourself, and anything that ran anything else (e.g. Javascript) ran on "untrusted" hardware. Then you'd need need to have a way of communicating safely between the two, with some user interface devices and the ability to send data from one to the other, and a fast bus/network between the two. And some machines would have all the oomph in the trusted box and others in the untrusted box for games and stuff, and there'd be a hardware video multiplexer doing it's clever stuff, like an updated version of what we had back in the days of video overlay cards on VGA, so that you don't need to try shoving 120fps video down the network pipe.

    Then high spec machines would include extra separate modules hanging off the bus/network so that eg. game engines didn't interfere with google docs.

    And there'd be a some kind of manager thingy on the main computer to make sure that let you interact with the different untrusted-compute devices while maintaining isolation. Actually, maybe the display/HID ought to be a separate device, maybe with a really simple RO filesystem, and everything work via that main UI box too. ...

    Oh. prior art, my UI box has just basically become an X server hasn't it?

  14. John Smith 19 Gold badge
    Unhappy

    Basically the mfg *promised" both speed and security, but couldn't deliver them

    So they delivered the speed (which users can measure easily) and hoped no one could figure out

    a) They'd relaxed the boundaries between running processes and

    b) No one could find a way to exploit the relaxed separation.

    IOW the illusion of security without actual security.

    I wonder how many process crashes over the years could also be traced to miswritten code influencing another process and crashing that instead? No way to know I guess.

  15. phuzz Silver badge

    Re: Basically the mfg *promised" both speed and security, but couldn't deliver them

    More likely they just didn't think that there would be a security problem with speculative execution. After all, it's not exactly an obvious flaw, it took years for anyone to notice it in the first place, and it's taken almost a year for this fresh crop to be discovered, even when they knew where to look.

    Always assume incompetence rather than malice and all that.

  16. Michael Wojcik Silver badge

    Re: Basically the mfg *promised" both speed and security, but couldn't deliver them

    I wonder how many process crashes over the years could also be traced to miswritten code influencing another process and crashing that instead?

    From transient-execution side channels? None, barring major CPU bugs that have mysteriously gone unreported.

    I think you do not understand how Spectre-class attacks work.

  17. Anonymous Coward
    Anonymous Coward

    New phone

    I wanted to buy a new mobile phone. Got a bad feeling when none of the providers were clear if Spectre/Meltdown issues were really mitigated. I'll wait for Samsung S12.

    Ideally my next phone is powered by a 6502. No apps should need to be bigger than 64 KB code.

  18. _LC_
    Coat

    Re: New phone

    "Row hammer" is still working on most models as well.

    They only want to sell their products. It's a party.

  19. Zippy´s Sausage Factory

    Re: New phone

    Ideally my next phone is powered by a 6502. No apps should need to be bigger than 64 KB code.

    I'm up for that. Maybe I'll start work again on my 6502 assembler that I haven't touched in years then, seems people might need it.

  20. _LC_
    Pint

    Re: New phone

    Can't we settle for the 68k series? That's a 'high-level' language, compared to x86/64 assembler.

  21. Anonymous Coward
    Anonymous Coward

    Re: New phone

    >I'm up for that. Maybe I'll start work again on my 6502 assembler that I haven't touched in years then, seems people might need it.

    You might want to pop over to 6502.org where this processor is discussed in detail, more than 40 years after it was designed. I am surprised the Z-80 didn't have the same longevity, given the enormous success of CP/M.

  22. arctic_haze Silver badge

    Re: New phone

    Yes, we should revert to using Z80 processors. At least my half-forgotten knowledge if its commands could make me indispensable!

  23. Orv Silver badge

    Re: New phone

    Z-80 derivatives continue to have a distinguished career as microcontrollers. They just aren't discussed as much in hobbyist circles because very few game systems used them (the GameBoy being one exception.)

  24. defiler Silver badge

    Waiting for bug-free CPUs?

    For all those who vehemently deny that they'll ever buy a CPU until they're entirely secure and bug-free, best add this (and all derivatives) onto the pile.

    Clue - they'll never actually be bug-free. It's not a perfect world, but it's the one we live in.

  25. Anonymous Coward
    Anonymous Coward

    Re: Waiting for bug-free CPUs?

    >Clue - they'll never actually be bug-free. It's not a perfect world, but it's the one we live in.

    I am sure most readers by far here know that. The issue is not about bugs as such but known bugs that can be exploited. Another bug that will not come to light in another 17 years is not what I am concerned about. An important part about security is to keep the time horizon in mind.

  26. Anonymous Coward
    Anonymous Coward

    Re: Waiting for bug-free CPUs?

    > For all those who vehemently deny that they'll ever buy a CPU until they're entirely secure

    Didn't Intel say that the Itanium was safe against the earlier attacks. I think the world just "Meh, security isn't THAT important".

  27. Orv Silver badge

    Re: Waiting for bug-free CPUs?

    Itanium's VLIW architecture was safe in that the optimizations were mostly done at compile time, so things like speculative execution aren't done on the fly nearly as much. That approach has its own problems, though, like requiring a recompile for every new chip iteration.

  28. BlueCat49

    The good news: You are one small target in a billion.

    The bad news: If they want to access your system they will. If not by hacking then by simply getting a job at your company and gaining access.

    Sort of good news: If you take proper precautions - regular off-site backups, complex passwords that you change regularly and don't reuse - it makes it less likely that the lazy will take the effort to hack you and if hacked you can restore. And don't forget to have those financial company phone numbers handy in case you need to report fraud.

  29. Anonymous Coward
    Anonymous Coward

    I thought the new conventional wisdom was NOT to change passwords so as to allow time for people to actually be able to memorize them and not have to rely on vulnerable mnemonics and sticky notes. Besides, anyone who managed to hack an account would only use it as a beachhead to set up a more-permanent independent access.

  30. Claptrap314 Bronze badge

    It can be done. But at a cost.

    All of these attacks can be prevented by the addition of suitable caches, which are flushed at instruction retirement. Unfortunately, the caches are the bulk of the area of the chips. Furthermore, the wires and logic to drive them are also large.

    But I'm seriously thinking about figuring out how to turn Spectre mitigations off when I'm gaming. Unplug the network, turn off Spectre mitigation, and see how much speed I gain. Stuff is getting unplayable.

  31. _LC_

    Re: It can be done. But at a cost.

    This shouldn't affect gaming that much. Games create their own cosmos. They typically don't rely on system calls. The newly found "Spectre for the GPU" could hit hard, though.

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