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

581–590 of 606 posts

Re: Memory Safe Languages in Android 13

#581

Post by pjmlp »

tialaramex wrote: post #580
pjmlp wrote: post #499

Earlier quoted context omitted.

No, it is about alignment and packing, you use StructLayout attribute alongside LayoutKind and FieldOffsetAttribute. https://learn.microsoft.com/en-us/dotnet/api/system.runtime.... You main issue was how structures arrange their fields. Also regarding arrays and structs, as of C# 7 you can use fixed to declare static arrays inside structs, however these structs need to be marked as unsafe.

> as of C# 7 you can use fixed to declare static arrays inside structs, however these structs need to be marked as unsafe. That is exactly what I was talking about.

Ah ok, somehow misunderstood that.

However there are actually good reasons for it to be unsafe, although it is debatable if that alone should be it.

One is due to the interactions with the GC, in case it moves the data and there are references to its elements, and stack size.

One way to get around it is to use AoS instead of SoA, which is any the best option if performance is the ultimate goal.

Re: Memory Safe Languages in Android 13

#582

Post by lalaithion »

tulio_ribeiro wrote: post #578
lalaithion wrote: post #289

Earlier quoted context omitted.

I haven't actually been able to find an example program where Swift violates memory safety in a multithreaded environment; I'd love to see an example.

To clarify, Swift is considered memory safe in single-threaded environments, but additional steps may be necessary to ensure memory safety in multi-threaded environments. This means that if you are writing Swift code that runs on a single thread, you can be confident that it will not suffer from common memory-related bugs. However, in a multi-threaded environment, multiple threads can access the same memory simultane…

It hasn’t, but not because that isn’t a great explanation.

I’m not looking for an explanation; I understand the theory. I’m just not super familiar with Swift — I’m looking for an example program that has a (potential) data race which leads to memory y safety.

Re: Memory Safe Languages in Android 13

#583

Post by nickm12 »

mk89 wrote: post #418
nickm12 wrote: post #367

Earlier quoted context omitted.

"Memory safe to me means -> it just can't happen. That's it." I'd suggest rethinking this definition. You are always at the mercy of the lower-levels of your system, both in the runtime and the compiler. By this definition, nothing is memory-safe, since it is possible for your code in a "memory safe" language to encounter memory-safety issues in its runtime or the operating system. Memory-safe means the bug won't hap…

> By this definition, nothing is memory-safe, since it is possible for your code in a "memory safe" language to encounter memory-safety issues in its runtime I am trying not to be extreme here, and of course I agree we objectively can't guarantee 100% safety, especially what's happening outside our code. However, importing a library happens within our code , it's in our executable, even if you don't write 90% of what…

>As far as I know, the JVM checks at runtime for overflows, dangling pointers, etc. so ... I only have to worry about using a good operating system...

No, you have to worry about your Java runtime too. The JRE has hundreds of thousands of lines of C++ and can have memory safety issues:

https://www.cvedetails.com/vulnerability-list/vendor_id-5/op...

> So what happens when Rust replaces a major component in some important framework or library ... but actually it's vulnerable to some weird CVE because of some unsafe calls under the hood?

You have a memory safety issue. Shit happens. If you are using Java, your runtime or OS can have a memory safety bug. If you are using Rust, the compiler, a library you consume, or the OS can have a memory safety bug.

The purpose of Rust is to reduce the surface area where such bugs can hide. In Rust, that surface area is the compiler and unsafe code. Well-written Rust minimizes unsafe code and audits it carefully, precisely because it is understood that this is where memory safety issues are most likely to hide.

The goal of Rust is to enable these low level components, like the JVM, to be written in a memory-safe language too.

Re: Memory Safe Languages in Android 13

#584

Post by nickm12 »

modshatereality wrote: post #560
nickm12 wrote: post #360

Earlier quoted context omitted.

"...wasting how many dev-years rewriting it" It sounds like you didn't read the blog post. The whole point is that they are not rewriting code, but writing new code in memory-safe languages (including "niche" languages like Java). This strategy is paying off with fewer severe vulnerabilities due to memory safety bugs.

>It sounds like you didn't read the blog post. where did you get the impression they are not rewriting code in rust? because the author cited some other blog post saying they should focus on new code and not rewriting it? How does that translate to "The whole point is that they are not rewriting code," ??? Obviously they're going to be rewriting whatever they see fit. If YOU actually read the article you would have s…

The article says that their focus should be on "new code, not rewriting existing components" and that Rust code is used in "new functionality and components".

Yes, one is named "keystore2" but you don't seem to actually know anything about it (nor do I). It seems doubtful to me that they would rewrite a perfectly working component in Rust just for fun. Most likely the original keystore, whatever language it was written in, was not meeting its requirements and needed to be replaced.

Re: Memory Safe Languages in Android 13

#585

Post by jstimpfle »

gnull wrote: post #575
jstimpfle wrote: post #472

Earlier quoted context omitted.

> 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…

I have a really hard time following anything you say here. How did we start talking about Java and VMs? Is this some sort of strawman argument? > But sure, the more complex a system becomes, the more contemplation it requires to figure out problems Strawman again? I wasn't talking about complexity. I said that the more "systems" your programming is, the higher is the cost of memory safety bugs.

> How did we start talking about Java and VMs? Is this some sort of strawman argument?

Is it a strawman if my comment was in response to "managed languages"?

> Strawman again? I wasn't talking about complexity. I said that the more "systems" your programming is, the higher is the cost of memory safety bugs.

