The computer security vulnerabilities Meltdown and Spectre can infer protected information based on subtle differences in hardware behavior. It takes less time to access data that has been cached versus data that needs to be retrieved from memory, and precisely measuring time difference is a critical part of these attacks.
Web browsers can’t change processor cache behavior, but they could take away malicious code’s ability to exploit them. Browser makers are intentionally degrading time measurement capability in the API to make attacks more difficult. These changes are being rolled out for Google Chrome, Mozilla Firefox, Microsoft Edge and Internet Explorer. Apple has announced Safari updates in the near future that is likely to follow suit.
After these changes, the time stamp returned by performance.now will be less precise due to lower resolution. Some browsers are going a step further and degrade the accuracy by adding a random jitter. There will also be degradation or outright disabling of other features that can be used to infer data, such as SharedArrayBuffer.
These changes will have no impact for vast majority of users. The performance API are used by developers to debug sluggish code, the actual run speed is unaffected. Other features like SharedArrayBuffer are relatively new and their absence would go largely unnoticed. Unfortunately, web developers will have a harder time tracking down slow code under these changes.
Browser makers are calling this a temporary measure for now, but we won’t be surprised if they become permanent. It is a relatively simple change that blunts the immediate impact of Meltdown/Spectre and it would also mitigate yet-to-be-discovered timing attacks of the future. If browser makers offer a “debug mode” to restore high precision timers, developers could activate it just for their performance tuning work and everyone should be happy.
Benchmarks often get criticized for their inability to perfectly model the real-world situations that we’d like them to. So take what follows in the limited scope that it’s intended, and don’t read too much into it. [Joonas Pihlajamaa]’s experiments with toggling a hardware pin as fast as possible on different single-board computers can still show us something.
The take-home result won’t surprise anyone who’s worked with a single-board computer: the higher-level interfaces are simply slow compared to direct memory-mapped GPIO access. But really slow. We’re talking around 5 kHz from Python or any of the file-based interfaces to the pins versus 3 MHz for direct access. Worse, as you’d expect when a non-realtime operating system is in the middle, there are glitches on the order of ten milliseconds with all the file-based methods.
This test only tells us so much, though, and it’s not really taking advantage of the BeagleBone Black’s ace in the hole, the PRUs — onboard hardware processors that bring real-time IO capabilities to the system. We’d like to see a re-write of the code to take advantage of libpruio, for instance. A 20 MHz square wave is a piece of cake with the PRUs.
Of course, it’s not interacting, which is probably in the spirit of the benchmark as written. But if raw hardware speed on a BeagleBone is the goal, it’s likely that the PRUs are going to feature prominently in the solution.
The Raspberry Pi has only been available for a few days, but already those boards are heading through the post office and onto workbenches around the world. From the initial impressions, we already know this quad-core ARMv7 system boots in about half the time, but other than that, there aren’t many real benchmarks that compare the new Raspberry Pi 2 to the older Raspi 1 or other similar tiny Linux dev boards. This is the post that fixes that.
A word of warning, though: these are benchmarks, and benchmarks aren’t real-world use cases. However, we can glean a little bit of information about the true performance of the Raspberry Pi 2 with a few simple tools.
AppleDifferent decided to run some benchmarks on their MSI Wind hackintosh to see how it stacked up to real Apple hardware. It comes in under the MacBook Air in most cases and they conclude that it performs about as well as a four year old G4. Being so small and inexpensive, you can’t really expect much better. As a counterpoint, Obsessable posted a video demoing just how slow a first generation Eee PC can be (embedded below). Boing Boing Gadgets is maintaining an OSX netbook compatibility chart. It shows that the MSI Wind is probably the best case for OSX usability. If we were buying today, we’d probably pick up a Dell Mini 9 even though it requires an SSD upgrade before it will sleep properly.
Are any of you running OSX as the primary OS on your netbooks? What has your experience been?
Christmas has come early for us. This is our 3,000th post since launching Fall of 2004 doing just one post a day. The outstanding stat though is the 50,000 comments in the system. The team at Hack a Day would like to thank you, the readers, for bringing in all of our best tips and being part of this great community.