4 ms·

The only currently-extant memory-unsafe language. Some variants of Forth? OpenSMTPD actually dates back earlier to around 2009, when it was introduced in 4.6.

The only currently-extant memory-unsafe language. Some variants of Forth? OpenSMTPD actually dates back earlier to around 2009, when it was introduced in 4.6. Not that this is even notable, as virtually all major OpenBSD projects are C-based.

nickpsecurity 11y ago
Yeah, there are other memory-unsafe languages. His overall point remains. Matter of fact, thanks to you, I can now drop bombs on concurrency angle thanks to Concurrent Pascal, Solo, etc. Relevant given all the C & BSD apps juggling threads. To think mainstream is just now solving these problems in past 3-5 years despite proven solutions available... (rolls eyes)
- vezzy-fnord 11y ago
  I don't see what concurrency has to do with any of this. Concurrent Pascal was an interesting project for its time, heavily dated by now. The greatest victory for concurrency was having architectures with thread-level parallelism instead of the dominant instruction-level parallelism, and one specifically optimized for CSP in the occam language. This was, of course, the transputer. So much for that. Erlang/OTP leads in the modern era. But I don't see any relation to our current topic of discussion.
  - nickpsecurity 11y ago
    Server apps, including mail, implement forms of concurrency to handle incoming requests. Smart ones use either multi-threading or event model for performance. OpenBSD and others have all kinds of such apps they built on C. There have been numerous concurrency-related errors in major server apps due to this. So, just like with C itself, ignoring the safe, concurrency approaches from languages like Concurrent Pascal (or SCOOP/Eiffel today) is a failure to learn from the past with a direct, proven cost. Think all the race conditions, deadlocks, etc that have hit server apps would've happened on Solo, Ada tasking, or SCOOP? Probably fewer to none. So, it's still relevant and Ada/Eiffel are actually building on it. Especially SCOOP R&D community.
    - vezzy-fnord 11y ago
      Oh, you're criticizing shared-state concurrency, I take it. Event loops seem to have been the norm for C projects for a while. Both OpenSMTPD and qmail seem to rely on concurrency through forkexec, which would entail deferring to the kernel's CPU scheduling and job control.
      - nickpsecurity 11y ago
        Yeah, specifically unsafe handling of it. Forkexec seems to be a heavyweight (and less portable) approach that even DJB defended in his paper. My gripe should apply to any using threads. "Event loops seem to have been the norm for C projects for a while." I'll take you word for it as I've seen that in the few, top-tier ones I scrutinized. There's a similar trail of research dealing with that alternate model. Have a feeling the meme might apply there, too, but won't accuse them until I see for sure. ;)
jerf 11y ago
Starting in 2009 mitigates my criticism by, oh, let's say, 40%. Which I mean as an acknowledgment of your correction, even as I'm not generally backing down from the core point. I want to respect OpenBSD. To a great extent, I do. And there are reasons to prefer tested C codebases to untested code bases in new languages, sure. But to the extent I can't give my full, unadulterated respect to OpenBSD, it is because I don't see that they consider everything being in C a problem to be solved. I mean, I get engineering considerations and that we can't rewrite everything at the drop of a hat and performance matters, etc. But it is my opinion that any engineer that cares about security really ought to see "written in C" as starting out with a huge entry on the debit side, and take appropriate actions. And every year that goes by that's more true.
- vezzy-fnord 11y ago
  I'm conflicted on the issue. As a general principle, writing security-conscious code in C should be avoided. On the other hand, the issue is a tad more subtle. There seems to be an almost Pavlovian revilement and panic against C code, and this usually comes from people who haven't dealt with the language in a long time or at all in any depth. For one thing, the blanket assertion that secure C code is a Herculean task, doesn't quite pan out. djb showed one way, based on a few general principles espoused in qmail, that has since successfully been reapplied by people like Wayne Marshall, Laurent Bercot, Bruce Guenter, Paul Jarc, JdeBP and so on. Much of it comes from abandoning the C standard library in favor of more robust alternatives like libdjb variants, clearly architecting process/module boundaries, using simple formats like netstrings and text0 that need not be "parsed" in the conventional sense, etc. Further along the line, we have the SEI CERT C Coding Standard that comprehensively identifies many pitfalls. [1] Deeper still, cryptography is one area where abstraction can be an enemy. You actually have to deeply worry about time complexity, branch prediction, precise timing, compiler optimizations and so on [2]. A tool like C becomes desirable here. Lastly, but crucially - you're on Unix, for better or for worse. POSIX, SUS, all of those standards? They're deeply written with the conventions and API/ABI semantics of C in mind. Such is life. When you primarily write code at that level, the easiest way not to have any impedance mismatch is to just write it in C. [1] https://www.securecoding.cert.org/confluence/display/c/SEI+CERT+C+Coding+Standard https://www.securecoding.cert.org/confluence/display/c/SEI+C... [2] https://cryptocoding.net/index.php/Coding_rules https://cryptocoding.net/index.php/Coding_rules

