4 ms·

I will be this guy, but can’t you use a better more safe programming language and expose an API for C?

95014_refugee 4y ago
I'll be that guy, then, and note that your response demonstrates that you've never worked on a nontrivial safety-critical project. It's clear from the OP's question that the org is already C-centric. Language support in a safety environment is a large and complex issue. The compiler, tools, libraries are also required to be validated in context (depending on the standards environment), coding and other supporting standards have to be developed or vetted for adoption, you need a population of able reviewers, interoperation between implementations needs to be validated, etc. etc. etc. And at the end of the day, the "safety" that another language buys you doesn't actually get you very far. A lot of folks get hung up about memory safety, or this or that language feature, when in reality the majority of safety issues in large codebases are algorithmic in nature, and no low-level language feature is going to save you from implementing the wrong design.
- maldev 4y ago
  Yep, this is why in Vulnerability Research one of the main ways of finding bugs is concolic execution (Looking at logic for error cases). Memory safety is pretty easy to catch if you arn't a clown and use good coding patterns. Logic isn't, which is where the big money and big boy vulns come in. And honestly, most modern OS's have memory safety protections built in. This is 1992 anymore.
  - buescher 4y ago
    Sure, but safety-critical development is a different domain than vulnerability research.
  - wizofaus 4y ago
    "Memory safety is pretty easy to catch" - my experience over the last 18 months or so on a large C++ open source project says very much otherwise, almost every week a new NPE or core dump/access violation seems to leak into the codebase. These simply can't happen in many other languages and many now even have good support for non-optional references, ruling out entire classes of bugs that can suck up significant developer time to track down. And for long running systems memory leaks can also be a substantial cause of instability. If I were working on a safety critical system I'd actively push to avoid using C/C++ unless there really was no alternative. And yes modern OS kernels are pretty good evidence that it is possible to do but I'd suggest it requires exceptional programmers and some very rigorous processes to enforce.
    - buescher 4y ago
      Assume you have a functional safety requirement for which a standard exists. What language implementation would you use that is certified for that standard?
      - wizofaus 4y ago
        Not sure how that question can be meaningfully answered unless it's for a specific safety requirement/standard. Are you suggesting that for most standards that require certification, there are no compiler implementations certified except for C/C++ ones?
        buescher 4y ago
        Try the exercise. Choose one and then choose your tooling. If it's not C, C++, or Ada, I'll be surprised.
        wizofaus 4y ago
        I had some involvement with development of an air traffic management system, which was being written in Java, as that was certified for use in that field. As a language, I'd rather use C++ over Java, but if safety criticality were the priority, I'd choose Java every time. I haven't coded in Ada but unless there's something about it that's truly awful to work with, it seems a better choice than C/C++ from what I know about it.
  - speedgoose 4y ago
    Yes, memory safety is a solved problem, and research has mostly moved on. The best solution is to use a memory-safe programming language. Yet we find security vulnerabilities all the time in software written with memory unsafe programming languages.
- speedgoose 4y ago
  Well, I have worked on safety-critical projects in the industry, though there wasn't a lot of C/C++ (health-care software connected to the internet). I currently work with researchers, some in the software security domain. I don't think it's clear that the OP organisation is stuck with C. Perhaps it's the case, but I think it's also time, in 2022, to push a bit to move toward safer programming languages. You describe an excellent set of rules and processes, perhaps too much for most projects. It sounds like it could be even better with a memory-safe programming language. Also, I doubt that most secure critical C/C++ projects proof their source code correctly in Coq or similar. I also think many security issues are tightly related to the programming language. For example, SQL injections are because of SQL, XSS because of HTTP/HTML, and Buffer overflows because of C.
  - buescher 4y ago
    Security and safety are different domains and only tangentially related - i.e. it helps in both domains for code to be correct, but it's not sufficient in either.
- Gibbon1 4y ago
  One take away I got from reading some Nancy Leveson stuff is a lot of danger lurks at the interfaces between things. You can take two things that work perfectly and put them together and get catastrophic behavior. That argues to the point that there isn't a magic language that will make problems go away. Another take away from an old old paper was that safety must be a primary design goal from the start. It's not something you can bandaid in afterwards. There is a lot of stuff out that what that didn't happen and as a result you see constant whack a mole with critical bugs.
