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

Memory Safe Languages in Android 13

security.googleblog.com

Post reply on HN
Print view View original

471–480 of 606 posts

Re: Memory Safe Languages in Android 13

#471

Post by burntsushi »

saagarjha wrote: post #311
burntsushi wrote: post #25

Earlier quoted context omitted.

Is there any practical programming language that is memory safe in its "entirety"? Python, for example, certainly is not. It has unsafe escape hatches (via ffi, at the very least). Yet, everyone I know of says and thinks of Python as a memory safe language. I do as well. > which makes it easier for developers to compartmentalize code to achieve memory-safety The problem here is that this is incomplete. Many many many…

JavaScript? It’s not typical to provide it with any access to unsafe APIs.

Someone already mentioned that. That only works if you restrict yourself to JavaScript in the browser. There's a huge ecosystem for using JavaScript outside of the browser.

Re: Memory Safe Languages in Android 13

#472

Post by jstimpfle »

gnull wrote: post #444
jstimpfle wrote: post #427

Earlier quoted context omitted.

I'm pretty confident that systems programming (you know - moving data around) is easier with raw memory access compared to managed languages.

Is this a joke? Systems programming is a lot about accessing APIs, dealing with all sorts of intricacies like interrupts, different execution contexts, and managing memory as you said. If you write in C and your program is complex enough, you will spend a lot of time just chasing segfaults and concurrency bugs and getting it to work the first time you write it. If your systems programming is in userspace, that's sort…

> Systems programming is a lot about accessing APIs, dealing with all sorts of intricacies like interrupts, different execution contexts

So now you need to make your interrupts talk to your Java objects? Is this any safer?

Is it easier to get a VM running in your kernel (probably no mean feat to do that in the first place) and you'll never get any concurrency bugs? And if you reduce memory bugs by half, those will be easier to debug?

And you won't be annoyed that you can't guarantee to be able to link objects in queues (because of allocation failure) and access them with generic code to copy data, link/unlink them, and so on? You're fine to pay for callbacks and interfaces everywhere, both in terms of runtime and performance as as maintenance headaches?

I'm asking incredulously, but seriously. Because frankly I've never looked at a project like MirageOS or whatever. But given real world evidence of what has survived, I don't see why you should assume I'm joking.

That you can't debug a "bare metal" kernel isn't quite true, either. But sure, the more complex a system becomes, the more contemplation it requires to figure out problems. This is universally true, but you can't simply discuss complexity away. And adding complex object models on top without consideration doesn't make your task easier just like that.

Re: Memory Safe Languages in Android 13

#473

Post by ilyt »

awesomeMilou wrote: post #361
p-e-w wrote: post #356

Earlier quoted context omitted.

> NOTE: down to 36% from 65% because of moving from C++ to Rust and other memory safe languages Imagine if in any other field, a process or technology were developed that cuts the number of high-severity issues in half. For example, a modification to the standard anesthesia protocols that demonstrably reduces anesthesia-related fatalities by 50% in clinical practice. And now imagine, in reaction to this revolutionary…

That seems to be a very limited view on the issue, since the stakes with ansthesia related issues are much higher (a human life).

I assume you're not familiar with https://en.wikipedia.org/wiki/Therac-25 ?

Re: Memory Safe Languages in Android 13

#474

Post by peoplefromibiza »

p-e-w wrote: post #368
dralley wrote: post #365

Earlier quoted context omitted.

Well, not exactly. There have been plenty of advancements in bridge / highrise construction over the past 100 years, but in practice we don't go around tearing down old infrastructure that is still functional because it was built with outdated designs and technologies, even when it could theoretically save lives. Buildings get "grandfathered" into meeting code all of the time. Software is not terribly different from…

This isn't primarily about replacing existing software. There are plenty of engineers that argue for continuing to use memory-unsafe programming languages. New projects written in C are being started every day. This is the exact equivalent of physicians continuing to use unsafe medical procedures, and what's worse, many of those engineers defend their dangerous practices by claiming there is no real danger in the fir…

> There are plenty of engineers that argue for continuing to use memory-unsafe programming languages

And why do you think it's wrong, per se?

> This is the exact equivalent of physicians continuing to use unsafe medical procedures

You mean with different safety tradeoffs?

Because what you propose is exactly like forcing very expert physicians to switch to a procedure they are novice of and that it's not been battle tested like the old one, that proved to be very effective in most cases.

It's the same reason why patients prefer to be treated with established procedures and to undergo experimental treatments they need to sign a document that proves their informed consent.

Re: Memory Safe Languages in Android 13

#475

Post by ilyt »

peoplefromibiza wrote: post #466
lolinder wrote: post #116

Their notes about vulnerability severity are particularly interesting. Defenders of C/C++ frequently note that memory safety bugs aren't a significant percentage of the total bug count, and argue that this means it's not worth the hassle of switching to a new language. Google's data suggests that while this is true, almost all severe vulnerabilities are related to memory safety. Their switch to memory-safe languages…

> Defenders of C/C++ frequently note that memory safety bugs aren't a significant percentage of the total bug count Well, first of all, this is said but not proven. But it's easy to prove that memory safety bugs are not a significant percentage of the total number of bugs, even Google agrees. Vulnerabilities are not the same thing as bugs, a vulnerability like spectre or meltdown are not due to a bug in the software,…

