It&#x27;s a developing story, but from the information we have so far, it does look like Intel involving AMD is a disingenuous since AMD processors are not affected by the most serious of the issues.

To be fair, the Intel post alludes to collaborating with AMD&#x2F;ARM on mitigating Spectre, but userspace memory leaking is wholly separate from kernel memory leaking (Meltdown, which only affects Intel processors).

yeah the intel response page is filled with people claiming intel is evil for even mentioning amd<a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=16064545" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=16064545</a>

There aren&#x27;t really any special Android ARM CPUs, maybe they are confident it doesn&#x27;t really work on Android because it&#x27;s very difficult to get the timing precision and low-level assembly sequences in Java&#x2F;ART compiled code. Though I wonder how that squares up with JNI.I think the key to the statement is in any case that you need to differentiate between what is possible on the processor architecture level when you have full software control, and what is possible on an operating system level, where 3rd party applications are further restricted in various arbitrary ways such as only allowed to use Java, limited access to high resolution timing primitives, etc. that can make practical exploitation impossible, even if the flaw is present.It&#x27;s difficult to reason about because it&#x27;s hard to tell if you can manipulate a JIT runtime into generating the code you need for the exploit to work - and as the JavaScript implementations show, the answer is often &quot;yes&quot;.

The ARM white paper goes into detail <a href="https:&#x2F;&#x2F;developer.arm.com&#x2F;-&#x2F;media&#x2F;Files&#x2F;pdf&#x2F;Cache_Speculation_Side-channels.pdf?revision=966364ce-10aa-4580-8431-7e4ed42fb90b&amp;la=en" rel="nofollow">https:&#x2F;&#x2F;developer.arm.com&#x2F;-&#x2F;media&#x2F;Files&#x2F;pdf&#x2F;Cache_Speculatio...</a>

Sounds like maybe SOME ARM and SOME AMD are implicated, especially since the Android ARM CPUs appear to be fine...

They weren’t effected by the really bad Intel big names Meltdown. They’re still susceptible to Spectre.

We won&#x27;t know until we have the full details. From the linux patches it looked like that AMD x86-64 processors were not affected.But the sentence you quote adds AMD back into play. Maybe some of its ARM processors? e.g. AMD Opteron A1100?

Here&#x27;s a list of what google tested:Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz (called &quot;Intel Haswell Xeon CPU&quot; in the rest of this document)AMD FX(tm)-8320 Eight-Core Processor (called &quot;AMD FX CPU&quot; in the rest of this document)AMD PRO A8-9600 R7, 10 COMPUTE CORES 4C+6G (called &quot;AMD PRO CPU&quot; in the rest of this document)An ARM Cortex A57 core of a Google Nexus 5x phone [6] (called &quot;ARM Cortex A57&quot; in the rest of this document)<a href="https:&#x2F;&#x2F;googleprojectzero.blogspot.com&#x2F;2018&#x2F;01&#x2F;reading-privileged-memory-with-side.html" rel="nofollow">https:&#x2F;&#x2F;googleprojectzero.blogspot.com&#x2F;2018&#x2F;01&#x2F;reading-privi...</a>

Links to descriptions of similar vulnerabilities in AMD and ARM processors would be very welcome.

That&#x27;s not even close to a thread...You can see all the tweets here (courtesy of @svenluijten): <a href="https:&#x2F;&#x2F;twitter.com&#x2F;i&#x2F;moments&#x2F;948681915485351938" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;i&#x2F;moments&#x2F;948681915485351938</a>.

We should have an annual vulnerability&#x2F;amelioration award (the Cerberus?) and give one to those guys.

&gt; computer security Nobel prizeWhile they&#x27;re not as big of a deal AFAIK, we do have the Pwnie Awards: <a href="https:&#x2F;&#x2F;pwnies.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;pwnies.com&#x2F;</a>

I can&#x27;t really see how it would be fixable even with new hardware.Speculative execution is fundamental to getting decent performance out of a CPU. Without it you should probably divide your performance expectations by 5 at least.Rolling back all state rather than just user visible state in the CPU is neigh on impossible. When you evict something from the cache, you delete it. Undeleting is hard. There are also a lot of other non-user-visible bits of state in a CPU.

See the Twitter thread here: <a href="https:&#x2F;&#x2F;twitter.com&#x2F;nicoleperlroth&#x2F;status&#x2F;948678006859591682" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;nicoleperlroth&#x2F;status&#x2F;948678006859591682</a>(Edit: there are 9 posts total, go to her user page to see them all)Seems there are two issues. One, called Meltdown, only effects Intel and is REALLY bad, but the kernel page table changes everyone is making fixes it.The other, dubbed Spectre, is apparently common to the way all processors handle speculative execution and is unfixable without new hardware.I’d like to know more about that but I haven’t seen anything yet.Whoever discovered this stuff on Google’s team deserves some sort of computer security Nobel prize.

&quot;We reported this issue to Intel, AMD and ARM on 2017-06-01&quot;What!

You can find the details below. They&#x27;ve tried AMD CPUs also.<a href="https:&#x2F;&#x2F;googleprojectzero.blogspot.com&#x2F;2018&#x2F;01&#x2F;reading-privileged-memory-with-side.html" rel="nofollow">https:&#x2F;&#x2F;googleprojectzero.blogspot.com&#x2F;2018&#x2F;01&#x2F;reading-privi...</a>

Not exactly; it says &quot;we are unaware of any successful reproduction of this vulnerability that would allow unauthorized information disclosure on ARM-based Android devices.&quot;

And yet it also says that AMD devices running Android are not vulnerable.I&#x27;d be curious how those two statements should be reconciled.

&quot;These vulnerabilities affect many CPUs, including those from AMD, ARM, and Intel, as well as the devices and operating systems running them.&quot;Curious. All other reports I&#x27;ve read state that AMD CPUs are not vulnerable.

Wow, what a find for the Project Zero team. This team and idea can only be described as a success, well done.

I like the way you say moment as if the android kernel is some single thing not a hodgepodge of hundreds of different kernels across tens of companies.

LineageOS is based on official Android sources. The moment the official Android kernel is patched, LineageOS will use the patch.

Will patches for this eventually trickle down to things like LineageOS?

The paper from the other people who discovered this says the same thing: &quot;We also tried to reproduce the Meltdown bug on several ARM and AMD CPUs. However,  we did not manage
to successfully leak kernel memory with the attack de-
scribed in Section 5, neither on ARM nor on AMD.&quot; The general purpose attack that leaks kernel memory, the one that KAISER fixes, only seems to work on Intel CPUs. Intel&#x27;s press release was misleading.

Interesting. Quoting a fair-sized chunk for context:&gt; So far, there are three known variants of the issue:&gt; Variant 1: bounds check bypass (CVE-2017-5753)
&gt; Variant 2: branch target injection (CVE-2017-5715)
&gt; Variant 3: rogue data cache load (CVE-2017-5754)&gt; During the course of our research, we developed the following proofs of concept (PoCs):&gt; A PoC that demonstrates the basic principles behind variant 1 in userspace on the tested Intel Haswell Xeon CPU, the AMD FX CPU, the AMD PRO CPU and an ARM Cortex A57 [2]. This PoC only tests for the ability to read data inside mis-speculated execution within the same process, without crossing any privilege boundaries.&gt; A PoC for variant 1 that, when running with normal user privileges under a modern Linux kernel with a distro-standard config, can perform arbitrary reads in a 4GiB range [3] in kernel virtual memory on the Intel Haswell Xeon CPU. If the kernel&#x27;s BPF JIT is enabled (non-default configuration), it also works on the AMD PRO CPU. On the Intel Haswell Xeon CPU, kernel virtual memory can be read at a rate of around 2000 bytes per second after around 4 seconds of startup time. [4]&gt; A PoC for variant 2 that, when running with root privileges inside a KVM guest created using virt-manager on the Intel Haswell Xeon CPU, with a specific (now outdated) version of Debian&#x27;s distro kernel [5] running on the host, can read host kernel memory at a rate of around 1500 bytes&#x2F;second, with room for optimization. Before the attack can be performed, some initialization has to be performed that takes roughly between 10 and 30 minutes for a machine with 64GiB of RAM; the needed time should scale roughly linearly with the amount of host RAM. (If 2MB hugepages are available to the guest, the initialization should be much faster, but that hasn&#x27;t been tested.)&gt; A PoC for variant 3 that, when running with normal user privileges, can read kernel memory on the Intel Haswell Xeon CPU under some precondition. We believe that this precondition is that the targeted kernel memory is present in the L1D cache.If I&#x27;m reading this right, then the only POC that works against ARM is the first one, which lets you read data within the same process. Not too impressive. (Yes, I know that I&#x27;m reading into this that they tried to run all the POCs against all the processors. But the &quot;Tested Processors&quot; section lower down leads me to believe that they did in fact do so.)The third and fourth POC seem to be Intel-specific.

