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

221–230 of 403 posts

Re: Translating All C to Rust (TRACTOR)

#221

Post by astrange »

n_plus_1_acc wrote: post #75
PreInternet01 wrote: post #62

Earlier quoted context omitted.

Ah, a voice of sort-of sanity, at long last. So, the reason I posted my original reply, is that at one of my $DAYJOBs, we recently had a 3-day outage on some service, related to Rust. Something like using AVX to read, like, up to 7 bytes too many from an array. Nothing really major -- we have a 10-day backup window, and the damage was limited to 4 days, so we were able to identify and fix all identified cases. But th…

The Rust community as a whole very much promotes the idea of trusting the Compiler. Which is a very useful thing, especially for folks coming from other languages like C. It's not perfect of course as the compiler has bugs, but I think it still a good thing to teach.

You should never do this if you work at a company large enough to have a compiler team, btw, because they're going to fork the compiler and put bugs in it.

Conversely, if you never encounter bugs in a component, it means it's not being improved fast enough.

Re: Translating All C to Rust (TRACTOR)

#222

Post by astrange »

keybored wrote: post #116
PreInternet01 wrote: post #62

Earlier quoted context omitted.

Ah, a voice of sort-of sanity, at long last. So, the reason I posted my original reply, is that at one of my $DAYJOBs, we recently had a 3-day outage on some service, related to Rust. Something like using AVX to read, like, up to 7 bytes too many from an array. Nothing really major -- we have a 10-day backup window, and the damage was limited to 4 days, so we were able to identify and fix all identified cases. But th…

> I'm just a C# wagie, and I fully accept that my code, my language, my compiler, and my runtime environment are all shit. What is shit about those things for C#? That’s the application programming language that seems to get the least flak out of all of them. If I’m using an alpha or beta compiler, I might suspect a compiler bug from time to time… not really when I’m working in a decades-old, very established languag…

Java is an underpowered clone of ObjC and C# is a slightly less underpowered clone of Java.

So they fixed the biggest issues (at least it has value types), but it has nullable classes, collection types are mutable, integer overflow doesn't trap, it doesn't have nearly enough program verification features (aka dependent types), etc.

Worst of all it was written by enterprise programmers, who think programs get better designed when you put all their types four namespaces deep. I assume whoever named System.Collections.ArrayList keeps everything in their house in one of those filing cabinets with the tiny drawers.

Re: Translating All C to Rust (TRACTOR)

#223

Post by zajio1am »

matheusmoreira wrote: post #197
atiedebee wrote: post #174

Earlier quoted context omitted.

> Who cares if your program actually works as intended? My optimization is legal according to the standard, it's your program that's relying written to exploit loopholes". If your program invokes undefined behaviour, it's invalid and non-portable. Out of bounds array accesses are UB, yet a program containing them may just happen to work. It won't be portable even between different compiler versions. The C standard is…

If undefined behavior is invalid, then reject the program instead of "optimizing" it. This "oh look undefined behavior I'm gonna turn the entire function into a no-op" nonsense is completely unacceptable. It's adversarial and borders on malicious. Null pointer check deletion can turn bugs into exploitable vulnerabilities.

> If undefined behavior is invalid, then reject the program instead of "optimizing" it.

Undefined behavior is usually a result of runtime situation, it is usually not obvious from just the code whether it could or could not happen, so the compiler cannot reject the program.

The 'UB-based' optimization is just assumption that the code is correct and therefore UB-situation could not happen in runtime.

Re: Translating All C to Rust (TRACTOR)

#224

Post by andrewflnr »

pdimitar wrote: post #201
andrewflnr wrote: post #200

Earlier quoted context omitted.

> There is no such mentality anywhere. There definitely is. Mainstream and official Rust community material is generally sane, but the meme did not come from nowhere. The rewrite-everything people are out there.

