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.
GrapheneOS finds Bluetooth memory corruption via ARM MTE
71–80 of 228 posts
Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE
#72Earlier 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.
Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE
#73Earlier 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.
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
#74Hope 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?
Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE
#75Earlier 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
Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE
#76Earlier 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.
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
#77Hope 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?
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
#78I 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.
Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE
#79Earlier 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
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…
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.