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

Mitigating Memory Safety Issues in Open Source Software

security.googleblog.com

Post reply on HN
Print view View original

111–120 of 244 posts

Re: Mitigating Memory Safety Issues in Open Source Software

#111

Post by ragnese »

arcturus17 wrote: post #50
hahahahe wrote: post #26

The more I look at Rust the more I realize it’s going to become the next standard language.

You mean standard for systems programming? I don't doubt that it will be a popular choice in that area, but even there it has competition from new languages. And above all, I think it might take longer than a century to phase out all the C/C++ legacy code!

It'll be interesting to see how it plays out.

I could absolutely see C++ devs jumping ship to Rust. I think const generics just stabilized or is about to. That was one of the first shortcomings I noticed when I learned Rust. I think custom allocators is pretty much the next big piece that would give C++ devs pause today.

But I don't see Rust picking up a lot of C devs. Rust is significantly more complex than C. You certainly don't have to use traits and Futures, etc, but you also don't have to use a bunch of features of C++ either and C devs still don't jump to C++.

Zig certainly gets a lot of buzz here, but I haven't personally looked into it. It does certainly sound like it's designed to appeal to the C crowd.

Re: Mitigating Memory Safety Issues in Open Source Software

#112

Post by ragnese »

bluGill wrote: post #46
wtallis wrote: post #19

Earlier quoted context omitted.

The main strength of a memory-safe language is that the safety mechanisms are opt-out, not opt-in: you can confine the unsafe behavior to a small, manageable portion of the codebase. And trying to "fix" C to become a memory-safe language would probably just result in something like a Rust dialect that merely bears more superficial resemblance to C. In any case, thorough re-writing of existing codebases would be requi…

I would call C++ a memory safe language that has more than a superficial resemblance to C. Rust makes is more obvious when/where you are intentionally opting out, but most C++ memory bugs are where someone opted out of the modern C++ way to use the C way. (including new/delete as the C way).

If C++ compilers had a default mode of rejecting code that was unsafe (any code using raw pointers or unchecked array access, I guess?), then sure- you could call it that. But as it is, no way.

Re: Mitigating Memory Safety Issues in Open Source Software

#113

Post by kazinator »

> Another analysis on security issues in the ubiquitous `curl` command line tool showed that 53 out of 95 bugs would have been completely prevented by using a memory-safe language.

That's not just a command line tool but a library, libcurl, with a command line wrapper. That library is easily used from a myriad of memory-safe languages, which is possible in part because it doesn't foist highly opinionated memory representations onto the caller.

Re: Mitigating Memory Safety Issues in Open Source Software

#114

Post by simias »

wmanley wrote: post #106
simias wrote: post #64

Earlier quoted context omitted.

To me this idea sounds a lot like "why do we need IPV6? Why not keep IPV4 and add a few bytes?" except it's effectively almost the same amount of breakage. Either you're C-compatible or you're not. Making C memory-safe by adding extra annotations to allow for static zoning/borrow checking is possible, but the churn involved is probably not much different than rewriting in a different language. See Cyclone for instanc…

> To me this idea sounds a lot like "why do we need IPV6? Why not keep IPV4 and add a few bytes?" except it's effectively almost the same amount of breakage. [DJB disagrees]( https://cr.yp.to/djbdns/ipv6mess.html ). Quote: >The IPv6 designers made a fundamental conceptual mistake: they designed the IPv6 address space as an alternative to the IPv4 address space, rather than an extension to the IPv4 address space. > Ei…

With all due respect I disagree with DJB here. I can't see how his proposal would significantly improve the current status quo. Note step one of his self-described "straightforward" transition plan (emphasis mine):

>0123456789abcdef0123456789abcdef to 192.5.6.30: The client sends a UDP packet to the .com DNS server asking for the address of www.google.com. The client software, intermediate computers, and server software have all been upgraded to handle the client's extended address.

A lot of work in this one "straightforward" step. I know that DJB is a great network engineer, so I'm willing to consider that I'm missing the point here, but at the very least I don't find this particular exposé very convincing.

>If we take this black and white approach then we must say that C++ is not C compatible just like Ada isn't C compatible.

Agreed, in a parent comment I mention C++ being effectively mostly compatible with C. But I can't really imagine how you could do something like that with a memory-safe subset of C. The changes involved are pretty thorough (you basically either need a garbage collector or a borrow checker). Things like raw pointers (especially nullable ones) can't really exist in their current form in a memory safe language.