For clarity, you spoke about the cost of debugging of memory bugs. And I said, it's universally true that programs are harder to debug the more "systems" they get. The reason is that it typically isn't sufficient to simply trace an individual thread anymore. "Logical tasks" are served over a number of event handlers executed in various (OS) threads.

It's not first and foremost a refutal of what you said. But an observation that I even placed in opposition to my other statement that it's not quite true that you can't use debuggers with kernels. FWIW and so on. I don't get why you are calling "strawman" repeatedly, and don't get the aggressive tone of your comments.

Re: Memory Safe Languages in Android 13

#586

Post by UncleMeat »

humanrebar wrote: post #573
UncleMeat wrote: post #536

Earlier quoted context omitted.

I assure you that "fix vulns caused by memory safety issues through some means other than a total language shift" is not boring work, but the sort of problem that will happily get people promoted to L8. It is just hard as hell . One of the people most involved in the systems described in the blog post that are used to harden the C++ side of things is a L9 here.

I more meant the mid range engineer work to just buckle down, test, and fix things. As in, just owning and cleaning up a lot of important projects, including third party ones. Designing the ultimate everything sanitizer with zero performance overhead would surely be impressive even at Google. Especially if it was actually adopted across the org.

But "buckle down and own it" doesn't actually prevent vulns in any sort of systematic way.

And I assure you that, despite the memes, code health efforts do end up with promos here. The org responsible for third_party and large scale code health had above average promo rates for ages.

Re: Memory Safe Languages in Android 13

#587

Post by fiedzia »

peoplefromibiza wrote: post #564
fiedzia wrote: post #545

Earlier quoted context omitted.

> using a low budget project with few developers maintaining one of the most used libraries in the whole World as an example of non memory safe languages perils is not exactly honest Why? That's the situation of enormous amount of code people use.

because Log4j is part of that enormous amount of code you talk about and it's probably used by much less experienced programmers on average, because Java it's safe by design, isn't it? Anyway heartbleed was discovered after many years, let's wait the same many years and see what kind of bugs we'll find in code written today with different languages. Full disclaimer: I do not write C code since long time ago and have…

> all of us make mistakes and will keep making them, in any language

.. unless said language makes making those mistakes difficult or impossible. Sanitizing input for example has not been an issue for me for decades, as every framework I used handles that by default, I'd have to work extra hard to make a mistake there.

> Google problems are not everyone's problems.

In this case they are. Not only memory safety is an issue for many codebases that have at least some C somewhere, but also because Google products are used by milions.

> Goggle's solutions to problems are not everyone's solutions to the same problems. > Assuming that what Google says is applicable everywhere is at best naive

Any other time I'd agree with you, but I don't see anything Google-specific here.

Re: Memory Safe Languages in Android 13

#588

Post by SleepyMyroslav »

raphlinus wrote: post #68
cyber_kinetist wrote: post #18

Earlier quoted context omitted.

Rust (despite the common understanding) is not a memory-safe language in its entirety. It is a language designed to have a strict division of safe/unsafe which makes it easier for developers to compartmentalize code to achieve memory-safety.

The blog speaks to this explicitly, in the "what about unsafe Rust" section. The tl;dr is that the number of unsafe sections is a small fraction of the total code size, and it's much easier to audit the usage of unsafe, as the reason to justify it is focused. Thus, the use of unsafe in Rust is not a significant driver of actual vulnerabilities. I think this has always been the goal, but it wasn't obvious at the outse…

disclaimer. I am sympathetic to the cause. I think Android needs to address security since they are processing personal data. I like how Rust community tries to educate others on what 'memory safety' is and is not.

But i am completely baffled by arguments that count number of unsafe blocks or code lines. Like this:

>the number of unsafe sections is a small fraction of the total code size

Code execution combinatorial effects makes number of sections or code size completely useless metrics to judge security. They do help mechanical part of auditing security in sense that they help to locate things. But locating things was never enough to judge if security is there.

Re: Memory Safe Languages in Android 13

#589

Post by timbit42 »

p-e-w wrote: post #356
yosefk wrote: post #199

Earlier quoted context omitted.

It's even worse. The majority, not of all bugs, but all vulnerabilities (of all severities) do come from memory safety bugs. TFA: "For more than a decade, memory safety vulnerabilities have consistently represented more than 65% of vulnerabilities across products, and across the industry." On top of that , memory safety vulnerabilities are disproportionately high severity: "Memory safety vulnerabilities disproportion…

> 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…

More than a decade? It started back in the 1970's when Pascal and C were duking it out. Early programmers were mathematicians and they took their craft seriously, including safety. They designed Algol which Pascal and C came from but Pascal had the safety and C didn't. C won the battle because programmers felt saving a few CPU cycles was more important than safety. Unfortunately, Pascal had a few other issues that kept it from beating C. Wirth later came out with Modula-2 in the late 1970's, which was vastly superior to C, but it was too late to compete with C's popularity. We've been hamstrung by C and its derivatives ever since. The importance of safety became much more apparent when networking became popular but there was no turning back at that point. Now, finally, 50 years later, Rust is pulling us back toward safety in a C-syntax language.

Re: Memory Safe Languages in Android 13

#590

Post by faitswulff »

saagarjha wrote: post #323
faitswulff wrote: post #205

No mention of Carbon among the new memory safe languages. I wonder what inside baseball is at play with language selection.

Carbon is not memory safe, not production grade, and also designed somewhat away from the Android team at the moment.

Ah yes, I'd forgotten about it not being memory safe. Thanks!
Post reply on HN