> The rewrite-everything people are out there. Meh, there are zealots in every community -- we're not even talking programming language communities only. Not even programming either. Everywhere. No idea why people over-reacted so much to one particular 0.1% fanatics. It's a pretty normal state of affairs. Point me at your hobby group and even if it is only 20 people I can bet my balls at least 1 of them is a fanatic.

Overreacting to fanatics is also a normal state of affairs, so don't act surprised. :) By their nature fanatics almost always make a disproportionate amount of noise, and if you're outside the community you often can't tell the difference: don't know which if any of the loudmouths members pay attention to, etc. And even more broadly, a small number of people can cause a lot of damage.

Re: Translating All C to Rust (TRACTOR)

#225

Post by wolfspider »

oconnor663 wrote: post #96
deepsun wrote: post #39

They didn't explain why they've chosen Rust. There are a lot of memory-safe languages besides Rust, especially in application-level area (not systems-level like Rust).

Apart from runtime/embedded requirements, there's the big question of how you represent what C is doing in other languages that don't have interior pointers and pointer casting. For example, in C I might have a `struct foo*` that aliases the 7th element of a `struct foo[]` array. How do you represent that in Java or Python? I don't think you can use regular objects or regular arrays/lists from either of those languag…

I’ve spent the past few months translating a C library heavy in pointer arithmetic to TypeScript. Concessions have to be made here and there but ended up making utility classes to capture some of the functionality. Structs can be represented as types since they are able to also to be expressed as unions similar to structs. These const types can have fields updated in place and inherit properties from other variables similar to passing by reference which JS can do (pass by sharing) or use a deep clone to copy. As far as affecting the underlying bytes as a type I’ve come up with something I call byte type reflection which is a union type which does self-inference on the object properties in order to flatten itself into a bytearray so that the usual object indexing and length properties automatically only apply to the byte array as it has been expressed (the underlying object remains as well). C automatically does this so there is some overhead for this that cannot be removed. Pointer arithmetic can be applied with an iterator class which keeps track of the underlying data object but sadly does count as another copy. Array splicing can substitute creating a view of a pointer array which is not optimal but there are some Kotlin-esque utilities that create array views which can be used. Surprisingly, the floating point values which I expected to be way off and can only express as a number type are close enough. I use Deno FFI so plenty of room to go back to unmanaged code for optimizations and WASM can be tapped into easily. For me those values are what is important and it does the job adequately. The code is also way more resilient to runtime errors as opposed to the C library which has a tendency to just blow up. TLDR; Don’t let it stop you until you try because you might just be surprised at how it turns out. If the function calls of a library are only 2-3 levels deep how much “performance” are you really gaining by keeping it that way? Marshalling code is the usual answer and Deno FFI does an amazing job at that.

Re: Translating All C to Rust (TRACTOR)

#226

Post by hgs3 »

woodruffw wrote: post #184
0xbadcafebee wrote: post #173

Earlier quoted context omitted.

They aren't trying to prevent them. It's trivial to prevent them if you actually put effort into it; if you don't, it's going to be vulnerable. This is true of all security concerns.

"You aren't trying hard enough" isn't a serious approach to security: if it was, we wouldn't require seatbelts in cars or health inspections in restaurants. (It's also not clear that they aren't trying hard enough: Google, Apple, etc. have billions of dollars riding on the safety of their products, but still largely fail to produce memory-safe C and C++ codebases.)

In the case of OpenSSL, Big Tech clearly neglected proper support until after the Heartbleed vulnerability. Prior to Heartbleed, the OpenSSL Software Foundation only received about $2K annually in donations and employed just one full-time employee [1]. Given the projects critical role in internet security, Big Techs neglect raises concerns about their quality assurance practices for less critical projects.

The OpenSSL Foundation is not exempt from criticism despite inadequate funding. Heartbleed was discovered by security researches using fuzz testing, but proactive fuzz testing should have been a standard practice from the start.

[1] https://arstechnica.com/information-technology/2014/04/tech-...

