4 ms·
this is actually a really interesting problem i've been pondering quite a bit recently. what would it actually take to get to actually secure computing assuming
by a-dub 5y ago
this is actually a really interesting problem i've been pondering quite a bit recently. what would it actually take to get to actually secure computing assuming one was able to start with a clean slate? it seems like getting away from memory unsafe languages is a pre-requisite, but beyond that... how do you build a computer system with thousands of pieces of software authored by different people with thousands of inputs that are controlled by different entities that produces output you can really trust, and verify... like not tamper resistant, but actually tamper proof with verifiable outputs. and well, also not a huge step back in performance and usability.
in reality, maybe something like this that builds on existing primitives to get there may be the only real, feasible thing... but assuming you could start from scratch, what would it look like?
- fsflover 5y ago> what would it actually take to get to actually secure computing assuming one was able to start with a clean slate? > getting away from memory unsafe languages How about secure virtualization and security through isolation instead? See Qubes OS.
- a-dub 5y ago> How about secure virtualization and security through isolation instead? See Qubes OS. yeah, that's kinda what i meant by "something like this that builds on existing primitives to get there may be the only real, feasible thing". it looks like qubes uses vms as an existing (heavyweight) primitive to limit blast radii for existing software and systems. i wonder if you can do better if you start from scratch.
- fsflover 5y ago> existing (heavyweight) It's not exactly heavyweight, because Xen hardware virtualization eats up only additional 10% of CPU. However, GPU acceleration is switched off for security reasons.