Google Publishes "Leaky.Page" Showing Spectre In Action Within Web Browsers

[microcode]

I'll stick to Firefox.

What about Firefox helps with this?

[DRanged]

What about Firefox helps with this?

It seems not to work on leaky.pages

[microcode]

It seems not to work on leaky.pages

Yeah I think it's just missing some work on supporting Firefox, looking at the L1 timer part of the process, it seems like something goes wrong there. Seems to me that it's not that the sidechannel isn't there, just that the demo isn't configured for a slight difference in how it is exposed.

[Guest]

Someone should show this to those idiotic Apple fans who keep beating their chests and shouting about how their CPU is bigger than anyone else's. God fanbases are annoying.

[deusexmachina]

If someone wonders why the exploit demo page works in spite of mitigations enabled:

Spectre V1 is so-far mitigated only in software. In this case, the software is the web browser. The browser mitigates the vulnerability by enforcing a barrier between insecure javascript sandbox and the rest of the browser. However, this demo uses Spectre V1 to access data which is within the sandbox, not outside it. Meaning, the demo already has sufficient privileges to read leaked data in a usual way , but this demo additionally shows that this data is also readable using Spectre V1. Since the leaked data is a data from the sandbox, the browser doesn't complain.

Of course, in this case there is no breach of privileges, but it is still a demonstation of reading data using Spectre V1.



Wrong. Out-of-order execution is a major contributor to performance, but speculative execution isn't so much, it's just a gain of about 15% for speculative execution.

To make a hardware mitigation for Spectre v1 (and v4, too!), a CPU designer has the following choices:
1. Disable speculative execution, take a 15% performance hit.
2. Disable speculation on loads and stores, take about 7% performance hit.
3. Redesign the L1 cache to be speculation-aware. Takes 3% performance hit and 20% additional transistors in L1. Some engineering effort reqired.

So far, the CPU designers have opted for this option:
4. Don't mitigate, let it be solved by software. About 3% performance hit. Requires recompilation of current software, lots of work from software developers, and additional caution on the side of programmer for every new piece of software written that employs privilege boudaries.

P.S. Let me not surprise you: we live in a fucked-up world.

So I guess that explains why this works on my Ryzen running the latest (semi-hardened) Linux kernel! Jeez...

[deusexmachina]

Since people seem to like that post of mine, here is some more info (I'm an amateur CPU designer).

No DM'ing on this forum, so let me ask something that isn't so far off topic here... How hard would it be to reverse engineer modern AMD CPUs to the degree that we can have verified boot on them? Can we reverse engineer away the potential backdoors in these "management engines"?

Perhaps they're in no hurry to fix these minor issues when because they put major backdoors in all of their CPUs on purpose (in return for governmental, regulatory, or financial favors, of course)? Anyone replying with the "conspiracy theory" line is committing a logical fallacy and I will not allow them to waste my time.

[deusexmachina]

As far as I know, "verified boot" would be virtually impossible. The problem is that for a verified boot you need a high level of certainty. But, a modern CPU contains billions of transistors, and there is practically no way to figure out, in sufficient detail, how are the transistors connected.

For a back-door, you would only need perhaps a few thousand transistors, maybe tans of thousands.

For "verified boot", you really need an open source architecture, with implementation schematic available and a silicon fab that you trust not to have modified the design.

Thanks... That does sound like the general consensus. But why can't a brute force method be used? Can't certainty be gained that way? I realize custom hardware might need to be made in order for the reverse engineering to get done - but once it is done it opens up countless high performance CPUs for the next 5+ years - so at least we can use top end gear safely until RISC-V's or Power10 are more mature...

[deusexmachina]

How far can these CPUs be underclocked xfcemint ?
Can't we "just":
1) make a CPU socket built to collect data as the CPU bootstraps itself
2) figure out how to write open source code which boots it as closely to the closed firmware as possible
3) then just attack get researchers to start using that new open firmware, attack it, and eventually it will be as secure as the original closed firmware?

I realize there's plenty of magic between step 1 & 2, but I need some back & forth to build the idea and use the correct language to communicate it... Which is where an amateur CPU designer comes in

[deusexmachina]

Oh, and also, the problem is not in the firmware, the problem is if a CPU has an undiscovered security-related bug. Such a bug can easily make the firmware insecure / hackable.

Of course, this gets much worse if big parts of a CPU are undocumented, such as Intel ME / AMD PSP. The ME is worse because it is a multithreaded kernel, PSP is simpler, so less problems, but still a big problem.

Sigh... Has anyone been able to verify if the PSP is network accessible yet? I suppose that could potentially be very hard to verify too.