Thanks! We&#x27;ve merged another thread and updated this link from <a href="https:&#x2F;&#x2F;security.googleblog.com&#x2F;2018&#x2F;01&#x2F;todays-cpu-vulnerability-what-you-need.html" rel="nofollow">https:&#x2F;&#x2F;security.googleblog.com&#x2F;2018&#x2F;01&#x2F;todays-cpu-vulnerabi...</a>.

link for details for that from Project Zero:<a href="https:&#x2F;&#x2F;googleprojectzero.blogspot.com&#x2F;2018&#x2F;01&#x2F;reading-privileged-memory-with-side.html" rel="nofollow">https:&#x2F;&#x2F;googleprojectzero.blogspot.com&#x2F;2018&#x2F;01&#x2F;reading-privi...</a>

Thanks for clarifying Mike, should be interesting to see how this actually pans out.

Looks like everyone is vulnerable to arbitrary user memory reads, while Intel and ARM are vulnerable to arbitrary kernel memory reads as well.

My read is that vulnerable processors generally have to:1. Have out of order execution2. Have aggressive speculative memory load &#x2F; caching behavior3. Be able to speculatively cache memory not owned by the current process (either kernel or otherwise)4. Have deterministic ways of triggering a speculative load &#x2F; read to the same memory location2 is probably the saving grace in ARM &#x2F; low power land, given they don&#x27;t have the power budget to trade speculative loads for performance (in the event they&#x27;re even out of order in the first place).Caveat: I&#x27;m drinking pretty strong Belgian beer while reading through these papers.

How does that pertain to the vulnerabilities that involve eBPF? My understanding is that eBPF code executes within the kernel, and so would run at the same privilege level.

That article links a commit [1] that contradicts this statement&gt; AMD processors are not subject to the types of attacks that the kernel
page table isolation feature protects against. The AMD microarchitecture
does not allow memory references, including speculative references, that
access higher privileged data when running in a lesser privileged mode
when that access would result in a page fault.And Axios [2] that Zdnet quotes gave a comment from AMD:&gt; &quot;To be clear, the security research team identified three variants targeting speculative execution. The threat and the response to the three variants differ by microprocessor company, and AMD is not susceptible to all three variants. Due to differences in AMD&#x27;s architecture, we believe there is a near zero risk to AMD processors at this time. We expect the security research to be published later today and will provide further updates at that time.&quot;And a comment from ARM:
&gt; Please note that our Cortex-M processors, which are pervasive in low-power, connected IoT devices, are not impacted.[1] <a href="https:&#x2F;&#x2F;git.kernel.org&#x2F;pub&#x2F;scm&#x2F;linux&#x2F;kernel&#x2F;git&#x2F;tip&#x2F;tip.git&#x2F;commit&#x2F;?id=694d99d40972f12e59a3696effee8a376b79d7c8" rel="nofollow">https:&#x2F;&#x2F;git.kernel.org&#x2F;pub&#x2F;scm&#x2F;linux&#x2F;kernel&#x2F;git&#x2F;tip&#x2F;tip.git&#x2F;...</a>[2] <a href="https:&#x2F;&#x2F;www.axios.com&#x2F;how-the-giants-of-tech-are-dealing-with-a-massive-chip-vulnerability-2522206367.html" rel="nofollow">https:&#x2F;&#x2F;www.axios.com&#x2F;how-the-giants-of-tech-are-dealing-wit...</a>

Yeah that&#x27;s a good one, hope they keep it updated &#x2F; link to new info &#x2F; posts as they come out.

Google&#x27;s post is newer and has more insights, the registry article is now outdated.

Another good article: 
<a href="https:&#x2F;&#x2F;www.theregister.co.uk&#x2F;2018&#x2F;01&#x2F;02&#x2F;intel_cpu_design_flaw&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.theregister.co.uk&#x2F;2018&#x2F;01&#x2F;02&#x2F;intel_cpu_design_fl...</a>&quot;AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault.&quot;

&quot;Intel suffers a Meltdown&quot; should be an apt headline for tomorrow&#x27;s headlines.

&quot;AMD chips are affected by some but not all of the vulnerabilities. AMD said that there is a &quot;near zero risk to AMD processors at this time.&quot; British chipmaker ARM told news site Axios prior to this report that some of its processors, including its Cortex-A chips, are affected.&quot;- <a href="http:&#x2F;&#x2F;www.zdnet.com&#x2F;article&#x2F;security-flaws-affect-every-intel-chip-since-1995-arm-processors-vulnerable&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.zdnet.com&#x2F;article&#x2F;security-flaws-affect-every-int...</a>* Edit:From <a href="https:&#x2F;&#x2F;meltdownattack.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;meltdownattack.com&#x2F;</a>Which systems are affected by Meltdown?&quot;Desktop, Laptop, and Cloud computers may be affected by Meltdown. More technically, every Intel processor which implements out-of-order execution is potentially affected, which is effectively every processor since 1995 (except Intel Itanium and Intel Atom before 2013). We successfully tested Meltdown on Intel processor generations released as early as 2011. Currently, we have only verified Meltdown on Intel processors. At the moment, it is unclear whether ARM and AMD processors are also affected by Meltdown.Which systems are affected by Spectre?Almost every system is affected by Spectre: Desktops, Laptops, Cloud Servers, as well as Smartphones. More specifically, all modern processors capable of keeping many instructions in flight are potentially vulnerable. In particular, we have verified Spectre on Intel, AMD, and ARM processors.&quot;

So this confirms the suspicion that the bug allows VM-to-VM disclosure of memory, which would conclusively explain the rush.

That&#x27;s what I&#x27;m thinking, effected by Spectre, but not by Meltdown. But more clarity would be appreciated on Google and AMD&#x27;s front. I mean from a pure PR angle, AMD has a lot to gain if they can clear the air more.

it is effected by spectre, but not by the other.

It seems like it is not affected by the most serious bug, but may be by a lesser one.

Spectre and Meltdown are two different exploits. In this case, the paper is talking about Spectre and they did have a POC that worked on all three major processor families (except for deterministic execution engines in microcontrollers and low end CPUs from ARM as well as a few early Atoms from Intel). AMD is saying that Meltdown, which at first glance seems like the most serious one, doesn&#x27;t effect their processors.

That seems like a rather fragile interpretation of the statement. I had interpreted it to mean they tried the attack on Ryzen and it worked. Given the general nature of their technique why would it not work on AMD chips?

From the Spectre paper-We have empirically verified the vulnerability of several Intel processors to Spectre attacks, including Ivy Bridge, aswell and Skylake based processors. We have also verified the attack’s applicability to AMD Ryzen CPUs. Finally, we have also successfully mounted Spectre attacks on several Samsung and Qualcomm processors (which use an ARM architecture) found in popular mobile phones.So in other word, the researcher haven&#x27;t tried it on AMD processors, but they think the attack would work. AMD, on the other hand, is saying the attack won&#x27;t work.Frankly, I believe in PoC||GTFO, so AMD is safe in my book for now.

You&#x27;ve successfully made it less clear.There is a nice table on AMD&#x27;s website though:<a href="https:&#x2F;&#x2F;www.amd.com&#x2F;en&#x2F;corporate&#x2F;speculative-execution" rel="nofollow">https:&#x2F;&#x2F;www.amd.com&#x2F;en&#x2F;corporate&#x2F;speculative-execution</a>

