Hardening in Android Q:
security.googleblog.com/2019/05/queue-
Scudo won't be used on GrapheneOS for 64-bit, but it will be nice to have for 32-bit where the far more hardened github.com/GrapheneOS/har implementation isn't available due to completely dependence on a very large address space.
Conversation
It's also quite helpful that they'll be officially supporting multiple malloc implementations, and they'll be hitting more of the memory corruption bugs themselves. Their usage of ASan has helped a lot but they don't have much pressure to fix issues not actively causing problems.
1
1
The Shadow Call Stack feature is nice. It works much better on arm than x86 due to the link register rather than stack-based return addresses. It would be interesting to reinforce features like ShadowCallStack or SafeStack with ARMv8.5 memory tagging. One of many uses for MTE.
1
5
You may remember GrapheneOS (long before that name) was an early adopter of the bounds and integer sanitizers for hardening. It used the bounds sanitizer globally. There was an attempt use the object-size sanitizer too, but it uncovered far too much pervasive undefined behavior.
1
2
Nice to see these features being adopted upstream. It's a lot of work, because they uncover so many latent bugs. The work they're doing on this helps more sophisticated future features with a much more complete implementation of memory safety for C. It's clearing many blockers.
1
1
They have far resources to fix all of these issues instead of just disabling the features for portions of the code with latent bugs. For the same reason, it's enormously helpful that they're using type-based forward edge CFI for the kernel on the Pixel 3 since it was released.
1
1
Same goes for their gradually expanding deployment of automatic integer overflow checking including unsigned overflow. It takes a lot of work to fix all unintended overflows (some benign, others harmful) and mark intended overflows. These problems need resources thrown at them.