Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk

thenewstack.io

Post reply on HN
Print view View original

91–100 of 100 posts

Re: Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk

#91

Post by sunshowers »

tetnis wrote: post #90
sunshowers wrote: post #80

Earlier quoted context omitted.

I regularly solve logic bugs using affine typing and shared xor mutability, so clearly some subset of logic bugs is solved with Rust, no?

Ok, I didn't really define logic bugs. I think of things like race conditions as memory bugs because its improper access to the same variable. So I suppose All Bugs Are Logic Bugs. But I really meant that many software software vuln aren't even that fancy. Sure if you have something like an iPhone which has whole companies trying to hack it, then eventually the bugs you have left are fancy heap overflows. But lots of…

Cargo does not require internet access to compile. You need it just to download packages once (which you obviously do in any ecosystem). Cargo also cryptographically verifies that downloaded packages haven't been tampered with.

Affine types also help with credential checking! Newtype wrappers synergize really well with them. I wrote a post about some of this a few years ago: https://sunshowers.io/posts/types/

Re: Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk

#92

Post by nanolith »

timClicks wrote: post #88
nanolith wrote: post #42

Leave it to politicians to pit bull a language. Model checked C/C++ is memory safe. Had they reached out to a wider set of people for guidance, they'd have a more balanced report. I will agree that software safety -- not just memory safety -- is critical. Trying to attack this at the language level instead of the development process and assurance level is daft. FIPS certification and aerospace certification both requ…

That's the intent of the document - to reach people for guidance. The document under discussion is requesting comment from industry.

Yep. I'm writing up a response letter based on my own work with model checked C. It's not the language but the process and the tooling that matters. It is definitely true that the industry has been quite lax with memory safety, but the solution isn't to rewrite everything in yet another language. The solution is to tighten development processes and put forward a plan to make existing code safer.

Re: Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk

#93

Post by dataflow »

nanolith wrote: post #92
timClicks wrote: post #88

Earlier quoted context omitted.

That's the intent of the document - to reach people for guidance. The document under discussion is requesting comment from industry.

Yep. I'm writing up a response letter based on my own work with model checked C. It's not the language but the process and the tooling that matters. It is definitely true that the industry has been quite lax with memory safety, but the solution isn't to rewrite everything in yet another language. The solution is to tighten development processes and put forward a plan to make existing code safer.

> It's not the language but the process and the tooling that matters.

You're missing some other critical components: the developers, and the costs.

If you come up with processes and tooling that is difficult to use widely, you're going to negatively impact your ability to deliver. That's not a trade-off you can ignore. If the cost of using C++ safely ends up being that only (say) 10% of the developers who currently use it will be able to keep doing that -- that on its own might justify a government policy decision to avoid it completely.

> but the solution isn't to rewrite everything in yet another language

How many times more effort would it be to rewrite a typical C++ function in a memory-safe language vs. verify the equivalent guarantees with model-checking tools, in your view?

Like how much actual work are you saving here? And how do the resulting turnaround times (say, compile/verification/etc. times) compare?

Re: Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk

#94

Post by nanolith »

dataflow wrote: post #93
nanolith wrote: post #92

Earlier quoted context omitted.

Yep. I'm writing up a response letter based on my own work with model checked C. It's not the language but the process and the tooling that matters. It is definitely true that the industry has been quite lax with memory safety, but the solution isn't to rewrite everything in yet another language. The solution is to tighten development processes and put forward a plan to make existing code safer.

> It's not the language but the process and the tooling that matters. You're missing some other critical components: the developers, and the costs. If you come up with processes and tooling that is difficult to use widely, you're going to negatively impact your ability to deliver. That's not a trade-off you can ignore. If the cost of using C++ safely ends up being that only (say) 10% of the developers who currently u…

> You're missing some other critical components: the developers, and the costs.

No, I'm not.

> If you come up with processes and tooling that is difficult to use widely,

That's an unfounded assumption. The tooling and processes I have developed are no more difficult to use than unit testing.

> How many times more effort would it be...

