Python Sweetness

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?

See the three-year warranty here for boxed CPUs:
https://www.intel.com/content/dam/support/us/en/documents/processors/Limited_Warranty_8.5x11_for_Web_English.pdf

Note the first bullet under "WHAT THIS LIMITED WARRANTY DOES NOT COVER":

"design defects or errors in the Product (Errata). Contact Intel for information on characterized errata."

Guess we're not covered on this one.

EDIT: That being said, given the potential scope of this issue (years of affected CPUs, massive PR hit) I'm hoping that Intel will at least offer some remedy to recent buyers. According to the article from The Register [1], OS vendors have been working on the fix since November. The blog posted over on pythonsweetness [2] posits the bug may have been identified in October. It'd be interesting to know for how long Intel has been selling Coffee Lake CPUs that are known to be vulnerable.

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

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

Seccomp might be a possibility here, but will require one process per live robot (and Linux). With seccomp your process can do nothing but read/write from its file descriptors (so you have to make sure they are safe) but can do nothing more (thus you cannot import modules). So you can exchange messages via file descriptors and otherwise use any Python (or even any other language at all features). Here's one recent article about it: http://pythonsweetness.tumblr.com/post/65442885019/secure-low-overhead-eval-sandbox-in-80-lines-of-python

RestrictedPython, used in zope, is nice too. However it cuts you out of many Python features that it cannot statically validate.

While I agree with your point (and often use this in interview questions) that wasn't what caused the Knight Capital problem.

That was bad software engineering and deployment practices, and had nothing to do with interprability of the model (actually it had little to do with the model at all.) They repurposed a feature toggle, then misdeployed the code: http://pythonsweetness.tumblr.com/post/64740079543/how-to-lose-172222-a-second-for-45-minutes

I understand that this was an example, but I'm sure someone will misread it as what happened in that case.