> How much impact will moving sharedlibs (mediaserver, for example) / runtime / libcore to Rust will bring? And if all libs will need to be moved? - Or will the likes of memory tagging, sanitizers, hardened allocators (Scudo in bionic / Arena/dl/Ros in ART) enough of a defense?
I'm not an expert on specific attacks against allocators, but my general rule of thumb based on what they describe themselves as is that this helps but does not obviate heap memory corruption from being the source of exploitable vulnerabilities. So I would say that moving to Rust would still be useful.
> Now that Android devices have as much computer/RAM as servers do (and fast battery charging is almost ubiquitous), do you see VM sandboxing apps (like in ChromeOS does with crostini) become a thing?
So Android has a thing called pKVM that was designed, as far as I can tell, to run secret ML models and DRM. When I left they seemed to be looking for more pleasant clients, so it seems reasonable that they one day actually work to put security-critical services into VMs. But the overhead is quite high so I assume there will need to be a lot of work put into this if they want it to be practical.
> Believe the drivers (Binder at one stage, GPUs, of late) remain a source of exploits; do you see a microkernel like Zircon being folded into the Android Kernel? Longer-term, will moving away from Linux (but maintaining compat via emulation, say) become a necessity to combat CSVs?
I'm not entirely sure if this is possible, to be honest. Drivers on Android have been a pain point for a while. Google has much more control over their own hardware, of course, but for random other OEMs what typically happens is their drivers are binary blobs that rarely get updated. Making improvements in this area is a major effort.
I think, in the long term, that you can't just go "microkernel" to the problem of drivers, because some hardware is always going to have broad access for performance reasons. You can stick an IOMMU between things but some hardware (e.g. graphics) usually bypasses that and other hardware (e.g. storage, flash ROM) can compromise the entire device if tampered with. So I expect to see greater integration in the stack to try to secure these. Some of this may involve userspace drivers, but some might be more specialized to protect against more specific attacks.
> I see a bunch of eBPF use since Android 12+. Do you see Google actively work to provide more APIs for forensics / monitoring (like Knox/EMM) without needing root (or abusing Accessibility/VPN/DeviceAdmin/ADB Shell/etc).
So I don't think Google will give you arbitrary eBPF just because eBPF gets exploited a lot, so letting apps upload arbitrary programs is probably too spooky for them. More generally though they are interested in this space but it's very difficult to provide good APIs, because a lot of the people in this space are selling borderline-scam EDR, and providing the things they want just lets people make spyware easier. I have no idea what is next but I can say that when I was there the things I was creating signals that we felt were very costly to bypass. Unfortunately this is very, very difficult, and the difficulty only goes up as you attribute more capabilities to an attacker.
I'm not an expert on specific attacks against allocators, but my general rule of thumb based on what they describe themselves as is that this helps but does not obviate heap memory corruption from being the source of exploitable vulnerabilities. So I would say that moving to Rust would still be useful.
> Now that Android devices have as much computer/RAM as servers do (and fast battery charging is almost ubiquitous), do you see VM sandboxing apps (like in ChromeOS does with crostini) become a thing?
So Android has a thing called pKVM that was designed, as far as I can tell, to run secret ML models and DRM. When I left they seemed to be looking for more pleasant clients, so it seems reasonable that they one day actually work to put security-critical services into VMs. But the overhead is quite high so I assume there will need to be a lot of work put into this if they want it to be practical.
> Believe the drivers (Binder at one stage, GPUs, of late) remain a source of exploits; do you see a microkernel like Zircon being folded into the Android Kernel? Longer-term, will moving away from Linux (but maintaining compat via emulation, say) become a necessity to combat CSVs?
I'm not entirely sure if this is possible, to be honest. Drivers on Android have been a pain point for a while. Google has much more control over their own hardware, of course, but for random other OEMs what typically happens is their drivers are binary blobs that rarely get updated. Making improvements in this area is a major effort.
I think, in the long term, that you can't just go "microkernel" to the problem of drivers, because some hardware is always going to have broad access for performance reasons. You can stick an IOMMU between things but some hardware (e.g. graphics) usually bypasses that and other hardware (e.g. storage, flash ROM) can compromise the entire device if tampered with. So I expect to see greater integration in the stack to try to secure these. Some of this may involve userspace drivers, but some might be more specialized to protect against more specific attacks.
> I see a bunch of eBPF use since Android 12+. Do you see Google actively work to provide more APIs for forensics / monitoring (like Knox/EMM) without needing root (or abusing Accessibility/VPN/DeviceAdmin/ADB Shell/etc).
So I don't think Google will give you arbitrary eBPF just because eBPF gets exploited a lot, so letting apps upload arbitrary programs is probably too spooky for them. More generally though they are interested in this space but it's very difficult to provide good APIs, because a lot of the people in this space are selling borderline-scam EDR, and providing the things they want just lets people make spyware easier. I have no idea what is next but I can say that when I was there the things I was creating signals that we felt were very costly to bypass. Unfortunately this is very, very difficult, and the difficulty only goes up as you attribute more capabilities to an attacker.