I'd say compared to the 10% or so overhead of model checking, it would be approximately 8X as difficult, given that this requires learning a new language, using it correctly, and rebuilding the semantics in a way that is safe in that language. But, first, you need to learn new frameworks, rebuild all of the testing and quality assurance that went into the first development process, and rebuild the same level of trust as the original. Writing software is the easy part. It's all of the other stuff, like analysis, testing, confidence building, and engineering that costs money, and this would have to be redone from scratch, as the artifact from that original effort is being thrown away for a rewrite. Remember: the cost of rewriting software isn't just the cost of sitting down and banging out code.

> And how do the resulting turnaround times (say, compile/verification/etc. times) compare?

Model checking is actually pretty fast if you use proper shadowing. Compiling with C is lightning fast. I'd say that using a model checker is a little slower than compiling with Rust.

Also, you are mistaken that using a memory-safe language gives equivalent guarantees. It does not. A model checker allows you to write safer code. There are more errors than memory errors. Memory safety fixes many of the problems, but not nearly enough. So, after that rewrite, you'll also need to add a model checker or some other kind of formal methods to be as safe as just using the model checker to begin with. For Rust, that's Kani. It's not an apples to apples comparison.

Re: Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk

#95

Post by dataflow »

nanolith wrote: post #94
dataflow wrote: post #93

Earlier quoted context omitted.

> It's not the language but the process and the tooling that matters. You're missing some other critical components: the developers, and the costs. If you come up with processes and tooling that is difficult to use widely, you're going to negatively impact your ability to deliver. That's not a trade-off you can ignore. If the cost of using C++ safely ends up being that only (say) 10% of the developers who currently u…

> You're missing some other critical components: the developers, and the costs. No, I'm not. > If you come up with processes and tooling that is difficult to use widely, That's an unfounded assumption. The tooling and processes I have developed are no more difficult to use than unit testing. > How many times more effort would it be... I'd say compared to the 10% or so overhead of model checking, it would be approxima…

>> If you come up with processes and tooling that is difficult to use widely,

> That's an unfounded assumption. The tooling and processes I have developed are no more difficult to use than unit testing.

My assumption was just founded on the reality of how few developers use model-checking tools, and how they difficult they find them. If your tools are radically better, and they work for C++, that's obviously amazing.

