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
Replying to
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.
1
Replying to
Contributions are welcome if you feel like it. We definitely strive for a balance perf/security rather than full security. Standalone (non sanitizer_common dependent) version is being committed @ github.com/llvm/llvm-proj
1
Replying to
github.com/GrapheneOS/har is certainly balancing performance, memory usage and security too. It takes a much different approach inherited from allocators like OpenBSD malloc rather than allocators like dlmalloc and is specifically designed around the large address space on 64-bit.
1
Show replies