nickpsecurity 11y ago

Yeah, there are other memory-unsafe languages. His overall point remains. Matter of fact, thanks to you, I can now drop bombs on concurrency angle thanks to Concurrent Pascal, Solo, etc. Relevant given all the C & BSD apps juggling threads. To think mainstream is just now solving these problems in past 3-5 years despite proven solutions available... (rolls eyes)

vezzy-fnord 11y ago
I don't see what concurrency has to do with any of this. Concurrent Pascal was an interesting project for its time, heavily dated by now. The greatest victory for concurrency was having architectures with thread-level parallelism instead of the dominant instruction-level parallelism, and one specifically optimized for CSP in the occam language. This was, of course, the transputer. So much for that. Erlang/OTP leads in the modern era. But I don't see any relation to our current topic of discussion.
- nickpsecurity 11y ago
  Server apps, including mail, implement forms of concurrency to handle incoming requests. Smart ones use either multi-threading or event model for performance. OpenBSD and others have all kinds of such apps they built on C. There have been numerous concurrency-related errors in major server apps due to this. So, just like with C itself, ignoring the safe, concurrency approaches from languages like Concurrent Pascal (or SCOOP/Eiffel today) is a failure to learn from the past with a direct, proven cost. Think all the race conditions, deadlocks, etc that have hit server apps would've happened on Solo, Ada tasking, or SCOOP? Probably fewer to none. So, it's still relevant and Ada/Eiffel are actually building on it. Especially SCOOP R&D community.
  - vezzy-fnord 11y ago
    Oh, you're criticizing shared-state concurrency, I take it. Event loops seem to have been the norm for C projects for a while. Both OpenSMTPD and qmail seem to rely on concurrency through forkexec, which would entail deferring to the kernel's CPU scheduling and job control.
    - nickpsecurity 11y ago
      Yeah, specifically unsafe handling of it. Forkexec seems to be a heavyweight (and less portable) approach that even DJB defended in his paper. My gripe should apply to any using threads. "Event loops seem to have been the norm for C projects for a while." I'll take you word for it as I've seen that in the few, top-tier ones I scrutinized. There's a similar trail of research dealing with that alternate model. Have a feeling the meme might apply there, too, but won't accuse them until I see for sure. ;)

jerf 11y ago

Starting in 2009 mitigates my criticism by, oh, let's say, 40%. Which I mean as an acknowledgment of your correction, even as I'm not generally backing down from the core point. I want to respect OpenBSD. To a great extent, I do. And there are reasons to prefer tested C codebases to untested code bases in new languages, sure. But to the extent I can't give my full, unadulterated respect to OpenBSD, it is because I don't see that they consider everything being in C a problem to be solved. I mean, I get engineering considerations and that we can't rewrite everything at the drop of a hat and performance matters, etc. But it is my opinion that any engineer that cares about security really ought to see "written in C" as starting out with a huge entry on the debit side, and take appropriate actions. And every year that goes by that's more true.

vezzy-fnord 11y ago
I'm conflicted on the issue. As a general principle, writing security-conscious code in C should be avoided. On the other hand, the issue is a tad more subtle. There seems to be an almost Pavlovian revilement and panic against C code, and this usually comes from people who haven't dealt with the language in a long time or at all in any depth. For one thing, the blanket assertion that secure C code is a Herculean task, doesn't quite pan out. djb showed one way, based on a few general principles espoused in qmail, that has since successfully been reapplied by people like Wayne Marshall, Laurent Bercot, Bruce Guenter, Paul Jarc, JdeBP and so on. Much of it comes from abandoning the C standard library in favor of more robust alternatives like libdjb variants, clearly architecting process/module boundaries, using simple formats like netstrings and text0 that need not be "parsed" in the conventional sense, etc. Further along the line, we have the SEI CERT C Coding Standard that comprehensively identifies many pitfalls. [1] Deeper still, cryptography is one area where abstraction can be an enemy. You actually have to deeply worry about time complexity, branch prediction, precise timing, compiler optimizations and so on [2]. A tool like C becomes desirable here. Lastly, but crucially - you're on Unix, for better or for worse. POSIX, SUS, all of those standards? They're deeply written with the conventions and API/ABI semantics of C in mind. Such is life. When you primarily write code at that level, the easiest way not to have any impedance mismatch is to just write it in C. [1] https://www.securecoding.cert.org/confluence/display/c/SEI+CERT+C+Coding+Standard https://www.securecoding.cert.org/confluence/display/c/SEI+C... [2] https://cryptocoding.net/index.php/Coding_rules https://cryptocoding.net/index.php/Coding_rules