AMD is saying that:<pre><code> !(susceptible_v1 &amp;&amp; susceptible_v2 &amp;&amp; susceptible_v3)
</code></pre>
They are not saying that:<pre><code> !susceptible_v1 &amp;&amp; !susceptible_v2 &amp;&amp; !susceptible_v3
</code></pre>
(the latter would be rendered in English as: &quot;AMD is not susceptible to any of the the three variants&quot;)

As almost everyone seems to be getting this wrong: It&#x27;s &quot;affected&quot;, not &quot;effected&quot;. &quot;effected&quot; means roughly &quot;caused&quot;, while &quot;affected&quot; means roughly &quot;influenced&quot;.

So, is AMD effected or not? This seems fairly important. The Google blog post sort of goes against itself in this regard. AMD itself has said:&quot;The threat and the response to the three variants differ by microprocessor company, and AMD is not susceptible to all three variants. Due to differences in AMD&#x27;s architecture, we believe there is a near zero risk to AMD processors at this time.&quot;So either AMD is lying or Google&#x27;s blog post is wrong. Granted AMD&#x27;s statement is a bit muddled, not sure if they mean they aren&#x27;t susceptible to all THREE variants (as in only 1&#x2F;3) or they aren&#x27;t susceptible to ALL three variants (as in none of them.)

Only if your speculative reads do cause irreversible side-effects on those caches. You could implement them in a way that doesn&#x27;t modify the caches... but that would be complicated and probably use more power and have lower performance.

You can&#x27;t unwind completely. Once the cache is full, to load something on the cache, it has to evict something else. You might be able to evict what you just loaded, but you can&#x27;t undo the earlier eviction.

