4 ms·

From a security perspective, if you think C is inadequate, try taking a look at the instruction set docs for one of Intel or AMD's semi-modern chips. ;-)

yxhuvud 10y ago
That is not an excuse. Defence in depth is a thing.
- jstewartmobile 10y ago
  If you're building on a sinkhole, I don't see how having really nice floors helps.
  - platz 10y ago
    I don't see how the chip's 'sinkhole' enabled bugs like heartbleed, which was industry-scale, which absolutely could've been prevented by having a really nice floor.
  - jstewartmobile 10y ago
    You can fix heartbleed--even in C. You can't fix TPM hacks, rowhammer, etc. without buying a new machine. That's not even getting into the potential of the missteps in the RMM / MMU / SMP / virt systems that exasperate even Torvalds and deRaadt.
    - sitkack 10y ago
      You are making an all or none fallacy. While those things do exist, we can't use them as an excuse to prevent the common case.
      - jstewartmobile 10y ago
        I'm not making any kind of fallacy here. The chipset is the foundation. Even with perfect programs written in perfect languages, the Mossad can still get whatever they want without breaking a sweat thanks to the silicon. If we were going to set priorities for making things "better," the foundation would be the reasonable place to start. We'd probably be happy with Algol if we were running it on B5000-style hardware.
        joncampbelldev 10y ago
        It sounds like you mean that stopping the vast numbers of lesser attackers other than Mossad is so much less important that its worth ignoring. Most people's day to day experience of vulnerabilities is someone getting access to their password or (for the techies) their private server. Stupid actions aside (like leaving a database open to the internet), it'd be nice if things like heartbleed weren't so prolific. Perhaps when we're living in a dystopian facist state we will wish we started out by fixing the hardware vulns, but until then it'd be nice if, for example, a person who has setup ssl correctly can assume it won't leak data all over the place.
        jstewartmobile 10y ago
        Never said to ignore anything. I'm just outlining priorities. With things like rowhammer, you don't have to be Mossad to exploit it, and you can't apt-get or windows update your way around it. From your own examples, better languages can only do so much.
  - MaulingMonkey 10y ago
    No point in building elsewhere if any earthquake will cause the structure to collapse, killing everyone inside, even on more solid ground. I'd love for chip design to be the weak point for once. Let's make it happen.
nickpsecurity 10y ago
Cornell did that. They saw horrible things. Then, they fixed the root cause: https://www.cs.cornell.edu/talc/ https://www.cs.cornell.edu/talc/ Did something similar with C in Popcorn: a safe, C dialect that compiles to TALC. Gotta wonder what things would be like if more groups took such an approach to the problems they've found in C, UNIX, etc. Well, it was a nice vision at least. :)
- emmelaich 10y ago
  I followed the web search links to Cyclone, Popcorn's successor and ended up at http://www.eecs.harvard.edu/~greg/cyclone/ http://www.eecs.harvard.edu/~greg/cyclone/ which is a 404. Which suggests how popular these safe C's are, regrettably.
  - nickpsecurity 10y ago
    Yep. How it always goes. Fortunately, Cyclones region and dynamic safety helped inspire Rust's scheme. It went somewhere even if not for C programmers in general. Far as also-rans, there's Microsoft's Vault, FLINT's C0 used in Verisoft for whole-system verification, and Clay that's mainly applied by Lea Wittie in stuff like device drivers. https://web.archive.org/web/20080219014100/http://research.microsoft.com/vault/ https://web.archive.org/web/20080219014100/http://research.m... http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.468.2032&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.468... http://www.verisoft.de/VerisoftRepository.html http://www.verisoft.de/VerisoftRepository.html http://www.eg.bucknell.edu/~lwittie/research/Clay.pdf http://www.eg.bucknell.edu/~lwittie/research/Clay.pdf http://www.eg.bucknell.edu/~lwittie/research.html http://www.eg.bucknell.edu/~lwittie/research.html

yxhuvud 10y ago

That is not an excuse. Defence in depth is a thing.

jstewartmobile 10y ago
If you're building on a sinkhole, I don't see how having really nice floors helps.
- platz 10y ago
  I don't see how the chip's 'sinkhole' enabled bugs like heartbleed, which was industry-scale, which absolutely could've been prevented by having a really nice floor.
- jstewartmobile 10y ago
  You can fix heartbleed--even in C. You can't fix TPM hacks, rowhammer, etc. without buying a new machine. That's not even getting into the potential of the missteps in the RMM / MMU / SMP / virt systems that exasperate even Torvalds and deRaadt.
  - sitkack 10y ago
    You are making an all or none fallacy. While those things do exist, we can't use them as an excuse to prevent the common case.
    - jstewartmobile 10y ago
      I'm not making any kind of fallacy here. The chipset is the foundation. Even with perfect programs written in perfect languages, the Mossad can still get whatever they want without breaking a sweat thanks to the silicon. If we were going to set priorities for making things "better," the foundation would be the reasonable place to start. We'd probably be happy with Algol if we were running it on B5000-style hardware.
      - joncampbelldev 10y ago
        It sounds like you mean that stopping the vast numbers of lesser attackers other than Mossad is so much less important that its worth ignoring. Most people's day to day experience of vulnerabilities is someone getting access to their password or (for the techies) their private server. Stupid actions aside (like leaving a database open to the internet), it'd be nice if things like heartbleed weren't so prolific. Perhaps when we're living in a dystopian facist state we will wish we started out by fixing the hardware vulns, but until then it'd be nice if, for example, a person who has setup ssl correctly can assume it won't leak data all over the place.
        jstewartmobile 10y ago
        Never said to ignore anything. I'm just outlining priorities. With things like rowhammer, you don't have to be Mossad to exploit it, and you can't apt-get or windows update your way around it. From your own examples, better languages can only do so much.
- MaulingMonkey 10y ago
  No point in building elsewhere if any earthquake will cause the structure to collapse, killing everyone inside, even on more solid ground. I'd love for chip design to be the weak point for once. Let's make it happen.

nickpsecurity 10y ago

Cornell did that. They saw horrible things. Then, they fixed the root cause: https://www.cs.cornell.edu/talc/ https://www.cs.cornell.edu/talc/ Did something similar with C in Popcorn: a safe, C dialect that compiles to TALC. Gotta wonder what things would be like if more groups took such an approach to the problems they've found in C, UNIX, etc. Well, it was a nice vision at least. :)

emmelaich 10y ago
I followed the web search links to Cyclone, Popcorn's successor and ended up at http://www.eecs.harvard.edu/~greg/cyclone/ http://www.eecs.harvard.edu/~greg/cyclone/ which is a 404. Which suggests how popular these safe C's are, regrettably.
- nickpsecurity 10y ago
  Yep. How it always goes. Fortunately, Cyclones region and dynamic safety helped inspire Rust's scheme. It went somewhere even if not for C programmers in general. Far as also-rans, there's Microsoft's Vault, FLINT's C0 used in Verisoft for whole-system verification, and Clay that's mainly applied by Lea Wittie in stuff like device drivers. https://web.archive.org/web/20080219014100/http://research.microsoft.com/vault/ https://web.archive.org/web/20080219014100/http://research.m... http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.468.2032&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.468... http://www.verisoft.de/VerisoftRepository.html http://www.verisoft.de/VerisoftRepository.html http://www.eg.bucknell.edu/~lwittie/research/Clay.pdf http://www.eg.bucknell.edu/~lwittie/research/Clay.pdf http://www.eg.bucknell.edu/~lwittie/research.html http://www.eg.bucknell.edu/~lwittie/research.html