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

221–230 of 244 posts

Re: Mitigating Memory Safety Issues in Open Source Software

#221

Post by Cloudef »

wtallis wrote: post #83
trynton wrote: post #76

"bugs would have been completely prevented by using a memory-safe language" Relying on safe languages isn't going to work as the defect resides in the Memory Management Unit. You would think by now these 'integrated' 'innovators' could come up with a MMU that provides total process isolation.

Have you confused the kind of memory safety that Rust, etc. are about with the Spectre and Meltdown vulnerabilities? Or do you think that each individual array that's potentially subject to a buffer overflow in C should have been allocated by an entirely separate process ?

Plan9 sort of does the latter (crypto in its own process and so on)

Re: Mitigating Memory Safety Issues in Open Source Software

#222

Post by mccr8 »

bluGill wrote: post #201
rcxdude wrote: post #166

Earlier quoted context omitted.

This is a common viewpoint but also wrong. There's plenty of ways to invoke memory unsafety in 'modern' C++: iterator invalidation is probably the biggest source.

While you are technically correct, those who study C++ security note that those are a tiny minority of all security errors. Still an issue, but not nearly as common an issue as the ones that come from the C roots of C++.

Iterator invalidation was the cause of a Firefox zero day in 2016. https://bugzilla.mozilla.org/show_bug.cgi?id=1321066

Re: Mitigating Memory Safety Issues in Open Source Software

#223

Post by mhh__ »

WalterBright wrote: post #220
the_duke wrote: post #212

Earlier quoted context omitted.

That's very cool to hear! As the ceator of D, how do you see the place of borrow checking in the ecosystem long term? Would you imagine most D code to be written against the borrow checker in the future, with transparent convenience for GC types? Or would it remain a somewhat niche feature for domains that can benefit?

