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

Translating All C to Rust (TRACTOR)

darpa.mil

Post reply on HN
Print view View original

271–280 of 403 posts

Re: Translating All C to Rust (TRACTOR)

#271

Post by nanolith »

pjmlp wrote: post #265
nanolith wrote: post #207

Earlier quoted context omitted.

> That's not "in reality", that's "in theory". Because in actual reality, people still write the good old buffer overflow bugs to this day. That's because while the technology exists, it is not widely communicated. That's not a fault of C, and that's not something that any language can solve. > Explain why this has not been done yet. See above. The technology to make C and C++ safer is not yet widely used. But, it ex…

The proven fact that the said technology has failed its purpose, as the C and C++ culture keeps resisting its adoption, is the fact that all CPU vendors are now integrating hardware memory tagging as the ultimate weapon against memory corruption exploits. Solaris has already been doing it since 2015, ARM more recently, we have Microsoft putting the big buckets into CHERI (including custom FPGA boards for testing), th…

> The proven fact that the said technology has failed its purpose,

How, because other solutions are being explored? That's not due to a failure of one thing, but because both defense in depth and a desire to fix existing systems with no additional engineering are paths that security researchers and vendors explore. Not everyone will converge on a single solution, even when that solution is practical.

Just because something is not being used universally doesn't mean that it has failed. Moreso, it is not widely known about, and there persists rumors that it requires extraordinary effort, often reinforced by well meaning, but rather outdated advice.

Re: Translating All C to Rust (TRACTOR)

#272

Post by nanolith »

roca wrote: post #242
nanolith wrote: post #207

Earlier quoted context omitted.

> That's not "in reality", that's "in theory". Because in actual reality, people still write the good old buffer overflow bugs to this day. That's because while the technology exists, it is not widely communicated. That's not a fault of C, and that's not something that any language can solve. > Explain why this has not been done yet. See above. The technology to make C and C++ safer is not yet widely used. But, it ex…

Bounded model checking is not a silver bullet. If you want to prove it is, verify a Web browser and blog about it.

There are no silver bullets. But, that doesn't mean that we should dismiss tooling that is not well understood in order to chase unrealistic goals, like rewriting extant code bases in a different language to achieve security goals. Or, worse, as this article suggests, using mechanical translation to somehow capture the features of error-prone software without carrying over the errors.

Better process and better tooling allows us to write better software. Bounded model checking is an incredibly useful bit of tooling that allows us, within context of the software, to demonstrate that certain conditions do not arise. This includes memory errors, resource errors, and other classes of errors. The limitation is the faithfulness of the translation to SMT and the complexity of the code being modeled. The former has gotten quite good with CBMC 6, and the latter can be managed through careful refactoring and shadow function substitution.

Is it magic? There is no such thing. But, it is a practical tool that is available for use today.

One need not wait until an entire web browser is verified using it. It can scale to this, but given the unreasonable size and scope of web browsers with respect to this challenge, which are basically operating systems and suites of software in one these days, that's like saying, "verify all software then blog about it."

Re: Translating All C to Rust (TRACTOR)

#273

Post by Y_Y »

pjmlp wrote: post #264
Y_Y wrote: post #261

Earlier quoted context omitted.

The programmers have changed, the machines have changed, the literature has changed, the compilers have changed a lot. You can still write and run the old insecure code, but you'll get warnings and hit stack canaries and your colleagues will gasp at you and your merge requests will be rejected.

Meaningless changes, as proven by the CVE database, or the kernel corruption by a bad pointer caused by Crowdstrike.

I respectfully disagree. GP claimed that nothing has changed [regarding string and array security bugs in C] in 50 years. I responded that many relevant factors have changed, such that people tend to write different code now which is less susceptible to those bugs. Of course the same old bugs are possible, and sometimes good coders will still write them. Still I argue that there has been meaningful change since there are more protections against writing bugs in the first place, less incentive to write dangerous code, and more security for when (some) bugs still appear.

Re: Translating All C to Rust (TRACTOR)

#274

Post by pjmlp »

nanolith wrote: post #270
pjmlp wrote: post #248

Earlier quoted context omitted.

Modern C still has the same security exploits in arrays and strings as Classical C, nothing changed in 50 years.

Bounded model checking has changed things. C on its own can't solve these problems. Likewise, Rust on its own -- while it can solve memory errors -- can't demonstrate safety from all errors that lead to CVEs. Practical formal methods using a tool like CBMC can make C safer. The existing code base can be made safer without porting it to a new language or using experimental mechanical translation. This isn't just somet…

The amount of people using stuff like CBMC is like trying to boil the ocean.

WG14 can solve those problems, they decided it isn't their priority to fix C.

Re: Translating All C to Rust (TRACTOR)

#275

Post by pjmlp »

Y_Y wrote: post #273
pjmlp wrote: post #264

Earlier quoted context omitted.

Meaningless changes, as proven by the CVE database, or the kernel corruption by a bad pointer caused by Crowdstrike.

I respectfully disagree. GP claimed that nothing has changed [regarding string and array security bugs in C] in 50 years. I responded that many relevant factors have changed, such that people tend to write different code now which is less susceptible to those bugs. Of course the same old bugs are possible, and sometimes good coders will still write them. Still I argue that there has been meaningful change since there…

ISO C89 is exactly like ISO C23 in that regard.