Re: Translating All C to Rust (TRACTOR)

#227

Post by adgjlsfhk1 »

nanolith wrote: post #212
pdimitar wrote: post #210

Earlier quoted context omitted.

> That's not a fault of C, and that's not something that any language can solve. If you say so. Rust clearly does, and before you go saying "but `unsafe` exists!" I'll have to remind you that (1) scarcely any Rust devs reaches for that and (2) it still keeps quite a lot of guarantees and only relaxes some . Some, not all. Not even most. > It's laudable that you wish to rid the world of memory errors. I want to normal…

> Rust clearly does Until it exists at the kernel layer, the firmware layer, the runtime library layer, and the application layer, these issues still exist. CVEs come out weekly for memory errors in Linux, in firmware, in operating system libraries, and in application libraries. We need to think beyond rewriting code in one language or platform, and instead think about technologies that we can apply to all languages…

bounded model checking is a new language with new idioms

Re: Translating All C to Rust (TRACTOR)

#228

Post by elromulous »

mike_hearn wrote: post #10

That sounds ... hard. Especially as idiomatic Rust as written by skilled programmers looks nothing like C, and most interesting code is written in C++ anyway. Isn't it equivalent to statically determining the lifetimes of all allocations in the C program, including those that are implemented using custom allocators or which cross into proprietary libraries? There's been a lot of research into this sort of thing over…

> and most interesting code is written in C++ anyway.

You're just asking for people to bring out their pitchforks :P

Re: Translating All C to Rust (TRACTOR)

#229

Post by nanolith »

adgjlsfhk1 wrote: post #227
nanolith wrote: post #212

Earlier quoted context omitted.

> Rust clearly does Until it exists at the kernel layer, the firmware layer, the runtime library layer, and the application layer, these issues still exist. CVEs come out weekly for memory errors in Linux, in firmware, in operating system libraries, and in application libraries. We need to think beyond rewriting code in one language or platform, and instead think about technologies that we can apply to all languages…

bounded model checking is a new language with new idioms

Respectfully, that's a rather extraordinary claim. There are model checkers that use separate specification languages, but there are also model checkers embedded in the host language.

CBMC translates C -- the same language -- to an SMT solver. A different target but the same language.

It is true that new idioms will often be discovered along the way of converting existing C to pass the bounded model checker in every branch condition and in every case. However, software that is already relatively safe will require very little modification. I've seen it go both ways. Simpler code bases can pass model checks relatively unscathed. More complex code bases require refactoring to pass model checking.

To my point, the code base can remain in C, and can be model checked gradually. It doesn't have to be ported to a different language or platform. But, it will require added assertions and some refactoring to make the execution of code more clear. It's still in C. The specifications are specified in C using regular assertions. The only thing that changes is that one will often use shadow methods -- still written in C but simpler than the functions they are shadowing -- in order to model check other functions.

Other bounded model checkers like JBMC, Kani, or PolySpace work in similar ways.

Re: Translating All C to Rust (TRACTOR)

#230

Post by techbrovanguard »

akira2501 wrote: post #141
commodoreboxer wrote: post #51

A lot of people are reading this as a call or demand to translate all C and C++ code to Rust, but (despite the catchy project name), I don't read the abstract in that way. There are two related but separate paragraphs. 1. C and C++ just aren't safe enough at large. Even with careful programming and good tooling, so many vulnerabilities are caused by their unsafe by default designs. Therefore, as much code as possible…

> or written in "safe" languages So when those languages have 'unsafe' constructs what are the rules going to be around using those? Without a defining set of rules to use here you're just going to end up right back where you started. > to migrate to safe languages, which Rust is an example of Rust has a safe mode. It is _not_ a safe language. To do anything interesting you will require unsafe blocks. This will not g…

> To do anything interesting you will require unsafe blocks

this is just flagrantly false, have you no shame?

Post reply on HN