3 ms·
It's not just untrusted code, it's all code. "Trusted code" is one exploit away from being untrusted code. And solving that requires not accepting untrusted in
by Klathmon 9y ago
It's not just untrusted code, it's all code.
"Trusted code" is one exploit away from being untrusted code. And solving that requires not accepting untrusted input, which makes most general purpose computing useless.
Has there been any research into solving this problem at the hardware level? I'm imagining something like having hundreds or thousands of distinct processors on a PC all isolated each running only one process.
It sounds extreme, but over time I've basically learned to treat "optimization" as a synonym for "introduces side channel attacks", and without something that can protect against a large majority of these kinds of exploits, computers are only going to get less secure.
- TrevorJ 9y agoEven with distinct processors, there would still be something in charge of who gets to use what hardware resource. I suspect that would be where the attack vector would shift.
- Klathmon 9y agoAt least some of those resources can only deal with encrypted data to reduce the amount of leakage to acceptable levels. Or maybe we can contain the problem by having a kernel that manages access to all resources, but keeps individual processes on nearly separate hardware. As you can probably tell, I have no idea what I'm talking about here, but the more of these big side channel attacks that come out, the more I'm feeling that there is no way to securely share a machine among multiple processes without just giving up and letting them all have access to one another.