A security research blog covering CPU side channel attacks, malware analysis such as Emotet and QakBot, and vulnerabilities in commercial software.
HN links its July 2017 negative-result post as early work on reading kernel memory, cited in discussions about who found Spectre and Meltdown first.
This happens all the time. In this particular case, speculative execution timing attacks were "in the air" for the last year. A little while ago the C.W. was that Anders Fogh had kicked this off with his blog post from last summer, but Fogh actually posted a chronology taking this work all the way back to December '16:
https://cyber.wtf/2018/01/05/behind-the-scene-of-a-bug-collision/
Once there's blood in the water, people race to find exploitable flaws (that's the goal of the game), and so it's not surprising that you'd get multiple teams disclosing, especially with something this egregious. Also: there's a Nyquist Frequency thing happening here: remember that we're dealing with months-long embargoes. So there's a lot of time for people to have found these bugs "separately", and all we're really seeing is a colliding disclosure.
But having said all that: straight-up collisions happen a lot. We all have favorite stories. My favorite is when Vitaly McLain (then at Matasano, now one of my partners at Latacora) found an nginx bug that was identical to Heartbleed, 2 years before Heartbleed was disclosed. A fantastic bug. We were on a client engagement, so we had to coordinate with the client before reporting it upstream, and in the one hour it took to do that, someone else reported the same bug.
I'm trying to understand the timeline of everything that is going on.
https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-from-user-mode/ was published on 2017-07-28.
The pythonsweetness.tumblr.com post talks about patches being first posted in October (anyone have a link to the first public patch?).
https://lwn.net/Articles/738975/ was published on 2017-11-15.
https://lwn.net/SubscriberLink/741878/5c019c71457e0da6/ was published on 2017-12-20.
https://lkml.org/lkml/2017/12/27/2 was published on 2017-12-27.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5aa90a84589282b87666f92b6c3c917c8080a9bf shows that Linus merged the patches on 2017-12-30.
https://lwn.net/Articles/742404/ was published on 2017-12-30.
http://pythonsweetness.tumblr.com/post/169166980422/the-mysterious-case-of-the-linux-page-table, which was the post that grabbed everyone's attention, was published on 2018-01-01.
Was the blog post on 2017-07-28 talking about the same vulnerability that has the world on fire today, or are there multiple issues going on?
Was the connection with speculative execution already being discussed openly? I know about https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-from-user-mode/, but not about anything between that and 28 Dec suggesting someone made it work and that's the reason for KPTI.
If it wasn't in the open, seems...not ideal embargo-wise for AMD to leak it there. Though no one's in that thread complaining about the disclosure, so maybe they either think that part is already known to anyone looking closely, or just don't think it's a very big piece of the exploit puzzle (like, finding the way to get info out a side channel was the hard part).
I thought that:
mov rax, [Somekerneladdress]
would trigger an interrupt even on speculative execution as described on https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-from-user-mode/
ADDED: So in the interrupt handler the kernel could evict all user space pages from cache before returning control to user space so it could not use the timing attack on the cache of the speculative execution of Mov rbx,[rax+Someusermodeaddress] on the address rax+Someusermodeaddress.
> Everything else was not seen as practically exploitable.
For a concrete blog post, see https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-from-user-mode/
Note that according to https://en.wikipedia.org/w/index.php?title=Spectre_(security_vulnerability)&oldid=962289953 Spectre was published January 2018, i.e. this blog post is indeed older.
As I wrote: It was unclear how this potential threat could be used to create real attacks.
Yeah, the blog post says they knew since June 2017, with that blog post being from July.
> This initial report did not contain any information about variant 3. We had discussed whether direct reads from kernel memory could work, but thought that it was unlikely. We later tested and reported variant 3 prior to the publication of Anders Fogh's work at https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-from-user-mode/.