5 ms·

Are we seriously trying to fix buffer overflows in hardware instead of just moving on from C?

jchw 9y ago
Unclear what the article is really talking about. However, regardless of programming language, I do think that microarchitectures could do more for security. When going for memory safety, why stop at the highest level? Frankly, if it were about memory safety, though, I think we could count C out. A microarchitecture with inherent protection against memory bugs would likely not be able to provide it's advantages to vanilla C or existing C software.
- abecedarius 9y ago
  https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri-faq.html https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri... sounds promising.
  - deepnotderp 9y ago
    Unfortunately, given the industry reliance upon standard C, I doubt capability machines will ever catch on.
    - nickpsecurity 9y ago
      CHERI a capability machine designed for C programs that runs FreeBSD.
      - deepnotderp 9y ago
        My point is more that it requires modifications to existing C code to use the full capabilities (no pun intended) of a capability machine.
        fao_ 9y ago
        I wonder if this could be done with an alternate stdlib. Editing the usual e.g. heap management functions et al. so it does stuff behind the scenes.
- otakucode 9y ago
  Why not get safety AND easy concurrency by going to Software Transactional Memory in hardware? I don't know the specifics of the overhead off the top of my head but I imagine we're getting close to the point where it's a reasonable cost to bear for the benefits it would bring...
drew-y 9y ago
I feel like that $3.6 Million in funding go a lot further if spent on projects like the Rust Language.
- mirashii 9y ago
  Rust isn't a panacea. Research funding should go towards exploring a wide array of subjects. Doing anything else ends up with a monoculture.
  - drew-y 9y ago
    Agreed. Although I do think that memory safe systems languages are seriously low hanging fruit.
- ComputerGuru 9y ago
  So instead of spending money on a completely revolutionary approach that would add an additional layer of security in addition to whatever an up-and-coming language that's already doing a tremendous job at raising awareness about the relationship of programming languages and security as it invents a new paradigm (the borrow checker), we should just give it to focus on the latter?
- nickpsecurity 9y ago
  Rust's safety was partly inspired from such spending on Cyclone, a safe version of C. The NSF and other organizations fund tons of work on clean-slate languages, type systems, formal methods, etc. The academic incentives usually lead to quickly thrown together prototypes that arent production ready. Even the good ones rarely get used by programmers in general. Ocaml was one of the exceptions. What gets adoption is normally a language/platform with a knock-off of their efforts pushed by a big company or used in a "killer app." Bandwagons in other words. The consistently-low adoption of clean-slate tech along with lock-in effecta means the opposite is true: massive investment should go into making most common tech more correct, secure, and recoverable as simple as possible for users. If clean-slate, it should stay close as possible to what people already know with clean integrations. We can also continue to invest in ground-breaking stuff for niches that use them (eg SPARK Ada for aerospace) and/or new bandwagons that might build on them (eg Rust ecosystem).
samfisher83 9y ago
Do you know what JVM , Node, python runtimes are written in? Its not like there aren't bugs in other software. When you have millions of lines of code there is always going to be something that some one forgot to think about. Unless you have a very trivial program I think its hard to make anything "unhackable."
- arbusername 9y ago
  > Do you know what JVM , Node, python runtimes are written in? this doesn't matter to its following theses: > Its not like there aren't bugs in other software.
- romwell 9y ago
  >JVM Well, here's a Java Virtual Machine written in Java: https://github.com/beehive-lab/Maxine-VM https://github.com/beehive-lab/Maxine-VM Not to counter your point, but to keep the discussion going :)_
Koshkin 9y ago
Security cannot be achieved by merely avoiding programming mistakes.
- stcredzero 9y ago
  The question is not if it can be made perfect, but if it can be improved.
adrianN 9y ago
If you fix it in hardware you wouldn't have to rewrite everything in a different language. That sounds like a pretty good solution to me.
dfox 9y ago
There were/are architectures (Burroughs large systems, iAPX432, to some extent AS/400) with fine-grained memory protection which essentially solved all the memory safety issues. Apart from the fact that some such machines were terribly inefficient (eg. iAPX) the major reason why you don't see them that much today is that there was no sane way to run existing C code (or any other code that expects flat memory space for that matter) on them while preserving the safety features. So the bottom line is that such hardware architectures necessitate using more high-level languages than C.
- sseth 9y ago
  I worked on Burroughs large systems - they had a stack architecture and memory locations were tagged by data type to ensure safe access. ALGOL scope rules were effectively enforced in hardware. The issue even then was that these rules did not work once you moved to COBOL, or C or other languages which had different scope rules / data types from ALGOL and so hacks had to be used which effectively gave up a lot of the safety features of the hardware.