CVE database proves that those kind of errors keep coming up in 2024, regardless of those changes.

Not only do they keep coming up, the monetary cost of fixing those issues has raised up to a level that now even governments are looking into this.

Re: Translating All C to Rust (TRACTOR)

#276

Post by pjmlp »

nanolith wrote: post #271
pjmlp wrote: post #265

Earlier quoted context omitted.

The proven fact that the said technology has failed its purpose, as the C and C++ culture keeps resisting its adoption, is the fact that all CPU vendors are now integrating hardware memory tagging as the ultimate weapon against memory corruption exploits. Solaris has already been doing it since 2015, ARM more recently, we have Microsoft putting the big buckets into CHERI (including custom FPGA boards for testing), th…

> The proven fact that the said technology has failed its purpose, How, because other solutions are being explored? That's not due to a failure of one thing, but because both defense in depth and a desire to fix existing systems with no additional engineering are paths that security researchers and vendors explore. Not everyone will converge on a single solution, even when that solution is practical. Just because som…

Hardware is the ultimate castle wall when nothing else fixes the problem at the software level.

Re: Translating All C to Rust (TRACTOR)

#277

Post by nanolith »

pjmlp wrote: post #274
nanolith wrote: post #270

Earlier quoted context omitted.

Bounded model checking has changed things. C on its own can't solve these problems. Likewise, Rust on its own -- while it can solve memory errors -- can't demonstrate safety from all errors that lead to CVEs. Practical formal methods using a tool like CBMC can make C safer. The existing code base can be made safer without porting it to a new language or using experimental mechanical translation. This isn't just somet…

The amount of people using stuff like CBMC is like trying to boil the ocean. WG14 can solve those problems, they decided it isn't their priority to fix C.

> The amount of people using stuff CBMC is like trying to boil the ocean.

That's like saying, "Getting everyone to use Rust or TDD or X is like trying to boil the ocean."

It's impossible to solve all things for all people at once. But, that doesn't mean that we can't advocate for tooling that can be used today to build safer software. This goes beyond C, as such tools and techniques are being ported to many languages and platforms.

Rust is a solution that works for some people. Modern C with bounded model checking is another solution that works for some other people. I'm certainly not going to change the minds of folks who have decided to port a project to Rust and who are willing to spend the engineering budget for this. But, hopefully, I can convince someone to try bounded model checking instead of maintaining the status quo. Because, the status quo is where we are with projects like the Linux kernel. Linux may pay lip service to Rust folks and allow them to write some components in that language, but the majority of the kernel is still in C and is not being properly vetted for these vulnerabilities, as we can see with the stream of CVEs coming out weekly.

> WG14 can solve those problems, they decided it isn't their priority to fix C.

WG14 must maintain some semblance of backwards compatibility with previous versions of C. It's no good to make a feature that breaks older code. This happens from time to time -- old school K&R C won't work in a C18 or C23 compliant compiler -- but efforts are made to keep that legacy code compiling, for good or ill.

Re: Translating All C to Rust (TRACTOR)

#278

Post by pjmlp »

mike_hearn wrote: post #256
TinkersW wrote: post #208

Earlier quoted context omitted.

With MSVC you can use _CONTAINER_DEBUG_LEVEL=1 to get a fast bounds check that can be used in release builds. Or just use it in development to catch errors.

Interesting thanks. Seems the reason I couldn't find anything on that is because it's internal only and not a feature you're actually meant to use? https://github.com/microsoft/STL/issues/586 > We talked about this at the weekly maintainer meeting and decided that we're not comfortable enough with the (lack of) design of this feature to begin documenting it for wide usage.

What you want should be _ITERATOR_DEBUG_LEVEL instead, that is the public macro for bounds checking configuration.

Re: Translating All C to Rust (TRACTOR)

#279

Post by pjmlp »

TinkersW wrote: post #209
Calavar wrote: post #56

Earlier quoted context omitted.

As far as I am aware, the standard doesn't mandate bounds checking for std::vector::operator[] and probably never will for backwards compatibility reasons. Most standard library implementations have opt-out std::vector[] bounds checking in unoptimized builds, but not in optimized builds. I tried a toy example with GCC [1], Clang [2], and MSVC [3], and none of them emit bounds checks with basic optimization flags. [1]…

As I said you need the correct flag set.. MSVC use _CONTAINER_DEBUG_LEVEL=1 and it can be used in release. They have had this feature since 2010 or so, though the flag name has changed.

The correct name is _ITERATOR_DEBUG_LEVEL.

Re: Translating All C to Rust (TRACTOR)

#280

Post by pjmlp »

Calavar wrote: post #56
TinkersW wrote: post #46

Earlier quoted context omitted.

std::vector [] has had bounds checking since forever if you set the correct compiler flag. Since they aren't using it this is a choice, presumably they prefer the speed gain.

As far as I am aware, the standard doesn't mandate bounds checking for std::vector::operator[] and probably never will for backwards compatibility reasons. Most standard library implementations have opt-out std::vector[] bounds checking in unoptimized builds, but not in optimized builds. I tried a toy example with GCC [1], Clang [2], and MSVC [3], and none of them emit bounds checks with basic optimization flags. [1]…

Add a "#define _ITERATOR_DEBUG_LEVEL 1" on top for VC++.
Post reply on HN