4 ms·

It's been done: http://www.crash-safe.org/papers.html http://www.crash-safe.org/papers.html https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ https://ww

It's been done: http://www.crash-safe.org/papers.html http://www.crash-safe.org/papers.html https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ The latter runs FreeBSD on a FPGA. There's others that use crypto to do similar things with sealed RAM. What we need isn't tech to be invented so much as solutions to be funded and/or bought. Neither most suppliers or demand side want to make sacrifices necessary to get the ball rolling. Most prototypes are done at a loss by CompSci people. There's a few niche companies doing it commercially. High-assurance security w/ hardware additions is popular in smartcard market for example. Rockwell-Collins does it in defense with AAMP7G processor but you bet really low volume in orders. Price goes up as a result.

dreamcompiler 9y ago
This. We know how to build secure systems, but VCs won't fund the effort unless there's profit to be made and existing software will run on it. That second criterion especially means you're going to have to dumb down either your security or your performance to the point that there's no real value added. I've come to the conclusion that the only realistic approach to security is to begin a slow, methodical replacement of every line of C code in the Linux kernel with Rust. No VC is going to pay for that, so some other funding mechanism will be required.
- pjmlp 9y ago
  Not only Rust, but every native compiled memory safe language is a good alternative to replace user space applications, specially if they aren't dependent on the usual C memory pointer optimization tricks for their use case. Hence why you will see my schizophrenic posts regarding Go, although I dislike some of the design decisions, every userspace application written in Go is one application less written in C. And if bare metal approaches like GERT[0] take off even better. [0] - https://github.com/ycoroneos/G.E.R.T https://github.com/ycoroneos/G.E.R.T
catern 9y ago
"It's been done" and "What we need isn't tech to be invented so much as solutions to be funded and/or bought." are somewhat dismissive overstatements. If we had a way to implement a capability-secure runtime on Linux on Intel CPUs, in a way that improved performance rather than making it worse, and was straightforwardly usable with existing programs, then we could make a ton of progress and easily be commercially successful. But that is technologically difficult. Maybe we can still figure it out, though. Or maybe we just need to figure out the right trade-offs to get something viable out the door and widely used.
- pjmlp 9y ago
  Intel had an wonderful processor for that, iAPX 432, and they botched it. Every time I read about it I wonder how things would have turned out, if they managed to do a proper job with the CPU.
  - nickpsecurity 9y ago
    Don't forget i960 which had some of 432's fundamental protections with decent performance. It was used later in high-end embedded market. https://en.wikipedia.org/wiki/Intel_i960 https://en.wikipedia.org/wiki/Intel_i960
- nickpsecurity 9y ago
  "in a way that improved performance rather than making it worse" This part is not realistic if it's apples to apples. Performance will always drop because the high performance came specifically by doing unsafe things that enable attackers. Adding checks or restrictions slows it down. The question is whether it can be done without slowing things down too much. I'm hopeful about this given many people are comfortably using their PC's and the net on 8-year old PC's w/ Core Duo 2's that still run pretty well. That was 65nm tech. Matching it or at least a smartphone is what I'd aim at for first run.
  - catern 9y ago
    >Performance will always drop because the high performance came specifically by doing unsafe things that enable attackers. No, this is not true. Strong static typing and other compile-time information can (at least theoretically) allow improving both security and performance. For example, look at single address space operating systems. Switching between security domains is cheaper when you don't have to switch address spaces. That's an improvement to security that allows increased efficiency.

dreamcompiler 9y ago

This. We know how to build secure systems, but VCs won't fund the effort unless there's profit to be made and existing software will run on it. That second criterion especially means you're going to have to dumb down either your security or your performance to the point that there's no real value added. I've come to the conclusion that the only realistic approach to security is to begin a slow, methodical replacement of every line of C code in the Linux kernel with Rust. No VC is going to pay for that, so some other funding mechanism will be required.

pjmlp 9y ago
Not only Rust, but every native compiled memory safe language is a good alternative to replace user space applications, specially if they aren't dependent on the usual C memory pointer optimization tricks for their use case. Hence why you will see my schizophrenic posts regarding Go, although I dislike some of the design decisions, every userspace application written in Go is one application less written in C. And if bare metal approaches like GERT[0] take off even better. [0] - https://github.com/ycoroneos/G.E.R.T https://github.com/ycoroneos/G.E.R.T

catern 9y ago

"It's been done" and "What we need isn't tech to be invented so much as solutions to be funded and/or bought." are somewhat dismissive overstatements. If we had a way to implement a capability-secure runtime on Linux on Intel CPUs, in a way that improved performance rather than making it worse, and was straightforwardly usable with existing programs, then we could make a ton of progress and easily be commercially successful. But that is technologically difficult. Maybe we can still figure it out, though. Or maybe we just need to figure out the right trade-offs to get something viable out the door and widely used.

pjmlp 9y ago
Intel had an wonderful processor for that, iAPX 432, and they botched it. Every time I read about it I wonder how things would have turned out, if they managed to do a proper job with the CPU.
- nickpsecurity 9y ago
  Don't forget i960 which had some of 432's fundamental protections with decent performance. It was used later in high-end embedded market. https://en.wikipedia.org/wiki/Intel_i960 https://en.wikipedia.org/wiki/Intel_i960
nickpsecurity 9y ago
"in a way that improved performance rather than making it worse" This part is not realistic if it's apples to apples. Performance will always drop because the high performance came specifically by doing unsafe things that enable attackers. Adding checks or restrictions slows it down. The question is whether it can be done without slowing things down too much. I'm hopeful about this given many people are comfortably using their PC's and the net on 8-year old PC's w/ Core Duo 2's that still run pretty well. That was 65nm tech. Matching it or at least a smartphone is what I'd aim at for first run.
- catern 9y ago
  >Performance will always drop because the high performance came specifically by doing unsafe things that enable attackers. No, this is not true. Strong static typing and other compile-time information can (at least theoretically) allow improving both security and performance. For example, look at single address space operating systems. Switching between security domains is cheaper when you don't have to switch address spaces. That's an improvement to security that allows increased efficiency.