jchw 9y ago

Unclear what the article is really talking about. However, regardless of programming language, I do think that microarchitectures could do more for security. When going for memory safety, why stop at the highest level? Frankly, if it were about memory safety, though, I think we could count C out. A microarchitecture with inherent protection against memory bugs would likely not be able to provide it's advantages to vanilla C or existing C software.

abecedarius 9y ago
https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri-faq.html https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri... sounds promising.
- deepnotderp 9y ago
  Unfortunately, given the industry reliance upon standard C, I doubt capability machines will ever catch on.
  - nickpsecurity 9y ago
    CHERI a capability machine designed for C programs that runs FreeBSD.
    - deepnotderp 9y ago
      My point is more that it requires modifications to existing C code to use the full capabilities (no pun intended) of a capability machine.
      - fao_ 9y ago
        I wonder if this could be done with an alternate stdlib. Editing the usual e.g. heap management functions et al. so it does stuff behind the scenes.
otakucode 9y ago
Why not get safety AND easy concurrency by going to Software Transactional Memory in hardware? I don't know the specifics of the overhead off the top of my head but I imagine we're getting close to the point where it's a reasonable cost to bear for the benefits it would bring...

drew-y 9y ago

I feel like that $3.6 Million in funding go a lot further if spent on projects like the Rust Language.

mirashii 9y ago
Rust isn't a panacea. Research funding should go towards exploring a wide array of subjects. Doing anything else ends up with a monoculture.
- drew-y 9y ago
  Agreed. Although I do think that memory safe systems languages are seriously low hanging fruit.
ComputerGuru 9y ago
So instead of spending money on a completely revolutionary approach that would add an additional layer of security in addition to whatever an up-and-coming language that's already doing a tremendous job at raising awareness about the relationship of programming languages and security as it invents a new paradigm (the borrow checker), we should just give it to focus on the latter?
nickpsecurity 9y ago
Rust's safety was partly inspired from such spending on Cyclone, a safe version of C. The NSF and other organizations fund tons of work on clean-slate languages, type systems, formal methods, etc. The academic incentives usually lead to quickly thrown together prototypes that arent production ready. Even the good ones rarely get used by programmers in general. Ocaml was one of the exceptions. What gets adoption is normally a language/platform with a knock-off of their efforts pushed by a big company or used in a "killer app." Bandwagons in other words. The consistently-low adoption of clean-slate tech along with lock-in effecta means the opposite is true: massive investment should go into making most common tech more correct, secure, and recoverable as simple as possible for users. If clean-slate, it should stay close as possible to what people already know with clean integrations. We can also continue to invest in ground-breaking stuff for niches that use them (eg SPARK Ada for aerospace) and/or new bandwagons that might build on them (eg Rust ecosystem).

samfisher83 9y ago

Do you know what JVM , Node, python runtimes are written in? Its not like there aren't bugs in other software. When you have millions of lines of code there is always going to be something that some one forgot to think about. Unless you have a very trivial program I think its hard to make anything "unhackable."

arbusername 9y ago
> Do you know what JVM , Node, python runtimes are written in? this doesn't matter to its following theses: > Its not like there aren't bugs in other software.
romwell 9y ago
>JVM Well, here's a Java Virtual Machine written in Java: https://github.com/beehive-lab/Maxine-VM https://github.com/beehive-lab/Maxine-VM Not to counter your point, but to keep the discussion going :)_

Koshkin 9y ago

Security cannot be achieved by merely avoiding programming mistakes.

stcredzero 9y ago
The question is not if it can be made perfect, but if it can be improved.

adrianN 9y ago

If you fix it in hardware you wouldn't have to rewrite everything in a different language. That sounds like a pretty good solution to me.

dfox 9y ago

There were/are architectures (Burroughs large systems, iAPX432, to some extent AS/400) with fine-grained memory protection which essentially solved all the memory safety issues. Apart from the fact that some such machines were terribly inefficient (eg. iAPX) the major reason why you don't see them that much today is that there was no sane way to run existing C code (or any other code that expects flat memory space for that matter) on them while preserving the safety features. So the bottom line is that such hardware architectures necessitate using more high-level languages than C.

sseth 9y ago
I worked on Burroughs large systems - they had a stack architecture and memory locations were tagged by data type to ensure safe access. ALGOL scope rules were effectively enforced in hardware. The issue even then was that these rules did not work once you moved to COBOL, or C or other languages which had different scope rules / data types from ALGOL and so hacks had to be used which effectively gave up a lot of the safety features of the hardware.