0xbeefeed 4y ago
UGH! Why there’s always a Rust cult follower ruining every C thread with their “opinions”?
- speedgoose 4y ago
  I didn't mention Rust or any language because depending on the problem, many other programming languages may be better too, such as Golang, C#, Python, Java… I know that some people get upset when they have a question, and they don't get the answer but some suggestions. But sometimes, people are not aware of the alternatives, and it's important to remind them that perhaps a better solution exists. If someone asks how to cut crusty bread with a butter knife safely, you can talk about the proper technic, how most people do it wrong, write a book about your industry do it better, but perhaps, someone should also mention that it's easier and better with a bread knife.
  - buescher 4y ago
    What happens when you're using a really nice sharp serrated bread knife and a terrible cutting process?
  - fizzynut 4y ago
    There's many other issues to mention, but in the "memory safe" languages you have poor control over memory allocation and fragmentation, which over time can cause issues with performance, size, swapping, etc.
flyingfences 4y ago
My experience in the aerospace industry may or may not be more widely applicable, but here are my two cents. Using "better more safe programming languages" generally gets you [some greater level of] memory safety and thread safety. Developing for safety-critical embedded systems with a single thread and no dynamic memory allocation renders those benefits irrelevant. There are still concerns around type safety, but full compiler warnings and strict code review, both of which we need regardless, handle that. We also need to be able to certify not only that our source code matches our requirements, but that our binaries match our source code. Compiling with --c99 --debug -O0 gives us a highly visible link between each line of source code that goes into the compiler and the assembly instructions that come out of the compiler. We know exactly what the computer is actually doing, not just what we think we've told it to do. The various "better" languages all get "better" via more powerful and clever (read: complex and opaque) compilers, which is a no-go in our field. With little benefit and impermissible cost to the alternatives, and the breadth and depth and longevity of the resources and support available for it, there's no sane choice for us but C.
- suprjami 4y ago
  This is a great reply. I'd never considered that part of this field was reverse engineering your own program to confirm the compiler actually emits what you asked it to.
- wizofaus 4y ago
  There's sense in this if you don't trust compilers/ interpreters in other languages to be reliably doing the right thing, which is certainly a reason to be wary of languages that are new or aren't super widely used. But the amount of effort that goes into ensuring Go or Rust or Ada compilers always generate the correct underlying machine code is surely far more than your own team can achieve, and if there were bugs in such compilers you'd be extraordinarily unlucky to be the first devs affected by them. Also are you saying the final shipped product is built with all the debug flags on (and optimisation flags off)? If not, how do you trust those binaries- trying to match machine code output with C source when optimizations are on (and key debug info stripped) is virtually impossible much of the time.
mamcx 4y ago
Seconded: Is insane that somebody "make safe program" but not USE a safe program for it. You can justify it by difficult of bootstrapping or a lot of legacy code that is already vetted so you can reuse. But in 2022, your options are very good in this area.

I'll be that guy, then, and note that your response demonstrates that you've never worked on a nontrivial safety-critical project. It's clear from the OP's question that the org is already C-centric. Language support in a safety environment is a large and complex issue. The compiler, tools, libraries are also required to be validated in context (depending on the standards environment), coding and other supporting standards have to be developed or vetted for adoption, you need a population of able reviewers, interoperation between implementations needs to be validated, etc. etc. etc. And at the end of the day, the "safety" that another language buys you doesn't actually get you very far. A lot of folks get hung up about memory safety, or this or that language feature, when in reality the majority of safety issues in large codebases are algorithmic in nature, and no low-level language feature is going to save you from implementing the wrong design.

maldev 4y ago
Yep, this is why in Vulnerability Research one of the main ways of finding bugs is concolic execution (Looking at logic for error cases). Memory safety is pretty easy to catch if you arn't a clown and use good coding patterns. Logic isn't, which is where the big money and big boy vulns come in. And honestly, most modern OS's have memory safety protections built in. This is 1992 anymore.
- buescher 4y ago
  Sure, but safety-critical development is a different domain than vulnerability research.
- wizofaus 4y ago
  "Memory safety is pretty easy to catch" - my experience over the last 18 months or so on a large C++ open source project says very much otherwise, almost every week a new NPE or core dump/access violation seems to leak into the codebase. These simply can't happen in many other languages and many now even have good support for non-optional references, ruling out entire classes of bugs that can suck up significant developer time to track down. And for long running systems memory leaks can also be a substantial cause of instability. If I were working on a safety critical system I'd actively push to avoid using C/C++ unless there really was no alternative. And yes modern OS kernels are pretty good evidence that it is possible to do but I'd suggest it requires exceptional programmers and some very rigorous processes to enforce.
  - buescher 4y ago
    Assume you have a functional safety requirement for which a standard exists. What language implementation would you use that is certified for that standard?
    - wizofaus 4y ago
      Not sure how that question can be meaningfully answered unless it's for a specific safety requirement/standard. Are you suggesting that for most standards that require certification, there are no compiler implementations certified except for C/C++ ones?
      - buescher 4y ago
        Try the exercise. Choose one and then choose your tooling. If it's not C, C++, or Ada, I'll be surprised.
        wizofaus 4y ago
        I had some involvement with development of an air traffic management system, which was being written in Java, as that was certified for use in that field. As a language, I'd rather use C++ over Java, but if safety criticality were the priority, I'd choose Java every time. I haven't coded in Ada but unless there's something about it that's truly awful to work with, it seems a better choice than C/C++ from what I know about it.
