Hacker News Reader

Comment by throwaway81523 | Hacker News Reader

Someday we will learn that allowing adversaries to run code on our computers will always create leaks. In the old days whenever a new exploit was discovered, advisories would go out telling people to disable Javascript in their browsers. Now JS can no longer be disabled, and way too many sites rely on it unnecessarily, so we are stuck. Oops.

View on HN

Our business has windows. Someone drove up, kicked in a window, stole some things and left. I keep trying to tell people to tear all their windows out, but I guess people think they add value to their home and so now we're stuck. Oops.

What we actually did was add "glass break sensors" to our security system.

You can also install glass that is 'vandal proof', with a plastic layer. It'll slow down whoever is trying to smash it enough until the police show up.

3M sell a range of security film for after market application. Also IR/UV blocking films. Former external latter internal. Worth looking at the energy savings because which can be significant depending on your local climate. Variants provide internal reflection suppression and tints which might make it attractive to executive pursors. The (public SKU) electrically conductive window film was discontinued unfortunately..

The difference now is we made it easier for people to break everyone’s windows at scale and take what they want from another country with unfriendly extradition rules.

Oops.

No, we just need deterministic processing capabilities for untrusted code. So, no caches, no speculation, guaranteed cycles and memory bandwidth.

It will be dog slow, but it can't leak the behaviour of other components on the system.

Today's Javascript crowd has an even more insatiable appetite for cpu cycles than Microsoft Word did in the early 2000's. A 50x slowdown would do some good, I suppose, but there are also the many software escapes that keep occurring. "Trusted" execution environments have failed repeatedly in the past too. Remember SGX? I don't remember what went wrong with it but it wasn't timing related afair.

Wikipedia shows a spate of speculative execution/timing-based attacks against SGX, as recent as 2020. something like 10 different attacks.

business-wise, I think Intel's decision to gatekeep SGX and require developers to buy licenses to get signing keys probably doomed it, along with how weird and arcane it was to develop for. but the security was not good.

SGX is out there and being used. It's actually the solution to these problems, ultimately, because Intel CPUs are highly patchable via microcode and when you set up an enclave you're effectively opting in to better security for lower performance. For instance, a lot of the early attacks were blocked simply by making the CPU flush its state when entering or exiting an enclave. Intel could do that because an enclave is meant to be hardened, whereas other sorts of mitigations at e.g. syscall boundaries hit tough performance/security tradeoffs that are very different in different contexts.

Also, I'll say, having read a lot of SGX related research papers that many of the attacks were not really practical on close examination, or were immediately patched. The researchers don't tend to mention these things but e.g. using ancient crypto libraries without any side channel mitigations is rather common in that field.

For things like this, it'd probably make sense to use SGX more in the Linux kernel for holding secrets and doing other things. A lot of stuff in the kernel isn't really read sensitive (modulo generic secrets like KASLR slides). Having secrets like root hashes hanging around in kernel memory isn't a good idea but where to put them? One solution is to move stuff into enclaves. Unfortunately it would only help on server platforms.

Reply on news.ycombinator.com