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

591–600 of 606 posts

Re: Memory Safe Languages in Android 13

#591

Post by heather45879 »

nindalf wrote: post #377
heather45879 wrote: post #251

Earlier quoted context omitted.

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…

> look at me oscillate I'm curious, are you dyslexic? Seeing letters move is generally something that people with dyslexia complain about.

I’m not dyslexic actually. Just thinking in terms of good user experience. A lot of the issues with C syntax is that it’s largely designed to make it easier for compiler writers.

I feel like Rust has similar pitfalls in that vein—instead of defining the user experience first, they went for a symbol that is not used elsewhere—making it easier on the engineers while satisfying the “functional requirement” of namespaces.

So—Rust will not be the language-to-end-all-languages because it is not beautiful enough. Perhaps it is almost there in functionality, but i foresee a problem with any language’s longevity unless it’s literally perfectly thought-out user experience.

I’d love to jump on the hype train with Rust but it’s not really that exciting. It doesn’t really feel all that natural. Well-thought-out user experiences should feel natural through-and-through.

Re: Memory Safe Languages in Android 13

#592

Post by peoplefromibiza »

fiedzia wrote: post #587
peoplefromibiza wrote: post #564

Earlier quoted context omitted.

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…

> unless said language makes making those mistakes difficult or impossible

You're missing the point [1]

(or I was unclear)

Yes, improvements in neuro surgery can save lives, but the bulk of preventable deaths it's in human mistakes [2] that are almost impossible to make impossible.

Just like the majority of the bugs are not prevented using rust, just a minority of them, which are also arguably the hardest to find and exploit, while a SQL injection can be exploid by a script kiddie with average IQ.

[1] https://portswigger.net/daily-swig/mastodon-users-vulnerable...

[2] The three risk factors most commonly leading to preventable death in the population of the United States are smoking, high blood pressure, and being overweight.

Re: Memory Safe Languages in Android 13

#593

Post by saagarjha »

burntsushi wrote: post #471
saagarjha wrote: post #311

Earlier quoted context omitted.

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.

It’s not very useful to talk about the memory safety of languages as a whole without looking at specific implementations. JavaScript in a browser is memory safe. JavaScript with access to /proc/mem is no longer memory safe. C on most hardware is not memory safe. C running on the abstract machine itself can be.

Re: Memory Safe Languages in Android 13

#594

Post by saagarjha »

gnull wrote: post #574
Sirened wrote: post #470

Earlier quoted context omitted.

har har :) It's an ergonomics thing, not a "can't" issue. There is a reason I called out Swift in particular—their "unsafe" APIs are so horrid to use that they make you regret doing unsafe things in the first place. Plus, throw in FFI and now you've got an even worse problem because not only are you forced to use the unsafe types, but often a lot of the critical APIs you need to interface with (in *OS exploitation, m…

I still don't understand why would you prefer raw memory manipulation to bytestring manipulation. If you want, just make a Swift library that will implement the memory like you want but without unsafe raw access (but just a few methods over a byte array). Back in the days when I did CTFs, I used Python for writing binary exploits, never C. https://github.com/hellman/libformatstr You can do something like this, no nee…

Swift has the advantage that it can directly “speak” C, without any indirection needed. (C can already do this of course.) In particular operations like scanning an address space for things, easily expressing the layout of something, and so on are much easier to do in these languages. In theory you could do the same in Python but it’s often not worth the effort.

Re: Memory Safe Languages in Android 13

#595

Post by saagarjha »

lalaithion wrote: post #571
saagarjha wrote: post #317

Earlier quoted context omitted.

Data races in Swift violate memory safety. That’s why you get EXC_BAD_ACCESS crashes from live data out of them.