So, as I gather, one of the main culprits is that unwinding of speculatively executed commands is done incompletely. That is something that the people doing the unwinding must have noticed and known. Somewhere the decision must have been made to unwind incompletely for some reasons (performance&#x2F;power&#x2F;cost&#x2F;time).As for the difference between AMD and intel. (From other posts here, not this one.) The speculative execution can access arbitrary memory locations on intel processors while this is not possible on AMD. This means that on intel processors you can probe any memory location with only limited privileges.As for the affected AMD and ARM processors I&#x27;m none the wiser. How are they affected? Which models are affected? Does it allow some kind of privilege escalation? The next days will surely stay interesting.

The short term answer is to patch the servers and swallow the 30% performance cut. Still likely cheaper than dedicated servers.

&gt; The infrastructure that runs Compute Engine and isolates customer workloads from each other is protected against known attacks. This also means that customer VMs are protected against known, infrastructure-based attacks from other malicious VMs.

This basically kills cloud computing for anything sensitive using shared hardware. In the short term this will actually be good for cloud providers because the demand for dedicated instances will shoot up as there is no short-term alternative.

&quot;Compute Engine customers must update their virtual machine operating systems and applications so that their virtual machines are protected from intra-guest attacks and inter-guest attacks that exploit application-level vulnerabilities.&quot;&quot;Compute Engine customers should work with their operating system provider(s) to download and install the necessary patches.&quot;

Chrome is listed as impacted.  People use chrome password managers.

Until someone figures out how to exploit it using JavaScript. The speed this moves it could be any minute now.

the big if is whether javascript code that can exploit this can be written. (edit: that&#x27;s a yes, from the pdf itself...) if yes, nobody&#x27;s safe, as any webpage (any webpage, even that ad in an iframe) could in theory read your password if it&#x27;s anywhere in RAM.

Main&#x2F;Big impacts are on the cloud computer.For home computer, standard office use, there is no impact at this point, right?

This means that Customer A&#x27;s VM cannot attack Customer B&#x27;s VM.However, if the OS inside the VM is unpatched, then code inside the VM can attack other code inside the VM. If for example you install some malware on your VM, it could use this attack.(I am not a security expert, this is just my understanding and not a official Google statement)

&gt; The infrastructure that runs Compute Engine and isolates customer workloads from each other is protected against known attacks. This also means that customer VMs are protected against known, infrastructure-based attacks from other malicious VMs.Doesn&#x27;t Google say that they are protected...?

Hmm. Is OpenBSD patched for Meltdown? I don&#x27;t see anything on their main site.

We should quote OpenBSD&#x27;s Theo de Raadt here, all the way back from 2007:&quot;x86 virtualization is about basically placing another nearly full kernel, full of new bugs, on top of a nasty x86 architecture which barely has correct page protection. Then running your operating system on the other side of this brand new pile of shit.&quot;<a href="https:&#x2F;&#x2F;marc.info&#x2F;?l=openbsd-misc&amp;m=119318909016582&amp;w=2" rel="nofollow">https:&#x2F;&#x2F;marc.info&#x2F;?l=openbsd-misc&amp;m=119318909016582&amp;w=2</a>

Was this quote removed from the article? I&#x27;m no longer able to find it.

&quot;Testing also showed that an attack running on one virtual machine was able to access the physical memory of the host machine, and through that, gain read-access to the memory of a different virtual machine on the same host.&quot;Holy shit.

More details at <a href="https:&#x2F;&#x2F;googleprojectzero.blogspot.com&#x2F;2018&#x2F;01&#x2F;reading-privileged-memory-with-side.html" rel="nofollow">https:&#x2F;&#x2F;googleprojectzero.blogspot.com&#x2F;2018&#x2F;01&#x2F;reading-privi...</a>

I couldn&#x27;t find it in the blog post or the Compute Engine Security Bulletin, does anyone know which version of Linux Kernel contains the mitigation?

See this blog post, which is some very informed speculation based on public Linux kernel patch activity. <a href="http:&#x2F;&#x2F;pythonsweetness.tumblr.com&#x2F;post&#x2F;169166980422&#x2F;the-mysterious-case-of-the-linux-page-table" rel="nofollow">http:&#x2F;&#x2F;pythonsweetness.tumblr.com&#x2F;post&#x2F;169166980422&#x2F;the-myst...</a>

Based on a link here yesterday, there was a patch to the Linux kernel and comments associated with it.

Do we know how news of this got out before the disclosure date?

&quot;all traces&quot; includes timing differences in execution of non-privileged code, which it turns out are not rolled back.

Speculative execution isn&#x27;t supposed to leak information; if the speculative instructions aren&#x27;t supposed to execute, all traces of them should be rolled back. I&#x27;d be curious to see what the details of this bug really are. I&#x27;m not sure how much will be disclosed in the interests of keeping exploits from popping up.

Incredible that in this day and age that chip designers do not prioritize performance over security.

<a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=14988652" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=14988652</a>

I think the chip designers never thought of security much:<a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=16062223" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=16062223</a>It&#x27;s a similar situation to other timing attacks, which have been around practically as long as caches.

Long time ago, in a far away office park there was an intense discussion over so called &quot;flag early&quot; and &quot;flag after&quot; designs.Flag early camp argument was - protected pages should not be allowed to be fetched to begin with by any insecure execution flow, and we need to pagefault before speculative executionThe &quot;flag after&quot; camp was all for post-factum pagefaulting when the branch has finished execution, so you do not need to pagefault for every branch, and only do it for the branch that has &quot;won&quot;Chip design magazines from nineties has all that well covered.

According to this comment, it has been theorized for quite some time:<a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=16066165" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=16066165</a>With this particular computer scientist, who talked about this problem before, referenced in Google&#x27;s paper:<a href="http:&#x2F;&#x2F;www.cs.binghamton.edu&#x2F;~dima&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.cs.binghamton.edu&#x2F;~dima&#x2F;</a>

Speculative execution seems like something that would be very intuitively insecure even to a layperson(relative to the field of course).I&#x27;m wondering, was this vulnerability theorized first and later found out to be an actual vulnerability? Or was this something that nobody had any clue about?I&#x27;m only saying this, because from a security perspective, I imagine somewhere at some point very early on someone had to have pointed out the potential for something like speculative execution to eventually cause security problems.I just don&#x27;t understand how chip designers assumed speculative execution wouldn&#x27;t eventually cause security problems. Is it because chip designers were prioritizing performance above security?

<a href="http:&#x2F;&#x2F;spectreattack.com" rel="nofollow">http:&#x2F;&#x2F;spectreattack.com</a>

A perfect occasion to invite others into my current exercise of using the web without JavaScript.

&quot;We wrote a JavaScript program that successfully reads data from the address space of the browser process running it.&quot;Yeah, it&#x27;s pretty bad.

Can someone with a little more experience this low-level let me know if this is as bad as I think it is?Because this looks real bad:&gt; Reading host memory from a KVM guest

<a href="https:&#x2F;&#x2F;security.googleblog.com&#x2F;2018&#x2F;01&#x2F;todays-cpu-vulnerability-what-you-need.html" rel="nofollow">https:&#x2F;&#x2F;security.googleblog.com&#x2F;2018&#x2F;01&#x2F;todays-cpu-vulnerabi...</a>Yes, this explains why it was lifted.

&gt; We are posting before an originally coordinated disclosure date of  January 9, 2018 because of existing public reports and growing  speculation in the press and security research community about the  issue, which raises the risk of exploitation.

It says at the bottom they were both done by the same person.

From the site:&gt; Both the Meltdown and Spectre logo are free to use, rights waived via CC0. Logos are designed by Natascha Eibl.

I feel like the Meltdown logo was done by a real designer, and Spectre was designed by a bored developer.

Accelerated, but not vastly. Google&#x27;s post says &quot;We reported this issue to Intel, AMD and ARM on 2017-06-01&quot;, so the embargo still ended up holding for 7 months, even with it ending a week early. The domain registration dates of 2017-12-22 seem to be just when Google started to prepare for releasing the publicity materials, not when the vulnerability was discovered.

Sorry to be daft, but hasn&#x27;t the Google Zero team jumped the gun on the coordinated disclosure date by publishing their blog post 6 days in advance?

Both domains were registered on 2017-12-22. Given the planned disclosure on 9th January that Google mentions and MS and others coding patches silently [1], do the early reports [2] of kernel patches, does this mean that due to coding in the open the whole disclosure procedure has been vastly accelerated?I wonder how the timing relates to New Year and many companies having holidays in CW1.[1] <a href="https:&#x2F;&#x2F;lists.freebsd.org&#x2F;pipermail&#x2F;freebsd-security&#x2F;2018-January&#x2F;009651.html" rel="nofollow">https:&#x2F;&#x2F;lists.freebsd.org&#x2F;pipermail&#x2F;freebsd-security&#x2F;2018-Ja...</a>[2] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=16046636" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=16046636</a>

<a href="https:&#x2F;&#x2F;spectreattack.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;spectreattack.com&#x2F;</a>Information site with some more information, and links to papers on the two vulnerabilities, called &quot;Meltdown&quot; and &quot;Spectre&quot; (with logos, of course).(<a href="https:&#x2F;&#x2F;meltdownattack.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;meltdownattack.com&#x2F;</a> goes to the same site)

&gt;running on the host, can read host kernel memory at a rate of around 1500 bytes&#x2F;second,I kinda get how it works now. They force a speculative execution to do something with a protected memory address, and then measure the latency to guess the content. They did not found a way to continue execution after a page fault as rumors were.The fact that speculative execution branch can access protected memory, but not to commit its own computation results to memory in ia32 was known since pentium 3 times.It was dismissed as &quot;theoretical only&quot; vulnurability without possible practical application. Intel kept saying that for 20 years, but here it is, voila.The ice broke in 2016 when Dmitry Ponomarev wrote about first practical exploit scenario for this well known ia32 branch prediction artifact. Since then, I believe, quite a few people were trying all and every possible instruction combination for use in timing attack until somebody finally got one that works that was shown behind closed doors.Edit: google finally added reference to Ponomarev&#x27;s paper. Here is his page with some other research on the topic <a href="http:&#x2F;&#x2F;www.cs.binghamton.edu&#x2F;~dima&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.cs.binghamton.edu&#x2F;~dima&#x2F;</a>

That&#x27;s unclear, to the point of being factually wrong. Variant 2 and Variant 3 POCs only affect Intel, and those are the ones people are most talking about, and at least to me, the most concerning.Treating them as a group, ignores the very real differences in effect.<a href="https:&#x2F;&#x2F;googleprojectzero.blogspot.com&#x2F;2018&#x2F;01&#x2F;reading-privileged-memory-with-side.html" rel="nofollow">https:&#x2F;&#x2F;googleprojectzero.blogspot.com&#x2F;2018&#x2F;01&#x2F;reading-privi...</a>

Google security blog says it is.&gt; These vulnerabilities affect many CPUs, including those from AMD, ARM, and Intel, as well as the devices and operating systems running them.<a href="https:&#x2F;&#x2F;security.googleblog.com&#x2F;2018&#x2F;01&#x2F;todays-cpu-vulnerability-what-you-need.html" rel="nofollow">https:&#x2F;&#x2F;security.googleblog.com&#x2F;2018&#x2F;01&#x2F;todays-cpu-vulnerabi...</a>

Yes, AMD is affected. There are multiple vulnerabilities (Project Zero refers to 3 separate &quot;variants&quot;, variant 1 and 2 being called &quot;Spectre&quot; and variant 3 being called &quot;Meltdown&quot;). The most serious variant only affects Intel, but can be patched. The other 2 variants affect AMD, ARM, and Intel, and cannot be patched.See this excerpt from spectreattack.com:&gt;Which systems are affected by Meltdown?&gt;Desktop, Laptop, and Cloud computers may be affected by Meltdown. More technically, every Intel processor which implements out-of-order execution is potentially affected, which is effectively every processor since 1995 (except Intel Itanium and Intel Atom before 2013). We successfully tested Meltdown on Intel processor generations released as early as 2011. Currently, we have only verified Meltdown on Intel processors. At the moment, it is unclear whether ARM and AMD processors are also affected by Meltdown.&gt;Which systems are affected by Spectre?&gt;Almost every system is affected by Spectre: Desktops, Laptops, Cloud Servers, as well as Smartphones. More specifically, all modern processors capable of keeping many instructions in flight are potentially vulnerable. In particular, we have verified Spectre on Intel, AMD, and ARM processors.

This is not correct.
That&#x27;s just what the POC chose to implement.

Of the variants of the attack that can leak privileged memory, AMD is only impacted if a non-default kernel configuration is enabled: &quot;BPF JIT&quot;

Is this saying that AMD is affected? Is this the same as the Intel bug reported earlier?

Then surely you must also argue that all data-dependent, side-channel attacks, such as key recovery attacks against some cryptographic algorithm implementations, are the fault of the hardware.Unlike Intel, ARM and AMD are implicated only where the attacker can inject code or data (specifically data that is manipulated by pre-existing vulnerable code) into the target address space. The particular kernel exploits require injection of a JIT-compiled eBPF program, as they said they were unable to locate any suitable gadgets in existing compiled kernel code. I wouldn&#x27;t rule out gadgets being found in the future, but much like cryptographic software timing attacks, the proper fix is to refactor sensitive software logic to be data independent. There&#x27;s no way to implement an out-of-order, superscalar architecture and protect against this stuff simply because of the nature of memory hierarchies. All you can do is 1) ensure that privilege boundaries are obeyed (like AMD and ARM do, but Intel notable doesn&#x27;t), and 2) provide guaranteed, constant-time instructions that programmers and compilers can reliably and conveniently leverage. Unfortunately, all the hardware vendors have sucked at providing #2 (much timing resilient cryptographic software relies on implicit, historical timing behavior, not architecturally guaranteed behavior), but it nonetheless still requires cooperation by software programers, making it a shared burden.Also, FWIW, basically everybody outside the Linux echo chamber has known that eBPF JIT and especially unprivileged eBPF JIT was a disaster waiting to happen. This is only the latest exploit it&#x27;s been at the center of, and the 2nd in as many months. The amount of attention and effort that has gone into securing eBPF is remarkable, but at the end of the day even if you could muster all the best programmers for as much time as you wanted it&#x27;s still an exceptionally risky endeavor. Everything we know about the evolution of exploits screams that unprivileged eBPF JIT is an unrelenting nightmare. But it&#x27;s convenient, flexible, and performant, and at the end of the day that&#x27;s all people really care about, including most Linux kernel engineers. The nature of the Linux ecosystem is that even if Linus vetoed unprivileged eBPF JIT (optional or not), vendors would have likely shipped it anyhow. It&#x27;s an indictment of the software industry. Blaming hardware vendors (except for the Intel issue) is just an excuse that perpetuates the abysmal state of software security.

They go into detail in the white paper <a href="https:&#x2F;&#x2F;developer.arm.com&#x2F;-&#x2F;media&#x2F;Files&#x2F;pdf&#x2F;Cache_Speculation_Side-channels.pdf?revision=966364ce-10aa-4580-8431-7e4ed42fb90b&amp;la=en" rel="nofollow">https:&#x2F;&#x2F;developer.arm.com&#x2F;-&#x2F;media&#x2F;Files&#x2F;pdf&#x2F;Cache_Speculatio...</a>They are adding a new instruction to control speculation...

Arm also claims it is working as intended:&gt; Arm recognises that the speculation functionality of many modern high-performance processors, despite working as intended, can be used in conjunction with the timing of cache operations to leak some information as described in this blog.I personally don&#x27;t agree, but I guess they&#x27;re trying to avoid needing to issue a recall for over ten years worth of CPUs?

&gt; We have some ideas on possible mitigations and provided some of those ideas to the processor vendors; however, we believe that the processor vendors are in a much better position than we are to design and evaluate mitigations, and we expect them to be the source of authoritative guidance.Intel: &quot;Recent reports that these exploits are caused by a “bug” or a “flaw” [..] are incorrect.&quot;So much for &quot;authoritative guidance&quot;, fuck these guys.

<a href="https:&#x2F;&#x2F;spectreattack.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;spectreattack.com&#x2F;</a> :).

Could somebody please coin a name for this? Wikipedia currently calls it &quot;Intel KPTI flaw&quot;, but that is very vague. It&#x27;s quite difficult to talk about something without a simple easy-to-remember name.Edit: has been settled, it&#x27;s <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Meltdown_(security_bug)" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Meltdown_(security_bug)</a> .

&gt; Meltdown breaks all security assumptions given by address space isolation as well as paravirtualized environments and, thus, every security mechanism building upon this foundation.&gt; On affected systems, Meltdown enables an adversary to read memory of other processes or virtual machines in the cloud without any permissions or privileges, affecting millions of customers and virtually every user of a personal computer.

The issue is with the chip.  So, it should impact any OS running on the chip.  This would include Windows as well as MacOS running on Intel chips.

Does this vulnerability affect Linux only, or any operating system?

How about based on how many of the serious issues are found by Google.   It has been one after another.

I don&#x27;t know how you would evaluate such a thing as &quot;best security team,&quot; but Project Zero certainly attracts a high calibre of security expert. If you&#x27;re into breaking things, why wouldn&#x27;t you want to break things with other bright people and the support of a massive corporation?

Not really, they are mentioned in the article. What is fascinating is the number of discoveries by the Google team. The Wikipedia page has a summary of the prominent ones: <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Project_Zero_(Google)" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Project_Zero_(Google)</a> these are not bugs in obscure pieces of software but on major services and operating systems.

Did you forget the Technical University of Graz students who came up with rowhammer and KAISER in the first hand?

Worth noting that in this case, many of the authors are in academia. It wasn&#x27;t solely a Google project.

Hm that&#x27;s tricky. These awesome findings didn&#x27;t exactly provide net value for google, not even on the not so short term (next 10 years?). They&#x27;ve created a large problem for Google! :-)

Oh, come on. Their only goal is to make Google money. The fact that they do useful work is a nice side effect, but if they didn&#x27;t improve Google&#x27;s security and give good PR there&#x27;s not a chance in Hell Google would keep them around.

&gt;their primary [0] goal is altruistic: ... making the internet and computing as a whole a safer place.Which is, at the same time, highly rational: to secure their entire market.It&#x27;s nice to have big corp&#x27;s incentives aligned with the public good. Too bad it happens so rarely.

Suppose you have transportaion company that owns 80% of the market share for everything transported on the roads. By car, van, truck, semi, everything.Suppose your company also has a team that inspects public bridges to make sure they don&#x27;t collapse.Is it really altruistic, or given your market share is it a cost of business?

Project Zero is very well known for things exactly like this. Partially, it&#x27;s because they are incredibly talented, but there are also talented people in academia and in other security consultancies. The biggest difference with Project Zero is that their primary [0] goal is altruistic: find vulnerabilities, and let people who can fix them know (vs publishing papers, securing paying clients, auctioning zero-days, etc), in the interests of making the internet and computing as a whole a safer place.[0] Their secondary goals are to protect Google products and services, and to provide excellent PR in line with what we&#x27;re discussing right here.

If true, how are edge computers going to connect to the cloud?

Hmm, or maybe it&#x27;s a reason to go with bare-metal providers :)

The irony here is that a good ol&#x27; dedicated hardware web server is far less susceptible to Meltdown or Spectre than Google Cloud, because only your code is running on the CPUs.I predict tonight&#x27;s disclosures will lead to an uptick in interest in running websites on dedicated hardware, like we did back at the turn of the century.

I can&#x27;t imagine better marketing for cloud services than making it as clear as you can that the world is a very dangerous place for computers and if you don&#x27;t have a crack team of hundreds of battle-hardened security engineers then you have no business hooking your computers up to the internet.

Cloud services will benefit from this greatly.Spectre occurs no matter you are in cloud or not, while cloud companies can advertise themselves to help customers proactively to mitigate such risks.

No collision has been found in SHA-256. SHA-1 is the broken hash function

I wonder how much of it relates to their mastery in data science.I keep wondering if they got some “””AI””” fuzzer that helps them a ton? Plus tons of compute power to spend (remember SHA-256 clash they found “just because”?)

Has Google the best security team in the world? It seems like Google security is in a complete different league. I cannot imagine how this impacts companies handling fiat money or cryptocurrencies in the cloud like Coinbase in AWS.

Why would you do that? If you are concerned for the security of your coins, you should have moved them to a wallet you own that is not hosted on an exchange. The bank you transfer your dollars to is just as likely to get hit by the exact same vurnerability. In addition you have to pay a fee to move your coins, then to wire the dollars to your bank account. Moving from crypto to fiat is also 	
liable to taxation. If the sole goal is to secure your coins then I don&#x27;t think that the whole process is worth the hassle. Moving them to a private wallet would suffice.

I just sold all my altcoins for BTC on Binance as soon as I saw this and transferred them to gdax. Hopefully I can sell them for USD on gdax and transfer to a real bank before they get hacked.

I believe most crypto exchanges are running in the cloud. What could possibly go wrong ?

Variant 2 and Variant 3 are Intel only. They are the most concerning as they break VM space.

someone should honestly do a press release like &quot;Intel Bug not actually Intel only&quot; or give this thing a neutral name to search for.

Due to early embargo lifting, I expect not everything&#x27;s been publicized yet

<a href="https:&#x2F;&#x2F;github.com&#x2F;IAIK&#x2F;meltdown" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;IAIK&#x2F;meltdown</a> 404&#x27;s. I assume this is by intention? So full disclosure, but missing the code? Or is it somewhere else?

Again conflating the issue to include AMD. This feels so disingenuous.

Intel has released a statement for the codename Meltdown bug:<a href="https:&#x2F;&#x2F;newsroom.intel.com&#x2F;news&#x2F;intel-responds-to-security-research-findings&#x2F;" rel="nofollow">https:&#x2F;&#x2F;newsroom.intel.com&#x2F;news&#x2F;intel-responds-to-security-r...</a>

Speculative execution as a concept should not be flawed. My take is that the results of illegal speculation should never be leaked in a visable way.

Yeah I was wondering this myself. Even if there&#x27;s some fiddly hardware fix to make speculative execution secure, how much of its performance gains will we have to give up to get there?

If they could have done microcode patches they would have done, suggesting they can&#x27;t.

Only on Intel. Others restrict prefetches on permissions.I think this might even be fixed by microcode patches on Intel, at least os specific, looking at the first address bit.

So is speculative execution just inherently flawed like this, or can we expect chips in 2 years that let operating systems go back to the old TLB behavior?

Would I be correct in assuming a browser-level mitigation isn&#x27;t necessary if you&#x27;re running a patched OS?

It probably means if you want mitigations right now, you can flip that flag. Otherwise wait for Chrome to auto-update with new versions that have mitigations enabled by default.

I&#x27;m not that savvy with security so I need a little help understanding this. According to the google security blog:&gt; Google Chrome&gt; Some user or customer action needed. More information here (<a href="https:&#x2F;&#x2F;support.google.com&#x2F;faqs&#x2F;answer&#x2F;7622138#chrome" rel="nofollow">https:&#x2F;&#x2F;support.google.com&#x2F;faqs&#x2F;answer&#x2F;7622138#chrome</a>).And the &quot;here&quot; link says:&gt;Google Chrome Browser&gt;Current stable versions of Chrome include an optional feature called Site Isolation which can be enabled to provide mitigation by isolating websites into separate address spaces. Learn more about Site Isolation and how to take action to enable it.&gt;Chrome 64, due to be released on January 23, will contain mitigations to protect against exploitation.&gt;Additional mitigations are planned for future versions of Chrome. Learn more about Chrome&#x27;s response.&gt;Desktop (all platforms), Chrome 63:&gt; Full Site Isolation can be turned on by enabling a flag found at chrome:&#x2F;&#x2F;flags&#x2F;#enable-site-per-process.
&gt; Enterprise policies are available to turn on Site Isolation for all sites, or just those in a specified list. Learn more about Site Isolation by policy.Does that mean if I don&#x27;t enable this feature using chrome:&#x2F;&#x2F;flags and tell my grandma to do this complicated procedure I (or she) will be susceptible to getting our passwords stolen?

Thanks for the helpful answer. :) Things make much more sense to me now.

The cache in question is not something which stores the result of these speculatively executed instructions, but the normal L1-L2-L3 caches we are used to. The result of these instructions is discarded, but as a side effect, they may load something from memory into the cache. The exploit detects whether or not a particular memory address was loaded into the cache (reading from something already in the cache is much faster than reading from the main memory).

You arrange things so that the speculated execution loads from an address you provide (this is the target address you want to read), then uses the result of that load to calculate the address of another load (this one, into a location that aliases in the cache with an address you can load directly yourself).You can then use cache timing to see which address was read in the second load, which means you can see part of the value that was read in the first load. Rinse, repeat.The variants mostly amount to differences in how you arrange the first part (speculated execution loading from an address you get to provide).

&gt; I don&#x27;t know how they go from that to reading memory though.That was the second bit of the example source code:unsigned long index2 = ((value&amp;1)*0x100)+0x200;This creates one of two different addresses, depending upon the value of bit zero of the memory location being attacked. The two different addresses are farther apart than the size of a cache line.&gt; unsigned char value2 = arr2-&gt;data[index2];This actually does the read from one of the two different addresses (which results in the value located at one of them becoming resident in cache). Note that the value returned here is a &quot;don&#x27;t care&quot; item.Then, after everything unwinds from the speculation, the follow on code on the real path would read from both of the two possible addresses that were put into &quot;index2&quot;. The read that returns data faster must have been in cache. Knowing which one was in cache, you now know the value of bit zero of the target address location.Repeat the same block of code for bits 1-7 and you&#x27;ll have read a whole byte. Continue and you can read as much as you like. You just gather data very slowly (the article mentioned about 2000 bytes per second).

It&#x27;s a timing attack against the cache. The speculative execution might need to do a read, which means something would need to be evicted from the cache. This makes a subsequent read against that evicted adres slower.This way you can detect things based on speculative execution. I don&#x27;t know how they go from that to reading memory though.

So, basically CPUs will read instructions inside a branch even if the branch is eventually going to evaluate to false. Does the CPU do this to optimize branch instructions? The results of instructions that are executed ahead of time are stored in a cache. How exactly does this exploit read from the cache? I understand it uses timing somehow but I&#x27;m not quite sure exactly how that works. (I mostly do software.)

rightfully so:<a href="https:&#x2F;&#x2F;twitter.com&#x2F;brainsmoke&#x2F;status&#x2F;948561799875502080" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;brainsmoke&#x2F;status&#x2F;948561799875502080</a>

I do also wonder if some speculative prediction &#x2F; branching stuff can be controlled through undocumented CPU instructions: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=KrksBdWcZgQ" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=KrksBdWcZgQ</a>

Getting flashbacks of brainsmoke&#x27;s JS PoC: <a href="https:&#x2F;&#x2F;youtu.be&#x2F;ewe3-mUku94?t=1766" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;ewe3-mUku94?t=1766</a>Edit: Also, PoCs for unpatched Windows by pwnallthethings: <a href="https:&#x2F;&#x2F;github.com&#x2F;turbo&#x2F;KPTI-PoC-Collection" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;turbo&#x2F;KPTI-PoC-Collection</a>

From the article it seems that is not 100% sure AMD and ARM are not affected by metldown, only that they could not trigger the issue, but authors mention this&quot;However, for both ARM and AMD, the toy example as described in Section 3 works reliably, indicating that out-of-order execution generally occurs and instructions past illegal memory accesses are also performed.&quot;

After skimming the articles it sounds like a lot hinges on just how hard Spectre is to pull off in practice&#x2F;in the wild. Anyone have any insights on that?

&gt; Mitigation is to insert mfence instructions throughout jit generated sandboxed code making it very slow, ugh.Here&#x27;s the synchronized announcement from Chrome&#x2F;Chromium: <a href="https:&#x2F;&#x2F;sites.google.com&#x2F;a&#x2F;chromium.org&#x2F;dev&#x2F;Home&#x2F;chromium-security&#x2F;ssca" rel="nofollow">https:&#x2F;&#x2F;sites.google.com&#x2F;a&#x2F;chromium.org&#x2F;dev&#x2F;Home&#x2F;chromium-se...</a>&quot;Chrome&#x27;s JavaScript engine, V8, will include mitigations starting with Chrome 64, which will be released on or around January 23rd 2018. Future Chrome releases will include additional mitigations and hardening measures which will further reduce the impact of this class of attack. The mitigations may incur a performance penalty.&quot;Chrome 64 will be hitting stable this month, which means that it ought to be possible to benchmark the performance penalty via testing in Chrome beta. Anybody tried yet?

&quot;Spectre&quot; is very bad news and affects all modern CPUsIt&#x27;s not yet clear whether it affects all modern CPUs, notably I have yet to see any mention of modern POWER&#x2F;MIPS&#x2F;SPARC-based designs. If someone has pointers, those particular cases would probably be quite interesting.

&gt; Mitigation is to insert mfence instructions throughout jit generated sandboxed code making it very slow, ugh. Otherwise assume that the entire process with jit generated code is open to reading by that code.It seems like keeping untrusted code in a separate address space would be a suitable workaround? A lot of comments here seem to be implying that meltdown-style reading of separate address spaces is possible via Spectre, and my read is that it wouldn&#x27;t.

&quot;Meltdown&quot; is an Intel bug.&quot;Spectre&quot; is very bad news and affects all modern CPUs. Mitigation is to insert mfence instructions throughout jit generated sandboxed code making it very slow, ugh. Otherwise assume that the entire process with jit generated code is open to reading by that code.Any system which keeps data from multiple customers (or whatever) in the same process is going to be highly vulnerable.

&gt; Am I overreacting here?Still skimming the paper, but the JS attack appears to be processor-intensive (please chime in if you interpret it differently!). Any widespread, indiscriminate use of such an attack in the wild seems like it would eventually be detected as surely as client-side cryptocurrency mining was discovered. If you aren&#x27;t a valuable target, if you don&#x27;t visit sites that are shady enough to discreetly mine bitcoin in your browser, and if you use an adblocker to defang rogue advertisers, then you probably shouldn&#x27;t lose too much sleep over this (which is not intended to diminish how awesome (in the biblical sense) this attack is).That said, if there were ever a time to consider installing NoScript, now&#x27;s it: <a href="https:&#x2F;&#x2F;addons.mozilla.org&#x2F;en-US&#x2F;firefox&#x2F;addon&#x2F;noscript&#x2F;" rel="nofollow">https:&#x2F;&#x2F;addons.mozilla.org&#x2F;en-US&#x2F;firefox&#x2F;addon&#x2F;noscript&#x2F;</a>

Doesn&#x27;t each tab run in a separate process?

It seems like practical attacks rely on having a reasonably precise timer available. The spectre paper uses SharedArrayBuffer to synthesize a timer, which is a recent and obscure feature:<a href="https:&#x2F;&#x2F;groups.google.com&#x2F;a&#x2F;chromium.org&#x2F;forum&#x2F;#!topic&#x2F;blink-dev&#x2F;dnzvgTswfbc" rel="nofollow">https:&#x2F;&#x2F;groups.google.com&#x2F;a&#x2F;chromium.org&#x2F;forum&#x2F;#!topic&#x2F;blink...</a><a href="https:&#x2F;&#x2F;groups.google.com&#x2F;forum&#x2F;#!topic&#x2F;mozilla.dev.platform&#x2F;Fjh9z7Er3aA" rel="nofollow">https:&#x2F;&#x2F;groups.google.com&#x2F;forum&#x2F;#!topic&#x2F;mozilla.dev.platform...</a>Chrome and Firefox&#x27;s &quot;intent to ship&quot; posts both contain claims to the effect that there probably aren&#x27;t any really serious timing channel attacks, which... seems to have been disproved. Why isn&#x27;t SharedArrayBuffer already being disabled as a stopgap? I think users can turn it off in firefox, how about Chrome?

I think this means we should consider all browser processes to be completely insecure, until mitigations are applied (e.g. Chrome&#x27;s Site Isolation: <a href="https:&#x2F;&#x2F;www.chromium.org&#x2F;Home&#x2F;chromium-security&#x2F;ssca" rel="nofollow">https:&#x2F;&#x2F;www.chromium.org&#x2F;Home&#x2F;chromium-security&#x2F;ssca</a>).Looks like any session token&#x2F;state could be exfiltrated from your Gmail tab to a malicious JS app running in-process, for example.Am I overreacting here?

Worked on my system.(Set cache_hit_threshold to the default value of 80, my cpu is an Intel i7-6700k.)

Thanks for this.  Would love an annotated version of this if anyone is up for it.  My C is pretty good, but some high level &quot;what is being done here&quot; and &quot;this is what shouldn&#x27;t work&quot; comments would be cool to see.

Worked on a Intel(R) Celeron(R) CPU 847 @ 1.10GHz.With &quot;gcc (GCC) 7.2.1 20171128&quot;, remove the parenthesis from CACHE_HIT_THRESHOLD macro[1] to compile correctly.[1]: <a href="https:&#x2F;&#x2F;gist.github.com&#x2F;ErikAugust&#x2F;724d4a969fb2c6ae1bbd7b2a9e3d4bb6#file-spectre-c-L50" rel="nofollow">https:&#x2F;&#x2F;gist.github.com&#x2F;ErikAugust&#x2F;724d4a969fb2c6ae1bbd7b2a9...</a>

Just tested this on systems of varying age.Works on processors going back as far as 2007 (the oldest I have access to now is an Athlon 64 X2 6000+), but the example code relies on an instruction that the Atom D510 does not suport.Because Spectre seems to be an intrinsic problem with out-of-order execution, which is almost as old as the FDIV bug in intel processors, I would be very surprised if the Atom D510 did not turn out to be susceptible using other methods as outlined in the paper.EDIT: I originally suspected this instruction was CLFLUSH and erroneously claimed the D510 doesn&#x27;t support sse2. It does support sse2, so it must be that it does not support the RDTSCP instruction used for timing.EDIT: This gets very interesting. I made some modifications to use a CPUID followed by RDTSC, which now runs without illegal instructions and works everywhere the previous version worked. Except on the D510, this runs but I cannot get the leak to happen despite exploring values of CACHE_HIT_THRESHOLD. Could the Atom D510 really be immune from Spectre?

I thought it was supposed to be exploitable by javascript?  If you can get to the machine and run c code, well, that doesn&#x27;t seem like an exploit?

Works on MacOS 10.13.2.Looking back, the Mac patches were to address KPTI (Meltdown) which is separate to Spectre.

Work&#x27;s on Intel® Core™2 Duo Processor T7200. Had to replace __rdtscp(&amp;junk) with __rdtsc(), the Core 2 doesn&#x27;t have the former.

So... it reads a string that was declared at the top of the file?

Terrifyingly, this seems to work on a DigitalOcean droplet. I&#x27;m assuming this means people could potentially read memory from other VMs on the same system, albeit with a great deal of difficulty.

I&#x27;ve thrown the C code in the Spectre paper up if anyone wants to feel the magic: <a href="https:&#x2F;&#x2F;gist.github.com&#x2F;ErikAugust&#x2F;724d4a969fb2c6ae1bbd7b2a9e3d4bb6" rel="nofollow">https:&#x2F;&#x2F;gist.github.com&#x2F;ErikAugust&#x2F;724d4a969fb2c6ae1bbd7b2a9...</a>

Thanks for the links. As an undergrad with limited knowledge of this subject, I would love to see these annotated on Fermat&#x27;s Library (<a href="https:&#x2F;&#x2F;fermatslibrary.com" rel="nofollow">https:&#x2F;&#x2F;fermatslibrary.com</a>)

New CPU microcode is enough, though at a performance price. On pre-Zen AMD there is also a chicken bit to disable indirect branch prediction. (It feels good to be finally able to speak about this freely!!!)I don&#x27;t know for which processors Intel and AMD plan to release microcode updates.

This is so incredibly bad. Spectre is basically unpatchable. We can do better than we are now with patches but it&#x27;s all just turd polishing, essentially. A proper fix will require new CPU hardware. And as a kicker? Leaks are basically undetectable.

Will it be nontrivial to detect or at least identify these types of exploits as they occur in the wild? Can protection software see these when they happen, assuming a best case scenario where the attack is carried out but doesn&#x27;t specifically use these methods to hide or disable detection? Is there a general sense yet of whether this exploit is already being leveraged?

&quot;As a proof-of-concept, JavaScript code was written that, when run in the Google Chrome browser, allows JavaScript to read private memory from the process in which it runs&quot;I am not sure what &quot;the process in which it runs&quot; means here ... do they mean private memory from within chrome ? Or within the child process spawned from chrome, or within the spawned JS sandbox or ... what ?Practically speaking, I worry about a browser pageview that can read memory from my terminal process. Or from my &#x27;screen&#x27; or &#x27;sshd&#x27; process.I think that is not a risk here, yes ?

Guys, can&#x27;t we just detect a program doing spectre-like behavior and just kill it instead of having every other application suffer a performance hit by the proposed changes? Antivirus software already does similar stuff

Papers describing each attack:<a href="https:&#x2F;&#x2F;meltdownattack.com&#x2F;meltdown.pdf" rel="nofollow">https:&#x2F;&#x2F;meltdownattack.com&#x2F;meltdown.pdf</a><a href="https:&#x2F;&#x2F;spectreattack.com&#x2F;spectre.pdf" rel="nofollow">https:&#x2F;&#x2F;spectreattack.com&#x2F;spectre.pdf</a>From the spectre paper:&gt;As a proof-of-concept, JavaScript code was written
that, when run in the Google Chrome browser, allows
JavaScript to read private memory from the process
in which it runs (cf. Listing 2).Scary stuff.

I don&#x27;t think this is the last we have seen of side-channels, it&#x27;s just a ridicolously hard problem to get right. And for that reason I can&#x27;t feel too angry at the procesor makers.And I certainly expect to see more things like this (but at least hopefully with lower bandwidth).

It gives all the required context, much needed for an &quot;average&quot; engineer to understand it. Without that, most of the people, except the microchip engineers, would have to read about the related topics first anyways.
I personally was surprised at how understandably everything was explained.

The papers take a while to get to the point. I nearly fell asleep re-reading the same statements until they got to the point: speculative execution of buffer overflows.Could have been said more concisely. Sadly, this seems to be the norm with academic texts.

I dunno. Potentially. But these are incredibly complicated bugs, which involve timing at the hardware level. There&#x27;s nothing close to this in the Vault7&#x2F;8 leaks.

This is a toughie. These bugs are basically very difficult to mitigate completely without fixes at the hardware level. One might imagine the NSA being coy and patching their own OS&#x27;s et al to the degree they can while working to exploit the bug in the wild. However, the reality is that this bug is almost worse for the NSA than for most other folks, because they have the most to lose if their security is breached. And they have a lot of machines out there. The idea of a bug of this severity that leaves no traces is probably leaving a lot of people at the NSA in cold sweats right now. Meaning that if they did discover it before other researchers it&#x27;s questionable whether they would have tried to exploit it vs. driving towards the most rapid possible mitigation and fix.

If I were a betting man, I&#x27;d place my bet on them knowing about this for a long time, and possibly even being behind the bugs&#x27; introduction in the first place

Pretty close to 100%.Google zero and academia researchers found it independently, following some talk about the concept a while back.The 3 letters agencies have people of the same calibre working full time on that. They could find it too.

I&#x27;m not familiar with the intricacies of CPU design. What are the odds the NSA somehow arranged for these vulnerabilities to exist?

What are the odds that the NSA already knew about this? Roughly 100%?

First implementation I&#x27;ve seen on twitter.<a href="https:&#x2F;&#x2F;twitter.com&#x2F;pwnallthethings&#x2F;status&#x2F;948693961358667777" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;pwnallthethings&#x2F;status&#x2F;94869396135866777...</a>

Really makes the case against going to the &quot;cloud&quot; (using hosted VM solutions) versus just using colocated servers running VMWare that you fully own and administer.

However, since it seems like there is not much anyone can do to identify what is being leaked and what process did it, this does increase the risk that someone might exploit this internally and get away with it.

Since this affects legacy systems that may not be able to be upgraded it seems like this issue will be around for a very long time.It also only affects &quot;legacy systems&quot; which routinely run nontrusted code. If it&#x27;s something like e.g. a server in a bank, chances are everything running on it has already been accounted for. This isn&#x27;t like e.g. Heartbleed where you could just connect to any open server and read its memory --- you have to somehow get your code to run on it first.

So how much legal liability are they exposed to due to this security flaw?Since this affects legacy systems that may not be able to be upgraded it seems like this issue will be around for a very long time.

best for now to get your crypto coins off the exchanges if you have them there

It seems that Richard Stallman is not so paranoid after all:&gt; I am careful in how I use the Internet.&gt; I generally do not connect to web sites from my own machine, aside from a few sites I have some special relationship with. I usually fetch web pages from other sites by sending mail to a program (see <a href="https:&#x2F;&#x2F;git.savannah.gnu.org&#x2F;git&#x2F;womb&#x2F;hacks.git" rel="nofollow">https:&#x2F;&#x2F;git.savannah.gnu.org&#x2F;git&#x2F;womb&#x2F;hacks.git</a>) that fetches them, much like wget, and then mails them back to me. Then I look at them using a web browser, unless it is easy to see the text in the HTML page directly. I usually try lynx first, then a graphical browser if the page needs it (using konqueror, which won&#x27;t fetch from other sites in such a situation).Ref: <a href="https:&#x2F;&#x2F;stallman.org&#x2F;stallman-computing.html" rel="nofollow">https:&#x2F;&#x2F;stallman.org&#x2F;stallman-computing.html</a>

Text and patch start here: <a href="https:&#x2F;&#x2F;lkml.org&#x2F;lkml&#x2F;2018&#x2F;1&#x2F;3&#x2F;780" rel="nofollow">https:&#x2F;&#x2F;lkml.org&#x2F;lkml&#x2F;2018&#x2F;1&#x2F;3&#x2F;780</a>Also, see Linus&#x27; response here: <a href="https:&#x2F;&#x2F;lkml.org&#x2F;lkml&#x2F;2018&#x2F;1&#x2F;3&#x2F;797" rel="nofollow">https:&#x2F;&#x2F;lkml.org&#x2F;lkml&#x2F;2018&#x2F;1&#x2F;3&#x2F;797</a>

From a recently posted patch set:Subject: Avoid speculative indirect calls in kernelAny speculative indirect calls in the kernel can be tricked
to execute any kernel code, which may allow side channel
attacks that can leak arbitrary kernel data.So we want to avoid speculative indirect calls in the kernel.There&#x27;s a special code sequence called a retpoline that can
do indirect calls without speculation. We use a new compiler
option -mindirect-branch=thunk-extern (gcc patch will be released
separately) to recompile the kernel with this new sequence.We also patch all the assembler code in the kernel to use
the new sequence.

What I understand is that the hypervisor of GCE has been patched already and so some customer running on the same machine as you can&#x27;t exploit you. However if you are running KVM or something yourself on a Cloud instance (vm in a VM) then you should patch that.

I wonder what this sentence in the Google product status page (<a href="https:&#x2F;&#x2F;support.google.com&#x2F;faqs&#x2F;answer&#x2F;7622138" rel="nofollow">https:&#x2F;&#x2F;support.google.com&#x2F;faqs&#x2F;answer&#x2F;7622138</a>) means, particularly what the inter-guest attack refers to:&quot;Compute Engine customers must update their virtual machine operating systems and applications so that their virtual machines are protected from intra-guest attacks and inter-guest attacks that exploit application-level vulnerabilities&quot;

I know it was scheduled but the information on the links are public and prior to the scheduled disclosure. A hacker could figure out the problem by reading the available information before the Google Project Zero.

No. This was all scheduled to be released on January 9th, but the release was sped up after people started connecting dots.We are posting before an originally coordinated disclosure date of January 9, 2018 because of existing public reports and growing speculation in the press and security research community about the issue, which raises the risk of exploitation.<a href="https:&#x2F;&#x2F;security.googleblog.com&#x2F;2018&#x2F;01&#x2F;todays-cpu-vulnerability-what-you-need.html" rel="nofollow">https:&#x2F;&#x2F;security.googleblog.com&#x2F;2018&#x2F;01&#x2F;todays-cpu-vulnerabi...</a>

Looks like the information was somewhat public available since middle of the last year on <a href="https:&#x2F;&#x2F;cyber.wtf&#x2F;2017&#x2F;07&#x2F;28&#x2F;negative-result-reading-kernel-memory-from-user-mode&#x2F;" rel="nofollow">https:&#x2F;&#x2F;cyber.wtf&#x2F;2017&#x2F;07&#x2F;28&#x2F;negative-result-reading-kernel-...</a> and <a href="http:&#x2F;&#x2F;www.cs.binghamton.edu&#x2F;%7Edima&#x2F;micro16.pdf" rel="nofollow">http:&#x2F;&#x2F;www.cs.binghamton.edu&#x2F;%7Edima&#x2F;micro16.pdf</a>. Also similar methods from 2013 paper <a href="http:&#x2F;&#x2F;www.ieee-security.org&#x2F;TC&#x2F;SP2013&#x2F;papers&#x2F;4977a191.pdf" rel="nofollow">http:&#x2F;&#x2F;www.ieee-security.org&#x2F;TC&#x2F;SP2013&#x2F;papers&#x2F;4977a191.pdf</a> (timing side channel attacks).Any reason for the panic now? Any know malware using it?

Reading privileged memory with a side-channel