The borrow checker in D can be used incrementally, like functional programming, on a function-by-function basis. It can be used where it makes sense to use it. (If only the GC is being used, the borrow checker isn't needed.) Being incremental, it won't require redesigning the program to make use of it. I don't know how pervasive its use will become, but I expect its use will steadily increase.

One thing that I think we'll have to deal with at some point in the next two years or so is that although using the borrow checker will be incremental on (say) functions, the actual design of said borrow checker needs to be more integrated than incremental i.e. currently we can catch lifetime related bugs but you can't properly express (say) invalidating a pointer into a container by calling popFront.

Re: Mitigating Memory Safety Issues in Open Source Software

#224

Post by pjmlp »

tptacek wrote: post #191
saagarjha wrote: post #186

Earlier quoted context omitted.

Oh, I'm not suggesting that they will use Go–they will use C and I'm just responding to you saying that it is difficult to find situations where Rust is unworkable.

The premise of this story is that ISRG is going to secure funding to essentially bribe people (my words, and I think it's a very good project) to not keep critical software in C anymore. My guess is what will happen in the cases where Rust is unworkable is that there will be less-secure forks for the obscure platforms.

Rust is not the only option.

F-Secure has been using TamaGo for bare metal on their secure USB keys.

MeadowLabs is using .NET with a tiny C++ hardware glue for IoT.

Aicas and PTC are still in business delivering real time bare metal Java stacks.

Astrobe is still in business selling Oberon compilers for embedded development.

MikroElektronika is still in business selling Pascal and Basic compilers for embedded development.

And then there are those 5 surviving Ada compiler vendors, one of them open source.

Finally, if there is no way around having to use C, there is no reason not to use C++ instead other that anti-C++ hater religion.

Unless we are talking about UNIX clones, thanks to them C will still be around for several decades to come anyway.

Re: Mitigating Memory Safety Issues in Open Source Software

#225

Post by pjmlp »

gpm wrote: post #218
kzhukov wrote: post #216

Earlier quoted context omitted.

What I don't really like in cargo is its' overcentralized and author-centric approach. What if some of your dependencies relies on the crate, which author doesn't support anymore and doesn't even accept patches? You will basically have to maintain a fork either with a different name (because you can't push it to crates.io) or have a patched version which you also can't push and have to manually update every Cargo.tom…

I'm not entirely thrilled with the cargo solutions here, but when I compare them to the options in other languages I think they're adequate. If you're making a small change, you use a [patch] section in the Cargo.toml for your workspace if you're using one, or the Cargo.toml for your binary/.so/.a if you're not, and it will cause your entire dependency tree to use your forked library. You don't need to fork the entir…

When I started programming, static linking was the only way of packaging software in mainstream computing, if it was so superior we wouldn't have moved away from it.

Also although we are talking about open source here, in many OSes, and enterprises, distribution of binary libraries is a very important subject, which cargo doesn't allow for.

Re: Mitigating Memory Safety Issues in Open Source Software

#226

Post by pjmlp »

tptacek wrote: post #175
jedisct1 wrote: post #41

Earlier quoted context omitted.

This.

Not really, no: * Languages with significant runtimes are going to be rejected by project maintainers; nobody is going to rube-goldberg a GC into an existing project just to replace a risky component when the option not to do that exists. * Languages with insignificant adoption are going to be rejected by project maintainers because why take a flyer on an unknown quantity (not just technically but in terms of where t…

F-Secure has decided otherwise for bare metal secure firmware.

Re: Mitigating Memory Safety Issues in Open Source Software

#227

Post by pjmlp »

rational_indian wrote: post #79
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…

>Anyone who’s tried to deploy their own complex Maven project knows that it’s a true nightmare. Maven != Cargo > C++, on the other hand, has a variety of choices for build systems. None of which even remotely approach the ease of use and maintainability of the Cargo build system. > once you need to build something that the default build system doesn’t support, you’re in big trouble. Cargo can build arbitrary dependen…

> Maven != Cargo

Indeeed, Maven supports binary libraries.

Re: Mitigating Memory Safety Issues in Open Source Software

#228

Post by tptacek »

pjmlp wrote: post #224
tptacek wrote: post #191

Earlier quoted context omitted.

The premise of this story is that ISRG is going to secure funding to essentially bribe people (my words, and I think it's a very good project) to not keep critical software in C anymore. My guess is what will happen in the cases where Rust is unworkable is that there will be less-secure forks for the obscure platforms.

Rust is not the only option. F-Secure has been using TamaGo for bare metal on their secure USB keys. MeadowLabs is using .NET with a tiny C++ hardware glue for IoT. Aicas and PTC are still in business delivering real time bare metal Java stacks. Astrobe is still in business selling Oberon compilers for embedded development. MikroElektronika is still in business selling Pascal and Basic compilers for embedded developm…

Yeah none of that is going to happen. People aren't going to rewrite major open source projects in Oberon, or specially hosted .NET, or custom JVMs, or Ada. ISRG isn't going to arrange funding for things to be rewritten in another memory-unsafe language, so C++ is right out. Stuff is going to get rewritten in Rust. Sorry!

That sounds snarky, I know. I promise, I'm not being snarky, and, again: it ain't my first choice (it'll be fine though).

Re: Mitigating Memory Safety Issues in Open Source Software

#229

Post by pjmlp »

tptacek wrote: post #228
pjmlp wrote: post #224

Earlier quoted context omitted.

Rust is not the only option. F-Secure has been using TamaGo for bare metal on their secure USB keys. MeadowLabs is using .NET with a tiny C++ hardware glue for IoT. Aicas and PTC are still in business delivering real time bare metal Java stacks. Astrobe is still in business selling Oberon compilers for embedded development. MikroElektronika is still in business selling Pascal and Basic compilers for embedded developm…

Yeah none of that is going to happen. People aren't going to rewrite major open source projects in Oberon, or specially hosted .NET, or custom JVMs, or Ada. ISRG isn't going to arrange funding for things to be rewritten in another memory-unsafe language, so C++ is right out. Stuff is going to get rewritten in Rust. Sorry! That sounds snarky, I know. I promise, I'm not being snarky, and, again: it ain't my first choic…

In what concerns Microsoft, the official security guidelines are .NET, Rust and C++ (with Core Guidelines).

As for the other platforms, and what Google is paying for, lets see where the bribe drives people into, after all from your point of view Google should rewrite gVisor and everything k8s as well.

Re: Mitigating Memory Safety Issues in Open Source Software

#230

Post by whateveracct »

mrkeen wrote: post #213
whateveracct wrote: post #146

Earlier quoted context omitted.

i just write all my projects in Haskell on any platform so the RTS is a given (or the RTS isn't present at execution time since the executable is generated from a Haskell eDSL) it's truly superior to any other programming language (5+ years of pro experience talking), so why waste my time with the manual labor of imperative programming?

I write 90% of my stuff in Haskell. When I need speed, I used to use C, now I use Rust. > why waste my time with the manual labor of imperative programming Someone has to. https://github.com/ghc/ghc/tree/master/rts

I'd say about the same. C has its place, and the GHC RTS is a great example.
Post reply on HN