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

561–570 of 606 posts

Re: Memory Safe Languages in Android 13

#561

Post by steveklabnik »

kaba0 wrote: post #527
steveklabnik wrote: post #518

Earlier quoted context omitted.

What is “internal assembly”? I’m not familiar with that term. Is there anything else that the various repr options don’t give you? My team at work does OS dev in Rust, and haven’t ever run into cases where Rust can’t do what we need it to do in these cases.

* inline assembly, just my brain stopped working for a sec :D Well, my specific case is writing a fast interpreter in Rust, where I would like to use elements like a stackframe from both inline asm and proper Rust code. In my first iteration I chose a dynamically sized u64 array, wrapped in a safe API, because I couldn’t be more specific. But even with known size elements the best I can do - to my knowledge - is Layo…

Ah yeah no worries :)

It’s sort of tough because I am only familiar in passing with the patterns in that type of code, but Layout is an allocator API, so I’m not 100% sure why it would be used here. I’d guess that if I was doing something like this, I’d be casting it to and from a struct that’s defined correctly. This is one area where stuff is a little simpler than C, thanks to the lack of TBAA, though many projects do turn that off.

Re: Memory Safe Languages in Android 13

#562

Post by UncleMeat »

clnq wrote: post #557
UncleMeat wrote: post #546

Earlier quoted context omitted.

> Should the smart pointer not be nulled after the object is destroyed? I'm not sure what you are going for here. The way this often happens is there is some module that owns an object with a unique_ptr and references to that object are used elsewhere. But the ownership of the object is complicated so a bug sneaks in where a non-owning reference to the object gets dereferenced after the unique_ptr is deleted. You can…

There are also other smart pointers, like std::'s weak ptr and proprietary stuff. You can avoid multi-ownership problems of shared ptrs with weak pointer member variables (which only need to be turned into shared in a given {} scope). Some other problems can be solved by marking objects as pending kill without destroying them immediately and ensuring all threads finish access before actual deletion. Unreal Engine use…

Of course there are designs that help prevent bugs. Chrome is doing plenty of stuff like this but the ownership and lifetime design for something like a JIT are complex as hell and problems happen.

We've got like 30 years of people insisting that it really is possible to write safe C and C++ programs if you just follow the One True Way (TM) and its never been the case. Each new One True Way helps, but it sure as hell doesn't solve the problem altogether.

Re: Memory Safe Languages in Android 13

#563

Post by _fullpint »

100001_100011 wrote: post #345
_fullpint wrote: post #272

Earlier quoted context omitted.

I write a lot of Rust these days and unfortunately really great FP stuff is pretty damn cumbersome to write.

I found this viewpoint about FP in Rust pretty interesting. Can you elaborate?

One, the lack of support for HKT isn’t great. There are some work arounds, but they aren’t particularly safe and end up being pretty cumbersome to implement.

Another big one is while the language supports lambdas and closures, it’s highly recommended to not perform any currying.

Re: Memory Safe Languages in Android 13

#564

Post by peoplefromibiza »

fiedzia wrote: post #545
peoplefromibiza wrote: post #488

Earlier quoted context omitted.

> Rust would stop Heartbleed for example, and that was one of huge vulnerabilities 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. Heartbleed could have been easily fixed if the companies profiting from using OpenSSL donated a few more eyes to look at the code. Similarly to what happen…

> 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 no intention of going back, but dogmatic programmers that believe in "saviours" are a real mistery to me.

The same people forgetting to free a resource are the same people that will forget to sanitize some input, meaning all of us make mistakes and will keep making them, in any language and those mistakes will be abused by some malevolent actor.

Google problems are not everyone's problems.

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.

Re: Memory Safe Languages in Android 13

#565

Post by maccam94 »

LAC-Tech wrote: post #82
Mesopropithecus wrote: post #75

Earlier quoted context omitted.

> Rust does require structuring programs in a "Rust way" to avoid fighting with things it can't prove to be safe. That was my concern that I had when I started learning the language. I think it is true, but I was surprised how quickly I managed to get used to the Rust way.

I'm surprised at how slowly I'm getting used to it! I mean I've improved but I still have a lot of "wtf" moments. End up doing a lot of deep copying and heap allocations just to shut the compiler up, which makes me question just how "zero cost" the safety is.

Are you able to store that data in reference-counted RC/ARC types? Those can help you avoid dealing with lifetime issues, though you'll still have to think about mutability and concurrency.

Re: Memory Safe Languages in Android 13

#566

Post by lynndotpy »

berkut wrote: post #226
lynndotpy wrote: post #213

Earlier quoted context omitted.

Security is absolutely a concern in these areas (except maybe offline graphics). In my experiences with university HPC clusters, security is very important because you have a lot of young students with no Unix experience accessing the resources. We've had real compromises of individual research machines because of this. This happens all the time at research universities, but it's not always public. In one public exam…

That's security of the generic infrastructure the code's running under though is it not? It's not security of say CUDA kernel code being executed on a GPU? I'm talking about the actual HPC algorithm code heavily priortising performance (or in some cases memory efficiency), at the expense of pretty much everything else (other than correctness, obviously).

Ah, I think I understand what you mean. Let me rephrase:

Students writing code are not prioritizing security or performance. (I've seen FEM analysis written in Matlab, large neural-networks written in nearly-pure Python, etc.) The real 'performance' priority is human time, at the cost of everything else. To this extent, extra security "for free" from memory safety is nice.

There are exceptions, of course. The 2012 AlexNet breakthrough was a result of performance-engineering, for example. But generally speaking, publish-or-perish rewards neither optimizing performance nor optimizing security.

So, students will be installing Docker images (which have super user privileges), sudo running bash scripts, sudo installing pip or npm packages. I've seen students replace libraries (including CUDA) with modded binary blobs from researchers from other universities. All to save time in pursuit of ~~interesting~~ publishable results.

These are horrible things I've seen during my time in academia. We (should) do virtualization, jails, firewalls, etc. to insulate the rest of us from these horrible things. (I'd add "keep machines offline", but that's rare, and even rarer because of the pandemic.) This insulation is imperfect, and many of those imperfections are due to memory safety flaws.

Re: Memory Safe Languages in Android 13

#567

Post by Rusky »

mk89 wrote: post #421
Rusky wrote: post #319

Earlier quoted context omitted.

I think it is just as (un)true that Rust programmers don't need to worry about those errors, as it is that Java/Python/JS/whatever programmers don't need to worry about them. And this is really the only meaning for "memory safe" that can apply to anything that runs on real world hardware and operating systems. It's always conditional on the correctness of the compiler checks, the runtime, and in Rust the unsafe block…

> And I don't think people really expect to be immune to bugs in their compiler or runtime just because the language is "safe"! I would really ask you to rethink what people think and expect. Maybe you work for a company with lots of people who understand this kind of things. I am more used to people who just jump on the "oh this lib does this, let me use it". Everywhere I read only Rust is memory safe, you don't hav…

I am a bit confounded by this comment- if people are pulling libraries with no concern for the maintenance or security implications, that's going to be an issue regardless of memory safety!

The lowest common denominator of every team in the world simply cannot be our target audience for every technical term we use. There is a minimum level of background people need to learn before they can be effective, and I don't believe we can get around that just by using maximally-pedantic language everywhere all the time.

If you are actually encountering misleading Rust materials, I certainly support any efforts to clarify them, but in my experience people are actually pretty good about that already. TFA here has an entire section on `unsafe` in Rust, for instance.

It is helpful to have some way to refer to this approach to language design, and "memory safe" (like "type safe") has a long history with a precise definition. But perhaps you have some alternative "forum thread friendly" term in mind that you would prefer over "memory safe"?

Re: Memory Safe Languages in Android 13

#568

Post by stouset »

mk89 wrote: post #417
stouset wrote: post #333

Earlier quoted context omitted.

Why shouldn’t this kind of inconsistency be pointed out? I’m happy to believe GP didn’t say exactly what they intended to or simply misremembered what exactly they said previously. It’s certainly something I’ve done before in an online conversation. And when it’s happened to me I’ve appreciated having it pointed out explicitly so I could clarify what my thoughts actually were. Often it’s because I misstated my opinio…

You might be right, it's probably just easier to ask :) So, when I wrote the message I was really physically and mentally tired, I wrote from the phone which unfortunately doesn't always help me write 100% consistent sentences. Finally I just used wrong wording. As I mentioned in another comment, the improvement is clear and it's the new way forward. In my opinion it simply doesn't solve all memory safety issues, and…

In my experience, almost no Rust programmers believe that it's a silver bullet that results in 100% safety. Certainly orders of magnitude fewer people than people seem to believe exists.

What it does do is drastically cut down the number of places you have to deeply audit.

Re: Memory Safe Languages in Android 13

#569

Post by burntsushi »

kaba0 wrote: post #559
burntsushi wrote: post #549

Earlier quoted context omitted.

> there is no absolute safety Now we've come full circle. I recommend you go back and read my initial comment in this thread and the comment I was responding to. You've veered far off course from there into waters in which we likely have very little disagreement of any consequence. > And Java can have surprisingly good performance Show me a regex engine written in Java that can compete with my own, RE2, PCRE2 or one…

You may be right, I’m not really disagreeing, I can absolutely stand behind this sentence of yours: > Where Rust is (somewhat although not entirely) unique is bringing this compartmentalization into a context that (mostly) lacks a runtime and garbage collection I just think that the model of “breaking down” is different between the two platforms and that might matter for some use cases.

Right, that's why I said:

> But it's not completely obvious to me that you're correct.

:-)

Which is to say, I don't know you're wrong. But it's a pretty subtle thing that requires a careful survey. And likely discussion of lots of concrete examples. It's far more nuanced than the thing I was responding to originally (not to you), which was this wrong-headed notion that Rust isn't memory safe "entirely." Because once you go down that path, the entire notion of "memory safety" starts to unravel. That is, of course Rust isn't "entirely" memory safe. Pretty much nothing practical actually is in the first place. I tried to force this issue by asking for counter-examples. The only good one I got was Javascript in browser, but that basically falls under the category of "programs in a strictly controlled sandbox" rather than "programming language" IMO.

I think this comment of mine might also be helpful, which reflects a bit on terms like "memory safety" and why they are a tricky but very common type of phenomenon: https://news.ycombinator.com/item?id=33825307

Re: Memory Safe Languages in Android 13

#570

Post by wiseowise »

Thiez wrote: post #492
maeln wrote: post #14

Earlier quoted context omitted.

I think he meant it in a way the same way that some people are still learning COBOL: a lot of critical, legacy code is written in C++ and cannot easily (or won't be for various reason) moved to another langage. Therefore, developer that can maintain a C++ codebase might become invaluable for some company.

The COBOL developers might be invaluable, but statistically their pay does not reflect this at all. Is there any reason to believe it will be different for C++, if it were to become a legacy language?

COBOL never penetrated use cases that C++ covers.
Post reply on HN