> <i>Pixels shipped a massive hardware security feature (MTE) they aren't enabling for the OS to save 3.125% memory/cache usage. It's silly. Heap MTE has near 0% perf overhead in async mode and is cheaper than increasingly ineffective legacy mitigations like SSP in asymmetric mode.</i><p>I really want to see someone from the Pixel team justifying the decision here. I really wonder what the thought process is for someone to disable such a significant security feature for negligible performance gain.
Stock Pixel may not ship with it on by default for end users, but anyone can enable developer options and enable Memory Tagging Extensions - either until toggled off, or for a single session if you're trying to test a specific app - if you do want the feature on.
GrapheneOS is so far ahead in terms of security than anything else that it makes chosing anything but pixel hardware really questionable. But I <i>REALLY</i> want replaceable batteries. Why does everything have to suck nowadays?
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?<p>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?
This is 2024. We need formally-verified operating systems, applications, and tools in the spirit of seL4 but going beyond it in rigor. Cobbling together lightly tested, over-engineered, heaving codebase systems with fragile, dangerous languages in this day and age is asking for users dying when foreign actors hack them, annoying bugs for many, and attack surface for malware and hacking generally.<p>On top of that, clean and unified UX and usable features must be provided or the engineering is all for naught.
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>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><p>I like how they snuck that in there :-D<p>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:<p>1. How closely does C translate directly over to Rust? Does Rust require some reorganization/refactoring?<p>2. How is Google approaching this? Are they trying to closely "translate" it as much as possible, or is this an opportunity for major rewrite/refactor?<p>Also very curious if anyone knows, will the Android Bluetooth stack ever be usable on a standard Linux distro desktop system?