3 ms·
this is not unknown. this appears to be an attempt to exploit AI39, which has been known for the last five years http://kerneltrap.org/mailarchive/openbsd-misc/
by munin 14y ago
this is not unknown. this appears to be an attempt to exploit AI39, which has been known for the last five years http://kerneltrap.org/mailarchive/openbsd-misc/2007/8/8/153144/thread http://kerneltrap.org/mailarchive/openbsd-misc/2007/8/8/1531...
and if you want to read the actual bug in Intel documentation, it is here: ftp://download.intel.com/design/processor/specupdt/313279.pdf
- duskwuff 14y agoAI39 is apparently "Cache Data Access Request from One Core Hitting a Modified Line in the L1 Data Cache of the Other Core May Cause Unpredictable System Behavior". But Javascript isn't multithreaded, so I'm not sure how the author claims to be tickling this bug. (Their commented-out "THREATED[sic] IMPLEMENTATION" doesn't invoke any form of multiprocessing. In fact, it doesn't do anything at all.) Additionally, AI39 doesn't even affect any of the CPUs they tested on! It affected some early Conroe steppings, but the Core2 (T5750) they tested on was Merom, released several years later, and the Atom is a completely different µarch altogether.
- Someone 14y agoI haven't looked at the page at all and the Intel PDF I could find wasn't too informative for me, but the reasoning could be that there are other processes running on the CPU. If 'hitting a modified line' means 'requesting an address that would be mapped to the same cache line in the other core' and not 'requesting an address that is in the cache of the other core', this approach would be viable [However, if that is the case, there have to be other conditions involved, as it cannot be that simple, as without them, it would be so easy to hit this problem that Intel would have detected it before selling one of these]