back to article You can't ignore Spectre. Look, it's pressing its nose against your screen

The Spectre processor design vulnerability is here to stay. Even if you choose to ignore it, the problem still exists. This is potentially a very bad thing for public cloud vendors. It may end up being great for chip manufacturers. It's fantastic for VMware. Existing patches can fix Meltdown, but only seem to be able to …

  1. Voyna i Mor Silver badge

    Arm A53

    The Arm A53 is still current in many mod-range phones and AFAIK doesn't have out of order execution. The same goes for the A55. AFAIK this should mean that Raspberry Pis and many mid-range Androids are not affected by Spectre.

    1. MacroRodent Silver badge

      Re: Arm A53

      I'm afraid that does not help much, since what we need is an in-order CPU that is also fast!.

      1. Dan 55 Silver badge

        Re: Arm A53

        It's all about the parallelism these days. You can make a Beowulf cluster of Pis.

        1. Anonymous Coward
          Anonymous Coward

          Re: Arm A53

          Raspberry Pi is indeed immune to Spectre:

          https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/

          So, it seems, is Intel Itanium. See comments at:

          https://forums.theregister.co.uk/forum/1/2018/01/25/intel_spectre_disclosed_flaws_november/

          Neither Pi nor Itanium is particularly fast, but I posit that most computers in use today are not CPU-bound so it doesn't matter much. Where CPU is crucial, there are often opportunities for parallelism as already mentioned.

          In the 1990s, one definition of a supercomputer was, a computer that would change a CPU-bound task to an I/O-bound task. If we expand "I/O" to include reads/writes over the Internet, almost anything I do at home is limited more by slow I/O than by CPU speed. I went through a phase of using a Raspberry Pi as my home computer, and it was not too bad. I gave up in the end, mainly because of low RAM on current versions of the Pi and the absence of MS Office to read attachments.

          The main problem using either widely may be that neither ARM as on Pi - nor Itanium - is binary-compatible with x86-64. This isn't an insuperable problem but it implies effort re-compiling and/or developing emulators/translators.

          1. Gezza

            Re: Arm A53

            the transputer's time has come. Step forward Tony Fuge and the Inmos posse. (its always the Brits who turn out to have been right in the end)

          2. Jonathan Schwatrz
            Boffin

            Re: DanielBarker Re: Arm A53

            ".....So, it seems, is Intel Itanium....." There is a good information in

            this explanation by Theresa Degroote at Secure64 of why Itanium's EPIC architecture is immune to Spectre and Meltdown. But it's unlikely that Intel will be shoe-horning Itanium's EPIC architecture into a Xeon package, or that anyone will be rushing out to replace all their Xeon servers with existing Itanium ones. The problem is - and always has been for Itanium - that it's architecture is more expensive to fabricate than x86-64. It would be pretty trivial for Microsoft to get Windows Server 2016 booting on Itanium, it's just would Microsoft be bothered to? Getting the OS to boot is just one problem, after that you have to get all your applications rewritten for the Itanium version of Windows, or accept the probable performance hit of x86-64 emulation on Itanium. After all, the OS and app vendors can simply wait for Intel to temporarily gin up the current Xeon designs with a die-shrink performance boost to alleviate any Spectre fix hit, a temporary cover until the next generation of Spectre-proofed Xeons are designed. Unfortunately for AMD, they seem to be right on the bleeding edge of die shrinkage, so their chance of recovering from Spectre fix performance hits is likely to be harder.

        2. kryptylomese

          Re: Arm A53

          And they are way less powerful than an equivalent costing Intel machine!

          1. Dan 55 Silver badge
            Trollface

            Re: Arm A53

            And they are way less powerful than an equivalent costing Intel machine!

            Was that before or after Spectre/Meltdown patches?

          2. Daniel 18

            Re: Arm A53

            You miss the point.

            All machines wait at the same speed.

            As long as a machine is fast enough for what your are doing, additional speed is of no real benefit.

        3. stephanh Silver badge

          Re: Arm A53

          The Raspberry Pi is more expensive than a core i7 - when measured in performance per £.

          Also the Beowulf cluster of Raspberry Pis was a nice hack, but impractical for almost anything since the networking on a RPi is so slow (it goes over the USB interface).

          Of course, you could put a bunch of ARM A53 on a die in an advanced technology node, with fast interconnect, and get something which would be like a modern-day transputer. Then you merely need to rewrite your software to be efficiently multi-threadable.

          1. Doctor Syntax Silver badge

            Re: Arm A53

            "Then you merely need to rewrite your software to be efficiently multi-threadable."

            You might need to do that anyway if the existing architectures need to be re-done with less out of order processing.

            1. Charles 9 Silver badge

              Re: Arm A53

              But some stuff is too interdependent for efficient multiprocessing, like video encoding.

      2. Voyna i Mor Silver badge

        Re: Arm A53

        "I'm afraid that does not help much, since what we need is an in-order CPU that is also fast!."

        For some value of "need".

        We've gone in the direction of virtualisation essentially because we can. That doesn't mean it is the best long term solution. The Transputer, IIRC, represented a different approach based on throwing lots of CPUs at a problem - parallelism with fast interconnect. Sure, not everything can be parallelised. But if you have one cluster of N CPUs running Y instances where Y >> N, surely you could have a managed cluster of Y CPUs each running one instance? Of course it would mess with licensing and the like, but these are not computer science constructs, they are just ones designed to please Wall Street.

        To use my favourite car analogy, for years manufacturers got more performance with more cylinders and bigger capacity. Then along came the small, efficient turbocharger and advanced simulation and engine management, and suddenly engines were getting smaller, with fewer cylinders, and more powerful. The technology changed to meet new conditions.

        If this all causes a major rethink of computer architecture, it may be a big blessing in disguise.

    2. WatAWorld

      Re: Arm A53

      "Raspberry Pis and mid-range Androids aren't affected by Spectre."

      You aren't implying they're a secure solution are you?

      Yeah single threaded non-speculative processors aren't susceptible to Spectre, but they're susceptible to many many other publicly known and still classified vulnerabilities.

      1. This post has been deleted by its author

  2. Anonymous Coward
    Anonymous Coward

    State-sponsored actors

    Can I be the first to nominate North Korea, Russia or China?

    To be honest I would be surprised if there aren't already tools to abuse this flaw because lets be honest if you are exploiting it you're going to do your best to keep it on the down low.

    1. el kabong

      Re: State-sponsored actors

      NSA, anyone?

    2. Zippy's Sausage Factory

      Re: State-sponsored actors

      I'd also add the USA and Israel to that list. They're almost certainly up to no good, I'm sure...

      1. RegGuy1
        Facepalm

        Re: State-sponsored actors

        And the UK.

        Opps! Silly me. They are too tied up with Brexit to notice. Getting out of Europe is far more important.

        1. Tigra 07 Silver badge
          Coat

          Re: State-sponsored actors

          Pfft. Like UK spooks could manage something like this. Ours are busy doing dodgy shit in hotel rooms and turning up dead in suitcases...The ones that aren't dodgy are Johnny English...

          Mine's the bag with the dead 007 in it.

          1. Bronek Kozicki Silver badge
            Black Helicopters

            Re: State-sponsored actors

            That's what GCHQ wants you to think ...

            1. Yet Another Anonymous coward Silver badge

              Re: State-sponsored actors

              It's time for Britain to step up and state sponsor its own actors.

              I nominate Judy Dench and Daniel Craig

              1. Will Godfrey Silver badge
                Unhappy

                Re: State-sponsored actors

                @WatAWorld

                What makes you think they are on 'our' side?

    3. WatAWorld

      Re: State-sponsored actors

      Amazing how of us overlook the fact of their own governments are doing stuff like this to their allies, even their own citizens.

      Yes, the NSA, GCHQ, Mossad, more than any other intelligence agencies they're likely to have known about this for years, decades, or maybe even before the hardware first shipped.

      That they're on our side doesn't mean we should leave them off the list.

  3. Duncan Macdonald Silver badge

    No shared CPUs

    One way to mitigate the Spectre problem (at a cost) for public cloud providers - do not share CPUs between customers. If only one customers code runs on any CPU at a given time then the problem of Spectre allowing reading of data from other VMs is greatly reduced.

    For big cloud jobs reserving a number of physical CPUs would not impose very much inefficiency but for small jobs that only need one or two cores reserving a whole CPU (with possibly over 10 cores and hyperthreading) would greatly affect the economics.

    It would not surprise me to find Amazon and Microsoft adding the option (at a price) of having dedicated CPUs for customers that are concerned about data security. (Though that begs the question - WHY use a public cloud if you care about data security?)

    1. Gordon 10 Silver badge
      FAIL

      Re: No shared CPUs

      Errr - thats exactly what the article said. Did you read it?

    2. Dan 55 Silver badge

      Re: No shared CPUs

      Or why use a public cloud if it's just a server dedicated for your own use? You might as well just use... your own server.

      1. Loud Speaker

        Re: No shared CPUs

        You might as well just use... your own server.

        but ...

        DevOps

    3. HereIAmJH

      Re: No shared CPUs

      Except that a lot of people use cloud for high availability. If you're going to throw all your hosted VMs on a single host you have just created a single point of failure. For reliability you want your VMs spread across hosts and data centers.

      1. kryptylomese

        Re: No shared CPUs

        You can do that with a Hyper converged solution e.g. Proxmox for very little outlay!

      2. Loyal Commenter Silver badge

        Re: No shared CPUs

        Except that a lot of people use cloud for high availability.

        Not to mention on-demand scalability, something that is important if you have a website that has occasional surges in demand, but you don't want the outlay for tens or hundreds of times the computing power needed for your typical load, which would otherwise sit there idle.

        You know, the actual reason we have cloud computing...

        1. Doctor Syntax Silver badge

          Re: No shared CPUs

          "You know, the actual reason we have cloud computing."

          So what about all the other situations where it's being used?

      3. Ken Hagan Gold badge

        Re: No shared CPUs

        "For reliability you want your VMs spread across hosts and data centers."

        There's no reason why you can't have your dedicated iron spread across several locations. Still, I'm not sure that the article's optimism is well placed. Whilst you may not be sharing iron with other customers, you are sharing it with your VM provider. That provider is still "at risk" from whoever they rent the iron to. Furthermore, as I understand it there is no way to *detect* that you are under attack from Spectre.

        Against that, it is probably true that an outfit like VMware can afford to replace all their kit as soon as safe hardware is available and, as valued customers, will be at the front of the delivery queue.

      4. Loud Speaker

        Re: No shared CPUs

        For reliability you want your VMs spread across hosts and data centers.

        For security, you might not!

        If your organisation is big enough to have more than one building, you can have a server closet in each. Hell, if you are a CEO, you probably have several closets big enough to hold a rack full of servers, and desperately need a reason why your entire mansion should be tax deductable expense: put an Enterprise scale server in one and network it to your galactic HQ. It justifies the cost of food for the enormous, man eating dog you need for security. Saves on the heating bill too! With some creative accounting, it probably even covers a pink pony for your daughter as well.

        (But remember 77dB is QUITE LOUD!)

    4. Jonathan Schwatrz

      Re: Duncan Macdonald Re: No shared CPUs

      "....do not share CPUs between customers...." You can already buy cloud services where you get dedicated hardware, even down to dedicated networking and storage, but it is more expensive.

  4. alain williams Silver badge

    State actors = malware developers

    State-sponsored actors absolutely have the resources to produce malware to exploit Spectre.

    I would be surprised if some did not already have the tools/malware. But as we well know they cannot keep their toys in their playpen, so we have to expect that other ne'er do wells will acquire them.

    1. WatAWorld

      Re: State actors = malware developers

      They have widely used tools, tools they know will be discovered by the other side because they're used so much and so many people internally have access to them.

      And they have tools kept in reserve and only used sparingly.

      Given that each of our intelligence agencies has many times more people dedicated to finding such vulnerabilities and exploiting them than Google does, and that they've all been at this game far longer, I fully suspect that Spectre and Meltdown were discovered and have been used by some of those tools that have been kept in reserve.

      1. Bronek Kozicki Silver badge

        Re: State actors = malware developers

        vCPU pinning is well know, but it makes load balancing difficult. Regular load balancing would be based on assumption that you can always pin more than one vCPU to a single core, and you pin vCPU from multiple VMs to cores on one physical CPU. These assumptions need to go out of the window now.

        I expect Amazon, AWS, Azure etc. will start offering a new tier of services where they indeed guarantee that only your VMs run on any single physical CPU, but this is going to be expensive (you pay for more vCPUs than stricly needed), or slow (poor load balancing), or both.

  5. Milton Silver badge

    Reaping what you sow

    The article is correct, and the fallout from this will continue to be enormous. I have litle confidence that some highly capable actors haven't already started very quietly raiding juicy targets. There are bad things happening now that we'll find out about in six, or 36 months' time, when we'll say "Duh, of course".

    Technical issues aside, I do think there's a moral in here somewhere too. "Cloud" has been relentlessly overhyped as a solution for everything, and its operators have worked tirelessly to sucker customers in, playing up performance, playing down security worries, all the while trying to squeeze every last drop of cash from punters while cutting their own costs. The promise to ghastly beancounters slavering over their next bonus has been irresistible and companies have, often with dangerous haste and poor preparation, tried to offload costs, worries and skills to "Anything Cheaper".

    Now it's not entirely fair to say that "Cloud" is distinct from "servers-in-a-datacentre" mostly because the former opens up yet another dangerous security compromise—but it's not completely wrong either. Beancounters: you believed the 'Good+Cheap+Quick' marketurds' spiel, didn't think hard enough about downsides (security and privacy risks that many folks much more knowledgeable than I have been going on about for years now) and so today ... well, to coin a phrase, the skeletons are coming home to roost.

    Just as you can stipulate that, say, no one with serious security needs would consider SMS-based 2FA, I suggest you could also state that no one with data of real importance or value would keep it on a shared platform in the "cloud".

    1. SquidEmperor

      Re: Reaping what you sow

      I think your last sentence is really the whole point. Regardless of where your server sits unless you have an air-gap between it and ??? you are vulnerable.

    2. John Brown (no body) Silver badge

      Re: Reaping what you sow

      "Beancounters: you believed the 'Good+Cheap+Quick' marketurds' spiel, didn't think hard enough about downsides (security and privacy risks that many folks much more knowledgeable than I have been going on about for years now) and so today ... well, to coin a phrase, the skeletons are coming home to roost."

      On the other hand, it's all one big house of cards. It only takes one bean counter to realise that cheap works for the majority and that's where it all goes. If your competitors don't follow you down that road, they'll go bust. This applies across most of industry, goods and services. There's usually some small niche at the top for quality, lots of cheap tat at the bottom, and not much in between.

    3. Loud Speaker

      Re: Reaping what you sow

      the skeletons are coming home to roost.

      featuring Wallace and Gromit?

  6. Anonymous Coward
    Anonymous Coward

    The good news is it's not being exploited in the wild yet, the bad news is when.

    1. Warm Braw Silver badge

      The good news is it's not being exploited in the wild yet

      It would be difficult to prove that assertion...

      1. ma1010 Silver badge

        So true!

        The good news is it's not being exploited in the wild yet

        It would be difficult to prove that assertion...

        Eventually we might find out that NSA/GCHQ/FSB, etc have known about and been exploiting this for a while.

    2. SquidEmperor

      The bad news is if it was being exploited in the wild you wouldn't know.

  7. Crypto Monad

    Dedicated instances

    In many ways, VMware on AWS may be just be the ultimate solution here. After all, it is dedicated hardware to just you.

    You don't need VMware for that. AWS already offer dedicated instances which are guaranteed not to share hardware with any other customer, but otherwise are managed exactly like regular EC2. Sadly, the small and tiny instance types are not available.

    You pay a premium of $2 per hour per region, so about $17,500 per year, for the privilege. Still, in the wake of Spectre, I expect business to be brisk.

    VMware on AWS costs $51,987 per year per host (if you pay 1 year in advance). Ouch. That gets you a single 2 CPU, 36 core, 512GB RAM box; clearly you'll want at least two for some sort of real-time redundancy.

    Traditional data centre hosting starts to look attractive again.

    1. Crypto Monad

      Re: Dedicated instances

      Oops: for VMware on AWS, "Minimum required configuration is 4 hosts per cluster". So you are looking at minimum spend of $207,948 per year, plus data transfer and IP address charges.

      There is a "hybrid loyalty discount" of "up to" 25% if you already have the full ESX stack licenced and in use on-prem (vSphere, vSAN, NSX).

    2. big_D Silver badge

      Re: Dedicated instances

      Makes me glad that my employer won't even consider cloud computing.

      My current employer won't consider it out of security grounds.

      My previous employer won't consider it, because it is "their" data and therefore needs to be on "their" hardware on "their" site, regardless of any arguments to the contrary.

      1. Yet Another Anonymous coward Silver badge

        Re: Dedicated instances

        My current employer won't consider it out of security grounds.

        And they have you to secure it - and you are better at cybersecurity than all the people at Google and amazon. Or is the entire data center air gapped and in an underground bunker somewhere ?

        1. big_D Silver badge

          Re: Dedicated instances

          Probably not better, but hopefully good enough.

          CEH v9, VMWare CP, MSCSE, LPI. But, everything in the server room is behind out firewall and security systems. We control who has access, we control what software comes on the servers and PCs, we control what extra security is put in place.

          If somebody gains access to the servers, we only have ourselves to blame.

          If somebody gains access to the cloud, the providers shrug their shoulders, try and clean up their act and we are still the ones who get hauled in front of a court for splurging our customers' details.

          1. Ken Hagan Gold badge

            Re: Dedicated instances

            "Probably not better, but hopefully good enough."

            Since you are not trying to secure against an attacker who is legitimately already running on the same hardware, you don't *need* to be better. You don't even need to be as good. I think that's the point that your critic was missing.

        2. Mark 65 Silver badge

          Re: Dedicated instances

          And they have you to secure it - and you are better at cybersecurity than all the people at Google and amazon.

          What makes you think they're so damned good? FFS Google were running non-encrypted comms between data centres and got absolutely fucking owned by the TLAs. Have Google never released security fixes for Chrome? Seriously, your argument is just so weak. They'd need to be orders of magnitude better because

          1. The potential attacker is already on the hardware (shared resources)

          2. As an aggregator of compute users they are such a big fat juicy target whereas Johnny SME just isn't as attractive.

          You are also guilty of making assumptions as to how capable the OP may be. Plenty of talented people would rather not work for companies like Google and by all accounts they seem to have their fair share of chaff.

    3. Uffish

      Re: " guaranteed not to share"

      My tinfoil hat turns blue whenever that phrase occurs.

  8. Doctor Syntax Silver badge

    "What it means is that enterprises are relying on the public cloud to handle the really large workloads."

    Maybe they'll need to look at the relative financial merits of stopping doing that until the new generation of H/W is available vs doing it in-house.

    1. Sir Runcible Spoon Silver badge

      Does this mean the bean-counters now have a magic £/$ figure to put into their risk column?

      All of a sudden cloud computing doesn't look quite so cheap, yet what really, in essence, has changed with regards to the risk? The likelihood has risen, that's all - the impact is the same as it always was.

      1. Doctor Syntax Silver badge

        "The likelihood has risen, that's all - the impact is the same as it always was."

        Risk is a function of both.

        1. Sir Runcible Spoon Silver badge

          I realise that :P

          My point was that cost analysis is related to impact, not whether it will happen or not.

          In my experience bean counters don't listen to techies and tend to vastly underestimate the cost of the impact of some of these issues. I've seen valid observations dismissed because someone who doesn't understand the inter-connectedness of underlying IT thinks the techies are exaggerating the potential impact of a problem arising.

          I've experienced the very same thing on a recent project. Not from the bean-counters, but from the project managers who just want to hit their milestones - regardless of the risk when you cut corners.

  9. Thoguht Silver badge

    Isn't the Xeon Phi in-order? Up to 72 cores with 4 threads per core. Sorted.

    1. Anonymous Coward
      Anonymous Coward

      Xeon Phi processors are not only rather expensive, but pretty slow in ordinary single-thread integer work, since even the highest model tops out at paltry 1700MHz. The lack of out-of-order execution widens the performance gap even more.

      CPU speed isn't critical in file/print serving and such, but when the higher powers want to crunch data in their BI software set, then the CPU is a bottleneck for the next hour or so. (which may be due to bad software since it doesn't do parallel things)

      1. Voyna i Mor Silver badge

        "but when the higher powers want to crunch data in their BI software set, then the CPU is a bottleneck for the next hour or so"

        Reducing the use of BI software and forcing people to use their brains might even prevent the next Carillion.

        1. Doctor Syntax Silver badge

          "forcing people to use their brains might even prevent the next Carillion."

          It depends on the quality of the brains as to whether it prevents the next Carillion.

          1. Voyna i Mor Silver badge

            "It depends on the quality of the brains as to whether it prevents the next Carillion."

            Not entirely. The downside of computers is that it allows stupid people to be stupid even faster, hence the 2008 crisis. In the days when mortgages were handwritten on vellum by clerks, the throughput just didn't allow the same rate of making bad decisions. It was said that the advent of spreadsheets greatly increased fraud as bank managers were taken in by what looked like the product of vast intellectual resources, rather than one conman who had managed to blag time on a PC.

            1. Charles 9 Silver badge

              Trouble is, speed sells. If you can't get them through quickly, customers leave you for someone who can.

  10. 0laf Silver badge

    Sounds like they're left with insurance as a mitigation.

    Who has started selling spectre insurance then?

    1. Sir Runcible Spoon Silver badge

      "Who has started selling spectre insurance then?"

      Since it's just a re-branding exercise I reckon the market will be flooded quite soon.

  11. Missing Semicolon Silver badge
    FAIL

    Smells like the financial crash...

    ... only it's silicon, not CDOs.

    The banks basically got the state to bail them out, and then carried on as before.

    Intel essentially expect us to just queue up to buy new chips and motherboards at full price to fix the problem caused by their poor CPU design.

    If they play their cards right, they will be richer as a result!

    The way I see it, you should be able to get a mail-in rebate on your old processor and motherboard!

    1. Yet Another Anonymous coward Silver badge

      Re: Smells like the financial crash...

      More like farming.

      We fed ground up cow brains to cows to grow faster and were shocked when that turned out to be a bad idea.

      We decided that all that protected modes and ring security could be bypassed to run faster and were surprised when that turned out to be a bad idea

      1. Charles 9 Silver badge

        Re: Smells like the financial crash...

        But it didn't seem like bad ideas at the time, particularly with other, more immediate pressures to address like DEADLINES.

  12. Pascal Monett Silver badge

    "It's not quite that simple"

    And just what exactly can I do about it ? Nada.

    While I applaud any article that draws attention to the security deficiencies of The Cloud (TM), I cannot help but remain unimpressed at this latest expositional piece. Telling me that state actors have the means to create malware to spy on VMs I would have spinning on AWS instances is hardly that important when the NSA can just write a National Security Letter to Amazon and have Bezos send them the data.

    Having another country capable of it does not really make a difference.

    1. Even Jelical

      Re: "It's not quite that simple"

      point = missed completely

    2. iron Silver badge

      Re: "It's not quite that simple"

      @Pascal Monett Yup, another lengthy diatribe by Potts with little or no useful content to take away from it.

    3. Ken Hagan Gold badge

      Re: "It's not quite that simple"

      "Having another country capable of it does not really make a difference."

      On the contrary, if you are a US company (or a close enough friend), it is unlikely that the NSA will write such a letter with the intention of causing your business to suffer a cataclysmic accident that wipes you off the map. (OK. In practice it might be more sensible to cause you a thousand minor headaches that, over time, make you less competitive than your rivals. But you get the idea.)

      Some other countries intelligence agencies might have different priorities.

  13. Gordon 10 Silver badge
    Meh

    A bit less FUD please El Reg

    How is this any worse than a zero day in any of the VM hypervisors? Lets have a sense of perspective please.

    They basically say that organisations have to do everything within their power to protect against any flaws that they reasonably should have known existed.

    The above is mostly bollocks - every regulation that I have come across has a "reasonableness test" ie it wasn't reasonable to expect us to replace all our servers.

    Lets look at whats needed to actually weaponise Spectre.

    1. Develop exploit code.

    2. Deploy exploit code.

    3. Actually find something worth stealing in several Gigs worth of randomly addressed memory per server whilst all the while trying not to get caught.

    Points 2 & 3 essentially mean that the biggest risk is either a bulk attack that will quickly be spotted and closed out AND which also requires another exploit to plant a lurker on a significant set of kit. OR a targeted attack on a known juicy target ala NSA and GCHQ.

    Either of which is only med risk IMO.

    There are bigger risks to worry about.

    1. Anonymous Coward
      Anonymous Coward

      Re: A bit less FUD please El Reg

      "zero day in any of the VM hypervisors"

      I'll see your patch-able zero day and raise you an undetectable exploit that could potentially be used to re-write your OS.

    2. 2Nick3 Bronze badge

      Re: A bit less FUD please El Reg

      Regarding #3, they're running the exploit on cloud. Where, per the article:

      "What it means is that enterprises are relying on the public cloud to handle the really large workloads."

      So it's pretty much exactly where they want to be. It would be easy enough to pull the data using the exploit, then process it to see if there's anything useful, or if not directly useful if there's a good target - say a banking operation. If you know you're running on a good host, then you keep pulling data until you get what will be useful to exploit.

      And from what it sounds like no one will have any idea that you're doing it.

  14. SPiT

    Can anyone explain why we should consider SPECTRE a hardware fault

    I continue to be confused about why everyone keeps talking about SPECTRE as if it is a hardware fault. As far as I can make out the issue is that SPECTRE can be used to read the entire readable address space of your own process. The hardware security promise is that you CAN do this. The problem lies with the whole idea of running a sandboxed program within this environment that cannot see the rest of the address space without having a security rules commitment from the CPU manufacturer. The only sensible way to have safe sandboxing is to have a hardware promise behind it. The obvious solution is for all scripting / sanboxing solutions to use essentially the same solution as for meltdown, make sure that the only mapped memory in the process environment as that which is allowed with the benefit that if you don't have a meltdown problem you can use privilege flagging to protect it.

    I appreciate that there are issues around how virtualisation works but the idea that Javascript, for example, wasn't massively exposed to sandbox breaches anyway is madness.

    1. TechnicalBen Silver badge

      Re: It kind of is and is not.

      No one realised this side channel was actually usable. They may of known it was there, and "possible", but some things are possible but not practical (brute forcing some encryption hits the heat death of the universe etc).

      So while the software was partially vulnerable to SPECTRE, the hardware continued with branch prediction because it was thought to be a near impossibility to exploit. Turns out it can be done (though slowly, at KB/MB per hour kind of speed). It's a bit like the row hammer exploits etc. It's a part of the "failings" of computing, not of a specific design (halting problem, P versus NP problem etc).

      Google have already hinted at a way to mitigate it entirely. But setting up any (and only to avoid performance hits else where) sensitive data to be branch prediction proof (though in their case I think they do it via blocking branch prediction for that bit of code, not proofing the actual code it's self entirely).

      So that kind of mitigation will take changes from the ground up, and a lot of time. It will still leave the occasional programmer/compiler writing out the password to an unprotected bit of memory and being at risk of being read... unless the entire computer blocks branch prediction, this will be the extra work needed to mitigate it. :(

    2. mevets

      Re: Can anyone explain why we should consider SPECTRE a hardware fault

      Spectre lets you read other processes address space; Meltdown lets you read a privileged address space. Where it gets confusing is that the privileged address space is in your map, you just aren’t supposed to be able to peek at it. Sadly you are.

      Modern CPUs have branch prediction mechanisms which inform the speculative execution mechanism whether it is likely a given (conditional) path will be followed. The predictor works from virtual addresses, which I think is part of the mistake, they should work from virtual address + Address Space IDentifier. Since my process has virtual addresses, as does my victims, and we likely share code in a shared library (libc.so, {mumble}.dll, ...) I can choose an address in my mapping of this library, and poison the branch predictor to favour a particular path. Then, when my victim runs in the area of this path, the branch predictor will follow it, and dirty the cache based upon the data. I then measure the cache dirt, and voila, I know what that data was.

      Seems like a lot, but with the use of decent analysis tools to find candidate paths and a little reverse engineering of some programs, and a pile of money or bitcoins as the payoff, you are away.

      It strikes me that there is a readily available mitigation for OSes: don’t permit the same virtual address to appear in two address spaces. This means that libc.so would be mapped to unique locations in each process. Most binaries are relocatable [ needed for ASLR ] so it shouldn’t be a big deal for them; that leaves only ‘forked’ processes as potential victims, and only forked copies of them can be used to induce the predictor.

      This would have been tragic in 32bit machines, but 64bit machines, even with lowly 47 bit VAspace can still offer 1024 unique address spaces of 140 GBytes...

  15. thondwe

    Containers worse than VMs?

    Suggestion is that once the Microcode fixes are available and don't do further damage attacks from VMs to Kernels is sorted for the moment? However, App <-> App attack is still an issue - so Container style hosting is in real trouble?

  16. Anonymous Coward
    Anonymous Coward

    Hit to clouds?

    So does this mean that cloud services are going to be shunned for the foreseeable future? Will there be a rush to go back to self hosting of data as a more secure storage method?

    N

    1. SquidEmperor

      Anyone got some cheap C90 cassettes?

      What? Are we not cloud now? I just off loaded my last C90 cassette tapes (Hot Hits of the 80's Vol.3) because I thought we were all cloud, spotify and netflx. I should have listened to my mother.

  17. Ugotta B. Kiddingme

    but hang on a bit

    I thought we already had a proper solution for SPECTRE

  18. Tim Brown 1

    Unecessarily alarmist

    The biggest weakness in any organisation is always going to be the human element. The "password on a post-it note" syndrome.

    Why bother going to the immense time and trouble of developing speculative Spectre exploits to harvest random data when you could just honey-trap a senior executive who has all the access you need?

    1. Steve the Cynic Silver badge

      Re: Unecessarily alarmist

      Obligatory reference: https://xkcd.com/538/

    2. croky

      Re: Unecessarily alarmist

      You're absolutely right. Most people just want the drama and, some, the need to be a valid target. Probably, it makes them feel more important ... This whole soap opera is hilarious. Almost ridiculous, I might add.

    3. Ken Hagan Gold badge

      Re: Unecessarily alarmist

      For a honey-trap, you need to target a particular individual, devote human resources to the task, and risk being found out. The cost-per-attack and the risk are both quite high. With Spectre, the whole thing can be automated and it is undetectable.

  19. WatAWorld

    For 5 decades we've known no connected computer is truly secure

    Intelligence agencies spy on intelligence agencies, so clearly it doesn't matter how hard anyone tries, there will always be vulnerabilities in systems connected to anything.

    You want real security: Lock your computer is a bank-quality safe in a faraday cage room. Never remove it from that room. Never connect it. Don't transfer data by any means other than retyping.

    We've known this for 5 decades. And still there are people out there who think "one more patch and it will be secure". No it will not.

    There will always be some link in the chain of any useful system via which information can leak out.

    Please stop implying otherwise.

    1. Charles 9 Silver badge

      Re: For 5 decades we've known no connected computer is truly secure

      You forget TEMPEST. They can glean information simply from electromagnetic radiation: a natural consequence of it being SWITCHED ON. Basically, the only secure computer is one that is never used AT ALL. If it's used in any way, it CAN be pwned by a sufficiently-determined adversary. Problem is, that bar keeps getting lower.

  20. WatAWorld

    I wonder how many years intelligence agencies have been using spectre?

    Something to think about.

    I wonder how many years our and their intelligence agencies have been using spectre?

    Is it just years? Is it decades?

    Did they know even before day one of device production?

    And if not for "White Hat Hackers", I wonder how many more years would have gone by where only intelligence agencies (and maybe a few chip maker employees) knew about Spectre?

    The bug was there for over a decade and no free-enterprise criminal figured it out.

    There is a near endless supply of *obscure* bugs and *obscure* vulnerabilities that have been out there for years and decades that no free-enterprise criminal has figured out yet.

    And none of them will be an issue until some PhD candidate or Google employee does a paper revealing them.

    Security by obscurity: It isn't only Apple customers who rely on that. We ALL do -- even the NSA, GCHQ, Mossad, 3PLA, and FSB.

    (The word "obscure" as used in "obscure bugs and obscure vulnerabilities" is important to my meaning. Of course vulnerabilities a criminal could realistically discover and utilize should be revealed. Vulnerabilities that have existed for decades undiscovered -- how likely is it that with so many other easier vulnerabilities to find and use they'd have invested the time and effort into this?)

    I'm not sure the answer. Where do we draw the line at "realistically discover"?

    And what new vulnerabilities are introduced by hasty fixes? (And in this case "hasty fixes" being fixed down with less than 2 years lead time.)

    And even fully considered and tested fixes, the added complexity they'll create, will those introduce new vulnerabilities?

    I don't know what to think, other than that there is no way to have complete security on a connected computer.

    1. Charles 9 Silver badge

      Re: I wonder how many years intelligence agencies have been using spectre?

      There's no way to have complete security, short of total destruction. The only way to be sure is to burn it, dissolve it, or melt it: something sufficiently physical and irreversible.

      But if you have to use it, then there WILL be a way to pwn it, simply because legal and illegal access can use the same interfaces.

  21. herman Silver badge

    Sir Mick said it best

    Hey, you! Get offa my cloud!

    1. Anonymous Coward
      Anonymous Coward

      Re: Sir Mick said "Hey, you! Get offa my cloud!"

      "Hey McLeod! Get offa my ewe!"

  22. Richard Conto

    Governance model

    The human housing market suggests a SET of solutions:

    (*) Own your own

    (*) Rent dedicated, private unshared housing

    (*) Rent shared housing

    (*) Rent target market specific housing

    (*) Buy into a condominium (where you know who else is there)

    (*) Buy into a co-op (where you govern together. Somehow.)

  23. amanfromMars 1 Silver badge

    AIDanegeld Option/Future/Root

    A number of security experts I have spoken to confirm that the Spectre problem has not gone away, nor is it going to any time soon. There is some concern, however, about the messaging that is emerging around this vulnerability.

    Spectre can theoretically allow code operating in a VM to read code in the cache of the physical CPU. If anyone figures out how to exploit it then it can allow someone executing code in one VM to peek into what's running in memory of another VM.
    ....... The Position here now is that now IT is, and Fully Cogniscent of the Immaculate Transubstantiation.

    All SCADA Systems are forever Susceptible to Novel IntelAIgents Adventing and Distributing New Knowledge, A Taster of which has been Diligently and Valiantly Registered ITSelf in a Post share earlier here .... https://forums.theregister.co.uk/forum/1/2018/01/25/uk_prime_minister_encryption/#c_3407738 ..... Introducing Quantum Field Great Games Plays

    Something Extra Terrestrial Supplied for Heavenly Endeavours ..... AIMaster PilotedD Plans. Or is IT AI of your Own Build?

    What when IT is Both .... with JOINT Applications for Others to Enjoy and Move on and Make a Move to/on the Next Great Temptation?

    You know there we're talking SCADA Core Systems Meltdown.

    Interesting Times ahead. Of that be Perfectly Reassured.

  24. croky

    Seriously, I'm tired of this Spectre Meltdown bla bla bla ...

    I mean, what's the probability for me to become a target ? That's the "elephant in the room" question some people don't want to answer. It seems those people need to freak out for some "ah" reason.

    1. diodesign (Written by Reg staff) Silver badge

      Re: croky

      "I mean, what's the probability for me to become a target ?"

      Spectre is irritating because it's hard to fix and lets software read stuff it shouldn't. This means JavaScript in the browser can sniff out secrets from the kernel and other tabs. There are PoC exploits for this out there. It's important for ppl to update their stuff, hence the attention on the flaws.

      Likewise Meltdown: malware will be along to lift stuff out of the kernel.

      PS: For us, the biggest thing about it is the embarrassing design cockup and the messy fixes, rather than this being the total end of the world (because it isn't).

      C.

      1. croky

        Re: croky

        "Secrets" ? Who wants those "secrets" ? Does the "other end" even know I've got any "secrets" ? Even if I have "secrets", they don't know what they are ! Thus, who on planet earth is willing to waste time searching for "secrets" they don't even know about what they are ? That's for a 12 year old with tooooo much imagination. Just like any paranoid, over analyzer, micro manager and nitpicker I see popping around here and there. People need to get a grip and to get real. Being so, show me proof people are being attacked, left and right, thanks to Spectre and Meltdown.

        1. Uffish

          Re: "secrets"

          I still use a phone number that was listed in phone books, when they existed. At the time I thought that keeping your phone number secret was stupid. Now I get at least two phone calls per day from what I assume are cold calling companies. They persist even though for the last two years everything has been blocked by an answering machine. Why do they persist? I suppose somehow there would be a profit in getting through to me. Do I regret not keeping my phone number secret - yes.

          1. KSM-AZ

            Re: "secrets"

            A robo dialer walks the exchange. Could care less if you are or were "listed" at some point.

        2. diodesign (Written by Reg staff) Silver badge

          Re: croky

          >"Secrets" ? Who wants those "secrets" ? Does the "other end" even know I've got any "secrets" ?

          By secrets, I mean: passwords and personal information. And yes, you have them in your computer. This is why it's good to patch - when good patches arrive, natch.

          >Show me proof people are being attacked, left and right, thanks to Spectre and Meltdown.

          No one's said people are. Relax guy. You're overreacting.

          C.

          1. croky

            Re: croky

            > "Passwords and personal information. And yes, you have them in your computer. This is why it's good to patch - when good patches arrive, natch."

            Lol, take it easy man and try to avoid all this paranoia. Please ... It's good for security but bad for performance. But anyway, you're not even questioning my argument. Not a little. I mean, can Spectre and Meltdown perform attacks remotely ? Proof ? And still, the main question. Why would anyone try to attack me ? You guys should all calm down and rethink your position ...

            > "No one's said people are. Relax guy. You're overreacting."

            Lol ! This is so ridiculous ... I'm the one not caring about the supposed severity Spectre and Meltdown in regards to my personal computer. Remember ? Again, all of you really need to relax and get another perspective about all this, other than this mass paranoia.

      2. Tim Brown 1

        Re: croky

        This means JavaScript in the browser can sniff out secrets from the kernel and other tabs. There are PoC exploits for this out there.p

        Does it really? I mean really? Care to link to one of those proof of concepts?

        If Javascript is able to do that then first and foremost it's a bug in the browser code and nothing to do with Spectre.

        Spectre, as I understand it can only be exploited by code with root privileges on one virtual machine to attempt to grab info from another.

      3. Jonathan Schwatrz
        Boffin

        Re: diodesign Re: croky

        "....the embarrassing design cockup....." Well, to be fair to Intel, they perfected prefetch as a performance boost long before virtualization or containers on x86 were even thought of. IIRC, the first real performance boost from prefetch came with the Intel 8086*, the first real x86 CPU, which had a six-byte prefetch queue. Intel also had the 8088s which had higher core frequencies than the 8086s but performed worse because it only had a four-byte prefetch queue, which meant the faster core was kept idling more than the slower 8086. Intel realized that keeping the core working was more beneficial than just making it fast and kept on tuning the prefetch performance as the x86 CPUs developed, making it a central part of the design. I expect Intel would prefer to try and work out a way to segregate the individual prefetch areas rather than a complete redesign.

        *The 8086 was developed from 1976 and released in 1978, long before VMware was even dreamed of.

        1. diodesign (Written by Reg staff) Silver badge

          Re: Jonathan Schwatrz

          "Well, to be fair to Intel, they perfected prefetch as a performance boost..."

          I think you missed the point of my post. I meant Meltdown/Spectre reveals an embarrassing cockup in Intel's processor designs (and Arm, AMD, etc for Spectre). Yeah yeah, prefetching and speculative exec and branch prediction speeds stuff up. That wasn't the point of my post.

          The point is that chip engineers left security in the glovebox the day they parked up in the company lot and walked in to design those parts of the pipeline.

          It's like a manager told them: "Speed. Security. Price. Pick one."

          C.

          1. Ken Hagan Gold badge

            Re: Jonathan Schwatrz

            "The point is that chip engineers left security in the glovebox the day they parked up in the company lot and walked in to design those parts of the pipeline."

            That's a tad unfair. At the launch of the Pentium-Pro, to exploit Spectre you would need to have used the RDTSC instruction to get the necessary timing resolution. That instruction, introduced in the Pentium, can be kept away from user-level code precisely because Intel knew that it would assist side-channel attacks. It is probably still possible to keep RDTSC away from user-level code, although I suspect it would make a lot of programs unhappy.

            As far as I know, it isn't possible to keep it away from a guest kernel. However, anticipating the security needs of a VM host was perhaps not on everyone's radar at that time. (There were serious academic papers around explaining why the x86 ISA was not virtualisable and VMware only managed it through a heroic exercise in on-the-fly disassembly and re-writing of code.)

          2. Jonathan Schwatrz
            Boffin

            Re: diodesign Re: Jonathan Schwatrz

            ".....The point is that chip engineers left security in the glovebox the day they parked up in the company lot and walked in to design those parts of the pipeline....." True, I suspect security was pretty low on the list in the '70s when the original 8086 was designed. I'm not disagreeing that Intel missed a big security hole, I am just pointing out that Intel got hooked on prefetch performance tuning when CPUs were single cores only, application loads were pretty much one per system, and no-one had even thought of virtualization on x86. It seems Intel did forget to do the design security review they should have done later (IIRC, VMware Workstation wasn't releases until 1999, for example) when customers started sharing CPU time on x86. Before then, virtualization was for big enterprise systems only.

            1. diodesign (Written by Reg staff) Silver badge

              Re: apologist

              "True, I suspect security was pretty low on the list in the '70s when the original 8086 was designed"

              The security hole was introduced way after the 8086. Basically, Intel and others screwed up. They're trying to spin this away as a design side effect.

              Like a plane crashing mid-flight is a side effect of a substantial fuel tank leak.

              C.

              1. Jonathan Schwatrz
                Facepalm

                Re: diodesign Re: apologist

                "Apologist"? Not apologizing, just seeing how Intel got hooked on prefetch performance tuning and how that could have blinded them to the problem. I think every Intel slide deck I've seen since the mid-'80s has bragged about their lead in cache hit ratios. Redesigning the cores to hit the same performance levels without relying on prefetch tuning will be an expensive challenge, unless if they can find a way to segregate cache between apps via software.

                "The security hole was introduced way after the 8086. Basically, Intel and others screwed up. They're trying to spin this away as a design side effect....." Hmmm, debatable. The hole was predicted by the original HP EPIC design team in the '90s, which is why the EPIC-based Itanium is immune. When Intel bought into EPIC as Itanium they intended that EPIC was going to be their future CPU design and would replace RISC and CISC, only AMD upset the applecart with the 2003 release of the cheaper Opteron CPU with 64-bit extensions to the 32-bit x86 design. In the scramble to get x86-64 CPUs out the door to compete it's not surprising that Intel missed a few points. For all we know, there may be other nasties still hidden in the x86-64 design.

    2. Voyna i Mor Silver badge

      Re: Seriously, I'm tired of this Spectre Meltdown bla bla bla ...

      "I mean, what's the probability for me to become a target ?"

      The probability for someone to get into the servers of a company which has your credit card details and to loot your account? The probability that someone gets into the Land Registry database and you find someone else owns your house? That your pension fund disappears?

      You're missing the point; it isn't your PC they are after.

      1. croky

        Re: Seriously, I'm tired of this Spectre Meltdown bla bla bla ...

        "You're missing the point; it isn't your PC they are after."

        Lolol ! That's exactly my point ! I'm solely referring to the common consumer. You me and most of the people reading this. That's why I ask "what's the probability for ME (ME, ME, ME) to become a target ?". And of course and please, patch and secure critical systems, just like you said. Those are THE targets. Not us ...

        1. Jonathan Schwatrz
          Alert

          Re: croky Re: Seriously, I'm tired of this Spectre Meltdown bla bla bla ...

          ".....I'm solely referring to the common consumer....." Well, the average "common consumer" makes lots of online purchases via browsers these days, and it could be possible for this bug to be exploited so malware could read your saved credit card details or your one-click password out of the bit of cache that it was prefetched into.....

    3. hmv

      Re: Seriously, I'm tired of this Spectre Meltdown bla bla bla ...

      The probability that you're a target? Specifically you? Low.

      As someone with presumably a credit card, bank card, an email address, ... the probability reaches 1.0

    4. Ken Hagan Gold badge

      Re: Seriously, I'm tired of this Spectre Meltdown bla bla bla ...

      "I mean, what's the probability for me to become a target ? "

      As I noted in a reply to a comment a few remarks above this one, the probability might be higher than you think, since the attack is easily automated and almost risk-free for the perpetrator. A state-level attacker rolling out a global offensive might easily catch you in the cross-fire simply because it is impractical *not* to attack you.

  25. Anonymous Coward
    Anonymous Coward

    This will make my next conference interesting

    Was at Sector 2017 in mid November (Just before Intel CEO sold off a whack load of Intel shares) and one of the SAST/DAST vendors who only offer cloud solutions insisted that there is no reason why someone would not submit their IP into the cloud.

    I asked if they had a on premise solution since I insisted that there is no way come hell or high water that the stakeholders of what I'm involved with would ever put anything remotely close to online ever, period. They said "That is the old way of thinking, cloud is safe", or "Why wouldn't you put it in the cloud, its encrypted", or "Guaranteed it is safer than in house solutions", or "Its a binary, why wouldn't you put it online" with stuff that gets multi-level encrypted (using two different algos)...

    Oh I cant't wait to see those sales guys at my next conference experience, actually wondering if they will even be there.

  26. sisk Silver badge

    I would hope that the big winners in all this would be Arm and AMD. I think that after the fiasco of Meltdown that vendors would be wary of Intel. Granted most AMD and some Arm processors are also vulnerable to Specter, but at least the vulnerability they have is a failing shared across the entire industry and any fixes they release are likely to be better tested and better thought out than the joke of a Meltdown fix released by Intel.

  27. Long John Baldrick

    Does This Affect AMD Epyc CPUs

    Trevor - You spend a great deal of time talking about the issue and Intel but not whether or not it affects the AMD Epyc CPUs. Could you enlighten us?

    1. Trevor_Pott Gold badge

      Re: Does This Affect AMD Epyc CPUs

      AMD and some ARM chips are affected by Spectre. But let me be 100% clear on this: AMD is completely irrelevant to this discussion.

      AMD chips might powerful a smallish percentage of endpoints, but they power almost none of the existing fleet of deployed servers. Even if, for some reason, we all decided to buy AMD tomorrow, AMD couldn't deliver. At full ramp, AMD would struggle mightily to put out enough silicon to cover 10% of planetary server capacity during the next refresh cycle, and there is zero indication that demand exists for them to invest in that many wafers.

      I'm sorry, but in the real world, AMD just isn't part of the any discussion about server chips. There's only one player in that market, and they'll be the one everyone buys replacement chips from.

      1. Ken Hagan Gold badge

        Re: Does This Affect AMD Epyc CPUs

        "I'm sorry, but in the real world, AMD just isn't part of the any discussion about server chips. There's only one player in that market, and they'll be the one everyone buys replacement chips from."

        True, but in the real world *now* there is no player at all in that market. Whilst it is reasonable to expect that Intel will come up with a safe CPU on roughly the same timescale as AMD, they do need to deliver on that expectation.

        1. Trevor_Pott Gold badge

          Re: Does This Affect AMD Epyc CPUs

          Why do you assume CPUs have to be "safe" for people to buy them? Do you honestly think that Spectre has slowed down CPU purchases? Do you think anyone but the handful of nerds that haunt these forums and some security nerds that read the Grugq a lot actually care about any of this?

          Make no mistake, Intel is still the seller of server CPUs. They'll keep on being the seller of server CPUs through the lawsuits, and they'll emerge from this as the seller of server CPUs.

          I'm as much of a fan of the underdog - and hence AMD - as anyone, but let's be realistic. Intel has an iron-fisted monopoly, and unless someone goes in there with the Almighty Axe Of Anti-Trust and cleans them out, they'll continue being a monopoly for at least the next decade.

          You know it. I know it. Everyone except a few deluded die-hards knows it. So let's no pretend about this, shall we?

          The people who buy things don't give a fnord about "security", and they never have. If they did, the Internet of Things wouldn't be such a gor'ram security dumpster fire. Nobody would ever buy Cisco or Supermicro again, and the list goes on and on and on.

          But you know what else? It's not their asses that end up in front of the judge. It's us. The hoi polloi at the coal face. Nobody sends suits to jail. They make some poor bastard working in ops the lightning rod and ruin his life, and the lives of his family instead.

          So yeah, Intel's dominance isn't going anywhere. Nobody's going to do a bloody thing about it. We're going to be responsible if/when it all goes horribly wrong, and we should know about this ahead of time so that we can take precautions and/or run the hell away in terror. (Depending on how you view risk.)

          For suits, the only risk they care about it "will this cost me some of my bonuses". For nerds, the risk we need to worry about is "will this land me in front of a judge"? I leave it as an exercise for the reader to work out how likely (or not) they feel this is to affect their chances of negative consequences.

          But we should all have eyes open here and understand that this issue isn't going away, and that we, as the plebians, have no choice but to deal with it.

  28. Anonymous Coward
    Anonymous Coward

    The mind was boggling at a possible solution. I'm just glad that there is some mitigation for Spectre albeit at a cost of isolating your usage to separate individual servers and patching your own machines as best you can.

    Although, I am left nervous at the talk by people from a multitude of organizations that say there are many more snafu's out there that just haven't been made known to the right people.

    The lyrics made famous by Dr Hook, keep playing in my head.

    "Walk right in, sit right down

    Daddy, let your mind roll on

    Walk right in, sit right down

    Daddy, let your mind roll on

    Everybody's talkin' 'bout a new way of walkin'

    Do you want to lose your mind?

    Walk right in, sit right down

    Daddy, let your mind roll on"

  29. JeffyPoooh Silver badge
    Pint

    Hmmm... Would this help?

    It's not as hopeless as described. There are endless mitigation strategies. Acknowledge in advance that these are merely suggestions intended to spur progress and provide encouragement.

    Perhaps the world's Cloud servers could be reprogrammed (in the OS, which is not "hard") to semi-randomly switch all User programs between CPUs (or CPU cores) so that any particular nefarious Kernel-stealing malware keeps waking up in a new CPU (or core) with every multiprocessing switch-e-roo. The net result is that the nefarious Spectre-based malware gets small sections of various assorted Kernel memories; effectively random noise. The speed delta between slow Spectre vice Kernal processes makes this feasible. The Kernel memory doesn't have to sit there like a 'sitting duck'. Linus has some work to do, it might take a week or two.

    Or... ('The Art Of War' Alert) ...load the Kernel memory with a bait string, again an OS function, and then have a supervisor monitor any User programs for this bait string. Like a "Bait Car", if they steal it then they're caught.

    Or... reprogram the OS to trivially "encrypt" (trivially scramble) the Kernel memory, no longer trusting it to be inherently secure. Just mix-up the data a bit so that the Spectre-based malware can't trivially read-out the sensitive data. Keep it moving, and the arguably slow speed of the Spectre attack makes the stolen data into noise.

    Or... the world's Cloud providers can automatically audit User code in a virtual machine before allowing it to be executed in the real system. Then the code would be signed and locked down as 'Trusted'.

    Or... Isolate high value trusted clients away from the wild West of the untrusted public's Cloud executed programs. Put the most likely hacker customers all in the same box and let them hack each other. Trusted customers such as Banks and e-Commerce folks (anyone dealing in credit cards) can be segregated away from the unwashed masses.

    Or... etc.

    PS: Some of those 'Or's might be 'And/Or's.

  30. Anonymous Coward
    Anonymous Coward

    Sensitive systems = no added risks ??

    Some systems deal with sensitive information in main memory. If such a system is infected with malware, then you've ALREADY got a problem. The bad actors don't need to install Spectre based attacks; if they can get malware onto the system then they're already won. They could just "clock out" the sensitive data. The kernel memory isn't that much more interesting than what's in main memory.

    1. amanfromMars 1 Silver badge

      Re: Sensitive systems = no added risks ??

      The kernel memory isn't that much more interesting than what's in main memory. ... Anonymous Coward

      Oh yes it is ..... and spectacularly more so, for it delivers Remote Practically Anonymous Virtually Autonomous Command and Control of Administration Systems ..... to SMARTR Drivers.

      1. amanfromMars 1 Silver badge

        An Almighty Resource is Resourceful AI ..... and as a TS/SCI Sensitive System,

        ..... Peerless Pioneering Perfection for the Passions and Temptations of an Adam with Eve. Nymphs and Satyr Territory whenever Everything is Just Right and Quite Perfectly Conceived.

        And that is Original Source with an Abiding Systemic Vulnerability for Immaculate 0Day Plays ...... with an Advanced IntelAIgent Utility for further Exploitation and Expansion with Perfect AIDevelopments.

        And something for AIWizards with GCHQ to Virtually Master Pilot with Quantum Communication Drivers .......... Heavenly Wave Machines :-)

        I Kid U Not.

        cc ..... C/M

        Knock, Knock, No 10! Your systems are hacked with Crack AI Mentoring and Monitoring Governments Actions/Reactions/Proactions. What would now be the best sane act for an administration failing New Virtualised Fields for Work, Rest and Play?

        Might I Propose Immediate Engagement?

        1. amanfromMars 1 Silver badge

          Re: An Almighty Resource is Resourceful AI ..... and as a TS/SCI Sensitive System

          What do you think, El Reg/El Regers? Is all of that some of that fake news or something else completely different and true .... and impossible to deny is excitingly attractive?

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–2019