Meltdown strikes back: the L1 terminal fault vulnerability | Hacker News Reader

Meltdown strikes back: the L1 terminal fault vulnerability

lwn.net

95 pointsingve10 comments

I've lost count of all the side-channels that have been discovered since Meltdown/Spectre, and to be honest, I quite frankly really don't care any more than I did before... I don't run untrusted code (yes, that includes JavaScript) and I'm the only user of my PC. Since Intel first introduced "protected" mode in the 286 I've felt the notion that it was only intended for protection against accidental errors, not deliberate maliciousness. From that perspective, all this "side-channel hide-and-seek" seems like an exercise in futility to add a level of security to something that was inherently not designed for such.

Since this attack goes directly to a physical address, it can in theory read any memory in the system. Notably, that includes data kept within an SGX encrypted enclave, which is supposed to be protected from this kind of thing.

Maybe one of the more positive things to come of this mess... and proof that DRM-enabling technologies will(should?) always be broken by design.

"From that perspective, all this "side-channel hide-and-seek" seems like an exercise in futility to add a level of security to something that was inherently not designed for such."

It seems that this SGX thing was designed for such. That's what makes this new attack notable.

Make no mistake, SGX was designed to give Intel control over what code its processors can run (they have the signing key), and to enable user-hostile DRM. Attacks against it are welcome in the same way as jailbreaks and rooting.

Let's be precise; that Intel is enforcing enclave Launch Control is orthogonal to the SGX mechanism itself. Launch Control is a bane to end-users, like you said, and a pain to enclave creators (I had to talk to some random business development employee at Intel..) Intel has even specified a system for users to use their own Launch Control (or disable it) but that is not implemented in any actual chips.

> I don't run untrusted code (yes, that includes JavaScript)

It's great that you are so security minded, but do you honestly think every single layperson using a computer ought to never run any untrusted code again, not even javascript? You don't think that that philosophy would set back the state of personal computing a bit?

You don't run untrusted code at all? I'd be very interested in hearing how you establish trust in all the code running on your system, as that seems quite a difficult task for most modern Operating system/application stacks.

I don't think any of these attacks really have much of an impact on your PC. However, there are many public cloud servers which do run untrusted code on the same hardware as your code, or others' code that manipulates your data.