- speedgoose 4y ago
  Yes, memory safety is a solved problem, and research has mostly moved on. The best solution is to use a memory-safe programming language. Yet we find security vulnerabilities all the time in software written with memory unsafe programming languages.
speedgoose 4y ago
Well, I have worked on safety-critical projects in the industry, though there wasn't a lot of C/C++ (health-care software connected to the internet). I currently work with researchers, some in the software security domain. I don't think it's clear that the OP organisation is stuck with C. Perhaps it's the case, but I think it's also time, in 2022, to push a bit to move toward safer programming languages. You describe an excellent set of rules and processes, perhaps too much for most projects. It sounds like it could be even better with a memory-safe programming language. Also, I doubt that most secure critical C/C++ projects proof their source code correctly in Coq or similar. I also think many security issues are tightly related to the programming language. For example, SQL injections are because of SQL, XSS because of HTTP/HTML, and Buffer overflows because of C.
- buescher 4y ago
  Security and safety are different domains and only tangentially related - i.e. it helps in both domains for code to be correct, but it's not sufficient in either.
Gibbon1 4y ago
One take away I got from reading some Nancy Leveson stuff is a lot of danger lurks at the interfaces between things. You can take two things that work perfectly and put them together and get catastrophic behavior. That argues to the point that there isn't a magic language that will make problems go away. Another take away from an old old paper was that safety must be a primary design goal from the start. It's not something you can bandaid in afterwards. There is a lot of stuff out that what that didn't happen and as a result you see constant whack a mole with critical bugs.

0xbeefeed 4y ago

UGH! Why there’s always a Rust cult follower ruining every C thread with their “opinions”?

speedgoose 4y ago
I didn't mention Rust or any language because depending on the problem, many other programming languages may be better too, such as Golang, C#, Python, Java… I know that some people get upset when they have a question, and they don't get the answer but some suggestions. But sometimes, people are not aware of the alternatives, and it's important to remind them that perhaps a better solution exists. If someone asks how to cut crusty bread with a butter knife safely, you can talk about the proper technic, how most people do it wrong, write a book about your industry do it better, but perhaps, someone should also mention that it's easier and better with a bread knife.
- buescher 4y ago
  What happens when you're using a really nice sharp serrated bread knife and a terrible cutting process?
- fizzynut 4y ago
  There's many other issues to mention, but in the "memory safe" languages you have poor control over memory allocation and fragmentation, which over time can cause issues with performance, size, swapping, etc.

flyingfences 4y ago

My experience in the aerospace industry may or may not be more widely applicable, but here are my two cents. Using "better more safe programming languages" generally gets you [some greater level of] memory safety and thread safety. Developing for safety-critical embedded systems with a single thread and no dynamic memory allocation renders those benefits irrelevant. There are still concerns around type safety, but full compiler warnings and strict code review, both of which we need regardless, handle that. We also need to be able to certify not only that our source code matches our requirements, but that our binaries match our source code. Compiling with --c99 --debug -O0 gives us a highly visible link between each line of source code that goes into the compiler and the assembly instructions that come out of the compiler. We know exactly what the computer is actually doing, not just what we think we've told it to do. The various "better" languages all get "better" via more powerful and clever (read: complex and opaque) compilers, which is a no-go in our field. With little benefit and impermissible cost to the alternatives, and the breadth and depth and longevity of the resources and support available for it, there's no sane choice for us but C.

suprjami 4y ago
This is a great reply. I'd never considered that part of this field was reverse engineering your own program to confirm the compiler actually emits what you asked it to.
wizofaus 4y ago
There's sense in this if you don't trust compilers/ interpreters in other languages to be reliably doing the right thing, which is certainly a reason to be wary of languages that are new or aren't super widely used. But the amount of effort that goes into ensuring Go or Rust or Ada compilers always generate the correct underlying machine code is surely far more than your own team can achieve, and if there were bugs in such compilers you'd be extraordinarily unlucky to be the first devs affected by them. Also are you saying the final shipped product is built with all the debug flags on (and optimisation flags off)? If not, how do you trust those binaries- trying to match machine code output with C source when optimizations are on (and key debug info stripped) is virtually impossible much of the time.

mamcx 4y ago

Seconded: Is insane that somebody "make safe program" but not USE a safe program for it. You can justify it by difficult of bootstrapping or a lot of legacy code that is already vetted so you can reuse. But in 2022, your options are very good in this area.