> Vulnerabilities are not the same thing as bugs, a vulnerability like spectre or meltdown are not due to a bug in the software, have an ubiquitous immediate impact on 100% of the devices and are much harder to fix or mitigate, sometimes it's could even prove impossible.

Using language-independent bug example in discussion about language-caused bug vectors isn't exactly honest.

Rust would stop Heartbleed for example, and that was one of huge vulnerabilities

Re: Memory Safe Languages in Android 13

#476

Post by throw827474737 »

galangalalgol wrote: post #392
j16sdiz wrote: post #381

Earlier quoted context omitted.

In my experience, a good, auto, code formatter helps alot. You can’t hide a semi colon from code formatter.

Are you suggesting a code formatter as a mechanism for static analysis? There are really good tools like coverity, and free ones like cppcheck and clang-tidy that will catch that and so much more. Using c++ without cppcheck and clang-tidy in your cmake and pipeline is like leaving the seat up. It takes so little time, and the benefits to others is great. That said, they won't catch a ton of memory and thread safety i…

If it was about a semicolon it even sounds more like running with not all warnings on. C++ is "bad" (shorting a lot) due to its compatibility being able to also compile last centuries code.. but if today on active code bases you are not even running with at least that, why would you ever switch to Rust?

And full agree, all what cppcheck does imo should have long gone into the warning suite, and Werror and Wall should be the default..

Re: Memory Safe Languages in Android 13

#477

Post by ilyt »

Tuna-Fish wrote: post #327
clnq wrote: post #294

Earlier quoted context omitted.

Programming languages are tools for a job. As the saying goes, a bad workman blames his tools. It's not worth taking anyone who blames defects on a programming language too seriously, whether it's Google or not. Modern C++ has many memory safety features. If a company has learned that its people fail to use them, then bad for them. Of course, there are languages that abstract memory safety to the point that they elim…

> As the saying goes, a bad workman blames his tools. It's not worth taking anyone who blames defects on a programming language too seriously Are you serious? A bad workman blames his tools, because workmen are reponsible for their tools . A large part of being a good workman is identifying what tools are good and using them. And C++ is a terrible tool for any task where you are not forced to use it because of existi…

>> As the saying goes, a bad workman blames his tools. It's not worth taking anyone who blames defects on a programming language too seriously

>Are you serious? A bad workman blames his tools, because workmen are reponsible for their tools. A large part of being a good workman is identifying what tools are good and using them.

Also C/C++ made into real life tools would be OHSA violation on OHSA violation in real world

Re: Memory Safe Languages in Android 13

#478

Post by ilyt »

mamcx wrote: post #309
clnq wrote: post #294

Earlier quoted context omitted.

Programming languages are tools for a job. As the saying goes, a bad workman blames his tools. It's not worth taking anyone who blames defects on a programming language too seriously, whether it's Google or not. Modern C++ has many memory safety features. If a company has learned that its people fail to use them, then bad for them. Of course, there are languages that abstract memory safety to the point that they elim…

> As the saying goes, a bad workman blames his tools. And a good workman put his old/obsolete/dangerous/etc tool behind when something better show up. The bad workman, instead, continue blaming his tools, when the problem is that he CONTINUE using bad tools, anyway!. P.D: I learn about mechanical engineering. Get rid of bad tools fast is like key around that...

First rule of tool buying, never buy the cheapest for the safety-related tools. C/C++ IS the cheapest

Re: Memory Safe Languages in Android 13

#479

Post by throw827474737 »

raggi wrote: post #347
blub wrote: post #293

Earlier quoted context omitted.

They’re not saying that C++ can or can’t be saved. And there’s no “they”, there are hundreds of teams with different expectations and policies. You’re merely reading what you want between the lines.

True, but what is said is: We continue to invest in tools to improve the safety of our C/C++. Over the past few releases we’ve introduced the Scudo hardened allocator, HWASAN, GWP-ASAN, and KFENCE on production Android devices. We’ve also increased our fuzzing coverage on our existing code base. Vulnerabilities found using these tools contributed both to prevention of vulnerabilities in new code as well as vulnerabil…

They "believe" the major shift is due to Rust, while they continously improve also their C++ tools, and the count in also all violations (even mabe more theoretical ones?) found by those .. I have no doubts about the actual claim, but especially this quite sounds like they may have made more out of this correlation==causation than there maybe is, I believe ;)

Re: Memory Safe Languages in Android 13

#480

Post by [deleted] »

heather45879 wrote: post #251
Mesopropithecus wrote: post #78

Earlier quoted context omitted.

As somebody who appreciates Lisp, I feel your pain. As somebody who also appreciates Rust, I'm curious, what is your baseline?

Good design theory. https://www.doverbooks.co.uk/point-and-line-to-plane Consider h::i::j::k versus h.i.j.k Two :’s is an extremely loud combination of visual elements compared to the subtle point. :: drags the eye away from the content and says “look at me oscillate” In addition, humans group similar visual elements together so a combination of anything::doesnt::matter::what::between::clumps it is impossible to esca…

[deleted]
Post reply on HN