Live data from Hacker News

GrapheneOS finds Bluetooth memory corruption via ARM MTE

grapheneos.social

71–80 of 228 posts

Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE

#71
post #37

Earlier quoted context omitted.

These phone cases with an integrated battery pack goes a long way towards replaceable batteries if you keep a stack of them. They probable put less strain and wear on the built-in battery too.

> They probable put less strain and wear on the built-in battery too. Nope, unless you can fore your phone to only charge to below 80% they strain the battery just as much if not more by keeping them at 100% all the time.

I don't know how they do it, but some of these cases keep the phone at below 100%.

Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE

#72
post #37

Earlier quoted context omitted.

These phone cases with an integrated battery pack goes a long way towards replaceable batteries if you keep a stack of them. They probable put less strain and wear on the built-in battery too.

> They probable put less strain and wear on the built-in battery too. Nope, unless you can fore your phone to only charge to below 80% they strain the battery just as much if not more by keeping them at 100% all the time.

My S20 has an option to limit charge to 85%. It's already a reality.

Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE

#73
post #53

Earlier quoted context omitted.

For my Pixel 7a, I searched the Developer Options menu three times and couldn't find it. Searching for Memory Tagging Extensions in Settings says it's there. Is it hidden somewhere? Edit: Nevermind, I seen it's only for Pixel 8 phones: https://news.ycombinator.com/item?id=38125379

is for Pixel 8 and above, since those have Tensor G3, which is armv9 IIUC.

Taken from the projects official Twitter they offer more than what is available by said toggle on stock:

They provide a nicer MTE implementation as part of hardened_malloc which uses the standard random tags with a dedicated free tag but adds dynamic exclusion of previous tag and current (or previous) adjacent tags. We also fixed Chromium's integration and will improve PartitionAlloc.

They also use it for their browser too using PartitionAlloc. Other Chromium-based browsers including Chrome don't use MTE since they don't really use the system allocators and have PartitionAlloc MTE disabled.

They are also continuing work on integrating more ARMv9 security features. MTE having the highest impact and being the most interesting of these features, but they're expanding usage of PAC and BTI. Android uses Clang's type-based CFI but not everywhere so BTI is still useful.

Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE

#74

Hope somebody using Graphene OS could answer: 1. Is it very challenging to install Graphene OS? Need special cables and to know a lot about jailbreaking Android devices, or will I be fine just following instructions? 2. Is it very inconvenient to use as a daily driver? How often phone just crashes and requires a few days of debugging? Will my bank app work on it?

Graphene is great, the problem is pixel phones. We need an effort to push other manufacturers to get on board.

Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE

#75
post #60

Earlier quoted context omitted.

[flagged]

I might have not caught that he tried to kill graphene os. Didn't he just say that he decided to not use gOS anymore because he thinks that the developer of gOS might have something against him personally? Anyway, I don't know a single person who stopped using gOS because of the feud between these two Gladly I might add since I have been enjoying gOS so far

[flagged]

Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE

#76
post #6

Earlier quoted context omitted.

Agreed but they do drop support for older pixel devices very very quickly which is kinda of PITA. At least the Pixel 8 is supposed to be supported 7 years.

Just a point of clarity, GrapheneOS has the same support window that Google does, so they're not dropping support earlier than the vendor. The reason they drop support is because the burden of supporting an EOL device is way, way higher, especially for a security-oriented OS.

Taking the "vendor security patch level" into account, it is impossible in some situations.

If a critical vulnerability is found in a Qualcomm modem, wifi, or bluetooth firmware, there may be scenarios where this cannot be fixed at the OS level.

Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE

#77

Hope somebody using Graphene OS could answer: 1. Is it very challenging to install Graphene OS? Need special cables and to know a lot about jailbreaking Android devices, or will I be fine just following instructions? 2. Is it very inconvenient to use as a daily driver? How often phone just crashes and requires a few days of debugging? Will my bank app work on it?

I've been very happy with GrapheneOS on my Pixel 7, for the year that I've had it.

The only inconveniences if you may call them that have been in alerting me of things naughty apps were doing.

Actually, no. One problem I've had is that external audio input via USB has not worked for me. Anyone else figure that out?

Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE

#78
post #69

I can hardly wait until mainstream hardware catches up to Solaris SPARC in 2015, or previous memory tagged architectures, to finally tame all those memory corruption issues, only written by bad skilled developers.

I tried running Solaris SPARC on my phone, but it was dog slow. Very secure though!

Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE

#79
post #60

Earlier quoted context omitted.

[flagged]

I might have not caught that he tried to kill graphene os. Didn't he just say that he decided to not use gOS anymore because he thinks that the developer of gOS might have something against him personally? Anyway, I don't know a single person who stopped using gOS because of the feud between these two Gladly I might add since I have been enjoying gOS so far

I never installed it because of who the founder is... but maybe I'm wrong and it takes someone like this to start such a project.

Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE

#80

> Android has ported a lot of the Bluetooth code to Rust. This is a demonstration of why they need to put more resources into porting the rest of the code into Rust. I like how they snuck that in there :-D As someone who spent years writing C and C++, but no experience with Rust, with this porting from C to Rust, how much refactoring is required? That might should be two different questions: 1. How closely does C tra…

I was recently trying to port a PIC microcontroller simulator from C++ to Rust as an (unfinished) experiment. Because there were lots of cyclic references (modules talking to each other over "signal busses" with callbacks,) I think I ended up fighting Rust more than it helped. It ended up requiring a lot of Box (pointers to heap) for things where I could store the data inline in C++.

My conclusion is that if you're writing a simple CLI or request-response thing, Rust is probably an easy port. More generally, if your code structure could work well with arena allocations, moving to lifetime-tagging of references isn't a big deal.

But if you're writing (admitted ugly) code with cyclic references the way a C programmer would :), Rust will feel like an uphill battle and is not the place to start. I need to start by restructuring the C++ code, moving ownership to a common parent. I think that'll make things better. Iteratively learning more about Rust, but continuing to work in C++ until the code has a better correspondance to Rust.

Edit: forgot the word simulator, and changed RefCell to Box.

Post reply on HN