I don't disbelieve this fact; I'd just like to see a sample program that demonstrates it.

  $ swiftc -
  import Dispatch
  
  var array = [Int]()
  
  DispatchQueue.global().async {
      while true {
          array.append(Int.random(in: .min...(.max)))
      }
  }
  
  DispatchQueue.global().async {
      while true {
          let range = 0..

Re: Memory Safe Languages in Android 13

#596

Post by zeroc8 »

pkolaczk wrote: post #463
zeroc8 wrote: post #428

Earlier quoted context omitted.

Yup, was quite surprised by this too, I was kind of expecting that most of Java's lunch would have been eaten by Kotlin by now.

Scala hasn't eaten Java's lunch, so how Kotlin could?

Well, only talking about Android here. And Scala is a totally different beast anyway.

Re: Memory Safe Languages in Android 13

#597

Post by burntsushi »

saagarjha wrote: post #593
burntsushi wrote: post #471

Earlier quoted context omitted.

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.

It’s not very useful to talk about the memory safety of languages as a whole without looking at specific implementations. JavaScript in a browser is memory safe. JavaScript with access to /proc/mem is no longer memory safe. C on most hardware is not memory safe. C running on the abstract machine itself can be.

This looks like a comment in response to https://news.ycombinator.com/item?id=33820918 and not to me.

The high level idea of my original rebuke was this idea that Rust was somehow lesser because it isn't "entirely" memory safe, and that its purpose was to divide safe from unsafe. But that really misses some very big points, because the programming language implementations used to build programs virtually everywhere are similarly not "entirely" memory safe, and many many many languages before Rust divided safe from unsafe.

Notice how I modified my rebuke to include your caveat. Does my point change? Does the strength of my rebuttal change? Does anything materially change at all, other than using yet more word vomit to account for caveat? No, I don't think there's anything materially different other than more words.

I tried to sidestep all of this by using the weasel word "practical." So next time I'll just say, "any practical non-sandboxed programming language." You might still chide me for confusing "programming language" with "implementation of programming language," but I've never much cared for that semantic because the ambiguity is almost always obviously resolvable from the context.

> It’s not very useful to talk about the memory safety of languages as a whole without looking at specific implementations.

Not sure I would agree with this, but it probably depends on what you mean. We can meaningfully discuss the memory safety properties of the programming languages (not just the implementations) of Rust, C and C++. I think you have to still acknowledge the practical realities of any particular implementation that others will use to build real programs, but I contend you need not do so more than what the language design does on its own already. Because languages aren't designed in a vacuum. Even if you can build an abstract machine, for example, C was not designed to be an abstract machine. It was designed to get stuff done in the real world, and the real world influenced that design. Same for Rust.

Things like CHERI will potentially change this conversation quite a bit. I was even thinking about it when I wrote my original comment in this thread. But I think it is, at present, covered by the weasel word "practical." It isn't practical to use CHERI yet, as far as I know.

Re: Memory Safe Languages in Android 13

#598

Post by optymizer »

masklinn wrote: post #183
optymizer wrote: post #152

Earlier quoted context omitted.

what if there's no static function with that name?

There is since that's what you declared. impl Foo { // static fn foo() {} } impl Foo { // instance, owned fn foo(self) {} } impl Foo { // instance, borrowed fn foo(&self) {} } impl Foo { // instance, boxed fn foo(self: Box ) {} } impl Foo { // instance, refcounted fn foo(self: Rc ) {} }

Again, what if there is no static declaration?

    impl Foo {
        // static
        fn foo() {}
    }
Why would I need to use self to tell the compiler about an instance method? Surely the Rust compiler is smart enough to detect this case and complain if the call site is ambiguous.

Re: Memory Safe Languages in Android 13

#599

Post by [deleted] »

optymizer wrote: post #598
masklinn wrote: post #183

Earlier quoted context omitted.

There is since that's what you declared. impl Foo { // static fn foo() {} } impl Foo { // instance, owned fn foo(self) {} } impl Foo { // instance, borrowed fn foo(&self) {} } impl Foo { // instance, boxed fn foo(self: Box ) {} } impl Foo { // instance, refcounted fn foo(self: Rc ) {} }

Again, what if there is no static declaration? impl Foo { // static fn foo() {} } Why would I need to use self to tell the compiler about an instance method? Surely the Rust compiler is smart enough to detect this case and complain if the call site is ambiguous.

[deleted]
Post reply on HN