Could you give us an idea of what the equivalent of this simple C++ code would look like, so we can see how it looks in comparison? You know, with whatever bells and whistles you need to add to it for the model checker to verify its correctness:

  #include 
  #include 
  
  template
  auto make_map(size_t argc, const Char *const argv[]) {
    using S = std::basic_string;
    std::unordered_map map;
    for (size_t i = 0; i + 2  &);
  
  int main(int argc, char *argv[]) {
    return process(make_map(argc, argv));
  }

Re: Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk

#96

Post by nanolith »

dataflow wrote: post #95
nanolith wrote: post #94

Earlier quoted context omitted.

> You're missing some other critical components: the developers, and the costs. No, I'm not. > If you come up with processes and tooling that is difficult to use widely, That's an unfounded assumption. The tooling and processes I have developed are no more difficult to use than unit testing. > How many times more effort would it be... I'd say compared to the 10% or so overhead of model checking, it would be approxima…

>> If you come up with processes and tooling that is difficult to use widely, > That's an unfounded assumption. The tooling and processes I have developed are no more difficult to use than unit testing. My assumption was just founded on the reality of how few developers use model-checking tools, and how they difficult they find them. If your tools are radically better, and they work for C++, that's obviously amazing.…

The reason why so few developers use model checking tools is because there is limited documentation out there for how to use them effectively. That is changing. Hell, I'm writing a book on the subject.

These tools aren't difficult to use. They just aren't well documented.

I've got better things to do with my afternoon than model check random bits of code in a forum. You wouldn't ask someone talking about a unit testing framework to unit test an example that you write up. If you're curious, I'm writing a book on model checking C, which will be going off to the publisher sometime in 2025. There are also examples online.

Re: Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk

#97

Post by dataflow »

nanolith wrote: post #96
dataflow wrote: post #95

Earlier quoted context omitted.

>> If you come up with processes and tooling that is difficult to use widely, > That's an unfounded assumption. The tooling and processes I have developed are no more difficult to use than unit testing. My assumption was just founded on the reality of how few developers use model-checking tools, and how they difficult they find them. If your tools are radically better, and they work for C++, that's obviously amazing.…

The reason why so few developers use model checking tools is because there is limited documentation out there for how to use them effectively. That is changing. Hell, I'm writing a book on the subject. These tools aren't difficult to use. They just aren't well documented. I've got better things to do with my afternoon than model check random bits of code in a forum. You wouldn't ask someone talking about a unit testi…

> I've got better things to do with my afternoon than model check random bits of code in a forum. You wouldn't ask someone talking about a unit testing framework to unit test an example that you write up.

I totally would, and I would also reply to their example. I've exchanged code examples in the past right here on HN for discussions like this.

You obviously don't have to do anything, but if you're going to claim it's only a 10% difference compared to unit testing -- expect people to be skeptical unless you can show side-by-side examples.

> If you're curious, I'm writing a book on model checking C, which will be going off to the publisher sometime in 2025. There are also examples online.

I'm not at all curious about model checking C. I've seen that before numerous times, and frankly, even if you could cut the development cost in C by 50% through model checking, I still wouldn't be interested.

You keep going back to C... in a conversation that's that's supposed to cover C++. I'm not sure why you do this, if the solutions to them are actually comparable -- a lot of the world is on C++, so you would find a much, much broader audience if you cater to that. My suggestion (and you're obviously welcome to ignore me, but I'm just letting you know my reaction as a reader) is to focus your response letter & book at least partly on visibly demonstrating how your proposed solutions would have similar success on C++. If you don't sell people on this being a solution for C++, I doubt your writing will make many people change their minds about switching to a different language.

Re: Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk

#98

Post by nanolith »

dataflow wrote: post #97
nanolith wrote: post #96

Earlier quoted context omitted.

The reason why so few developers use model checking tools is because there is limited documentation out there for how to use them effectively. That is changing. Hell, I'm writing a book on the subject. These tools aren't difficult to use. They just aren't well documented. I've got better things to do with my afternoon than model check random bits of code in a forum. You wouldn't ask someone talking about a unit testi…

> I've got better things to do with my afternoon than model check random bits of code in a forum. You wouldn't ask someone talking about a unit testing framework to unit test an example that you write up. I totally would, and I would also reply to their example. I've exchanged code examples in the past right here on HN for discussions like this. You obviously don't have to do anything, but if you're going to claim it…

I'm focused on C because a lot of our critical infrastructure is written in C. The Linux / BSD kernels, firmware, etc. It's also where my interest is. Model checked C is a good enough balance of cognitive load, safety, and time to market for my purposes. Others may disagree.

Tooling exists in C++. That shouldn't be too surprising given that the C++ abstract machine model is not much more complex than C and has similar complexities as Rust. The same techniques work there as well. If someone wants to tap that audience by translating this process to C++, they are welcome to do so.

Re: Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk

#99

Post by whytevuhuni »

nanolith wrote: post #96
dataflow wrote: post #95

Earlier quoted context omitted.

>> If you come up with processes and tooling that is difficult to use widely, > That's an unfounded assumption. The tooling and processes I have developed are no more difficult to use than unit testing. My assumption was just founded on the reality of how few developers use model-checking tools, and how they difficult they find them. If your tools are radically better, and they work for C++, that's obviously amazing.…

The reason why so few developers use model checking tools is because there is limited documentation out there for how to use them effectively. That is changing. Hell, I'm writing a book on the subject. These tools aren't difficult to use. They just aren't well documented. I've got better things to do with my afternoon than model check random bits of code in a forum. You wouldn't ask someone talking about a unit testi…

What are some of the tools you'd recommend?

In my case I'm working with Nginx and I'd like to make a few custom modules safer.

Re: Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk

#100

Post by nanolith »

whytevuhuni wrote: post #99
nanolith wrote: post #96

Earlier quoted context omitted.

The reason why so few developers use model checking tools is because there is limited documentation out there for how to use them effectively. That is changing. Hell, I'm writing a book on the subject. These tools aren't difficult to use. They just aren't well documented. I've got better things to do with my afternoon than model check random bits of code in a forum. You wouldn't ask someone talking about a unit testi…

What are some of the tools you'd recommend? In my case I'm working with Nginx and I'd like to make a few custom modules safer.

For C, I recommend CBMC.
Post reply on HN