Re: Mitigating Memory Safety Issues in Open Source Software

#115

Post by Liquid_Fire »

bluGill wrote: post #102
madmoose wrote: post #65

Earlier quoted context omitted.

> I would call C++ a memory safe language C++ is not, in any sense, a memory safe language.

Then you don't know anything about C++, only the C legacy it is built on. Modern C++ has good data structures and good memory management. To be fair actually using those features of C++ instead of the C legacy is still catching on. Most instructors aren't even teaching it. Using C in C++ is like using unsafe everywhere in rust - you can do it, but you lose all the advantages.

Even if you stick to "modern C++" and never use C-style pointers, arrays, enums or unions, it is still trivial to have memory errors in C++.

Re: Mitigating Memory Safety Issues in Open Source Software

#116

Post by nick_ »

praptak wrote: post #42
roel_v wrote: post #8

Can someone please fix the title to the original in the blog ('Mitigating Memory Safety Issues in Open Source Software'), because the current title is not at all representative of what the blog is actually saying.

Also "for rewriting popular systems in Rust" is just false. The blog is about improving memory safety and gives two pieces of software rewritten in Rust as an example. There's nothing about this effort being focused on rewriting things in Rust.

HN is like 15% pro-Rust propaganda these days.

Re: Mitigating Memory Safety Issues in Open Source Software

#117

Post by ragnese »

tediousdemise wrote: post #63

Is there a reason why some developers prefer Rust over C++? I often hear that it’s because of Cargo, but in my experience, universal build systems and package managers end up not really solving the problem they are designed to solve, and are a huge attack vector. Anyone who’s tried to deploy their own complex Maven project knows that it’s a true nightmare. C++, on the other hand, has a variety of choices for build sy…

Cargo is the least of reasons I prefer Rust. Rust APIs are much more ergonomic than C++'s, its type system is better (built-in ADTs and type classes, no null), it's obviously safer by default, it's expression-based which is just sooo ergonomic, its move semantics are enforced by the compiler, and it just doesn't have all the sharp edges of C++ (returning dangling references, implicit constructors, 57 different kinds of lvalue, rvalue, xvalue, lrxhvalue, whatever), etc.

Re: Mitigating Memory Safety Issues in Open Source Software

#118

Post by lrossi »

lrossi wrote: post #3

What is left out of the title is that they do not provide funding to the current authors/maintainers of these open source projects. Instead, they fund an organization that will rewrite these tools. Correct me if I’m wrong, but that’s my understanding of the rather terse article. I would rather have the original maintainers funded and still in control of the many pieces that form the basis of the major Linux distribut…

Replying to myself as I cannot edit anymore.

As others pointed out, it’s not clear who will do the rewrites. Based on the curl example, it might be the maintainers. It would have been great if they could state that concretely.

I’m also wondering why there’s a middle man instead of funding the projects directly, but that’s another story.

Re: Mitigating Memory Safety Issues in Open Source Software

#119

Post by duckerude »

notpygame wrote: post #75

The security information about C and curl is a bit outdated in the post, and recent research shows Rust does not solve the memory safety issue. The "recent study" quoted in the article was published at the beginning of 2019, using older data. Current vulnerability data shows that curl has very much limited the risk of memory safety issues. How many reported security vulnerabilities in the last two releases of curl? Z…

Rust does not solve the memory safety issue. It does mitigate it, and the post is about mitigation. That study finds that Rust "successfully limits memory-safety risks to the realm of unsafe code".

It also finds that Rust has novel patterns of unsafety in unsafe code. That's important! But it's fully compatible with the claim that Rust is much safer than C overall.

I don't think it ever says that the sum of safety in safe code and novel unsafety in unsafe code adds up to as much unsafety as C. The paper's overarching claims aren't quantitative.

I think you're overstating the claims of both the blog post and the study.

Re: Mitigating Memory Safety Issues in Open Source Software

#120

Post by themarkers »

theandrewbailey wrote: post #61
roel_v wrote: post #8

Can someone please fix the title to the original in the blog ('Mitigating Memory Safety Issues in Open Source Software'), because the current title is not at all representative of what the blog is actually saying.

I'm a native english speaker, and I've never seen the word "fundings" in my life. Edit: the submission title is fixed.

Might be reinventing the wheel ;D
Post reply on HN