How we got to #Spectre and #Meltdown A Timeline

My version of the timeline on #Spectre #Meltdown. This post will be updated! If you want to add/correct something, please comment.

I’m merely listing events I think are relevant. I’m not trying to tell a specific story nor am I trying to create a specific narrative. Just the events, chronologically listed.

NOTE This timeline stops on 2018-01-03, the day Google went public with it. I’m mainly interested in what happened BEFORE.

The post from Greg Kroah-Hartman is the obvious exception because it is extremely relevant in understanding how the Linux kernel community acted.

2016-08-04
Anders Fogh and Daniel Gruss present “Using Undocumented CPU Behavior to See Into Kernel Mode and Break KASLR in the Process” at the Blackhat conference. [16]

2016-08-10
Moritz Lipp et al (Graz University) publish “ARMageddon: Cache Attacks on Mobile Devices” in the proceedings of the 25th USENIX security symposium. Even though focused on ARM, it lays the groundwork for the attack vector. [15]

2016-12-27
At #33C3 Clémentine Maurice and Moritz Lipp (Graz University) present their talk “What could possibly go wrong with <insert x86 instruction here>?
Side effects include side-channel attacks and bypassing kernel ASLR” which outlines already what is coming. [11]

2017-02-01
The CVE numbers 2017-5715, 2017-5753 and 2017-5754 are assigned to/reserved by Intel. (I guess they asked for being assigned a range).

2017-02-27
Bosman et al (Vrije Universiteit Amsterdam) publish their findings how ASLR can be abused on cachebased architectures at the NDSS Symposium. [5]

Some time before June, 2017
The two attack vectors, now combined as #Spectre, are independently found by Google’s Project Zero researchers and researchers from the academic world. [1]

2017-06-01
The findings are shared with Intel, AMD and ARM. [1] footnote 1

2017-06-24
Daniel Grass et al (Graz University) publish “KASLR is Dead: Long Live KASLR” which introduces the KAISER patchset that will later become KPTI [10]

Some time before 2017-07-28
#Meltdown attack vector is identified and shared with Intel (also AMD, ARM?) (by the same group?) [1] footnote 1

2017-07-28
Anders Fogh publishes his #Meltdown findings (found independently?) called “Negative Result: Reading Kernel Memory From User Mode” [3]

Around 2017-09
Google deploys fixes in their Linux based infrastructure to protect their customers according to [18], using patches they propose to Linux upstream as #retpoline only after the public disclosure of Spectre/Meltdown on 2018-01-03.

2017-10-30
Intel CEO Brian Krzanich files trading instructions compliant with Rule 10b5-1(c) to sell 890,000 shares on 2017-11-29. [12]

2017-11-09
Intel informs partners and other interested parties under NDA. [2]

2017-11-15
Jonathan Corbet notes on LWN.net that the KAISER patchset seems to get fast tracked into the kernel. He specifically notes that “There are rumors circulating that other such channels exist but have not yet been disclosed.” [9]

2017-11-20
The CRD (Coordinated Release Date) is agreed upon to be 2018-01-09 by many parties involved. [2]

2017-11-29
Intel CEO Brian Krzanich sells 890,000 Intel shares, resulting in $39M [12]

2017-12-13
Apple releases iOS 11.2, MacOS 10.13.2 and TVos 11.2. These update contain fixes for #Meltdown but that is not mentioned in the release notes. Apple explains this in [13], published 2018-01-05

2017-12-15
Amazon starts sending emails to AWS customers, informing them of a scheduled reboot of EC2 instances on or around the 6th of January 2018. People that reboot following that email notice degraded performance and start discussing this in [17]

2017-12-20
Jonathan Corbet publishes an article called “The current state of kernel page-table isolation” and remarks that the KPTI patches have “all the markings of a security patch being readied under pressure from a deadline. Just in case there are any smug ARM-based readers out there, it's worth noting that there is an equivalent patch set for arm64 in the works.” [8]

2018-01-01
The sweetpython post appears, speculating about what’s behind the KPTI patches for the Linux kernel. [4]

2018-01-02
The Register publishes an article titled “Kernel-memory-leaking Intel processor design flaw forces Linux, Windows redesign” that puts enough of the information together. [6]

2018-01-03
Bosman posts on Twitter about a working reproducer for #Meltdown [7]

Google breaks the agreed CRD and makes everything public. Amazon, Google, Microsoft declare their respective clouds are patched and safe.

2018-01-06
Greg Kroah-Hartman publishes “Meltdown and Spectre Linux Kernel Status” on his blog which hints at quite some discussions (to put it friendly) behind the curtains. [14]

Sources:

[1] https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html

[2] https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown

[3] https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-from-user-mode/

[4] http://pythonsweetness.tumblr.com/post/169166980422/the-mysterious-case-of-the-linux-page-table

[5] https://www.ndss-symposium.org/ndss2017/ndss-2017-programme/aslrcache-practical-cache-attacks-mmu/

[6] https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/

[7] https://mobile.twitter.com/brainsmoke/status/948561799875502080

[8] https://lwn.net/Articles/741878/

[9] https://lwn.net/Articles/738975/

[10] https://gruss.cc/files/kaiser.pdf

[11] https://media.ccc.de/v/33c3-8044-what_could_possibly_go_wrong_with_insert_x86_instruction_here

[12] ‪https://www.sec.gov/Archives/edgar/data/50863/000112760217033679/xslF345X03/form4.xml

[13] https://support.apple.com/en-us/HT208394

[14] http://kroah.com/log/blog/2018/01/06/meltdown-status

[15] https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_lipp.pdf

[16] https://www.blackhat.com/us-16/briefings.html#anders-fogh and https://m.youtube.com/watch?v=Pwq0vv4X7m4

[17] https://forums.aws.amazon.com/thread.jspa?threadID=269858

[18] https://www.blog.google/topics/google-cloud/protecting-our-google-cloud-customers-new-vulnerabilities-without-impacting-performance
Shared publiclyView activity