Defeating KASLR by doing nothing at all(googleprojectzero.blogspot.com)
googleprojectzero.blogspot.com
Defeating KASLR by doing nothing at all
https://googleprojectzero.blogspot.com/2025/11/defeating-kaslr-by-doing-nothing-at-all.html
12 comments
I'm of the opinion, sadly, that running some custom build of android with a few compiler options tweaked away from their defaults, is probably far more secure than the latest patched versions of iOS or Android.
Yes, it is effectively security by obscurity using the fact that nobody knows exactly which compiler options you tweaked, but the reality is it works really well since almost all exploits need to know some code offsets very precisely to work.
Also, many state security agencies have a ready to go exploit for the latest iOS, but they don't have a team ready to assemble a custom exploit for your modded android.
Yes, it is effectively security by obscurity using the fact that nobody knows exactly which compiler options you tweaked, but the reality is it works really well since almost all exploits need to know some code offsets very precisely to work.
Also, many state security agencies have a ready to go exploit for the latest iOS, but they don't have a team ready to assemble a custom exploit for your modded android.
It is the same principle behind sexual reproduction causing genetic variation that makes it harder for bacteria to kill everyone.
The post on lwn.net has some more context in the comments:
https://lwn.net/Articles/1044867/
https://lwn.net/Articles/1044867/
Edit to add: no need to read the LWN comments, the article is crystal clear and to the point - no technical reading skills necessary (unlike some very involved Project Zero posts).
- - -
Make sure you get down to the comment by ardbiesheuvel, “linear map randomization was already broken”, past all the hot air about the lack of QA. This comment explains why hot pluggable memory causes issues with randomization.
Now off to read the article.
- - -
Make sure you get down to the comment by ardbiesheuvel, “linear map randomization was already broken”, past all the hot air about the lack of QA. This comment explains why hot pluggable memory causes issues with randomization.
Now off to read the article.
I’m a bit confused by your edit and I’m glad I ignored it to read the comment you initially highlighted because it does offer a strong counter to the Project Zero article.
There are some good points around how limited the entropy available here is, but it entirely skips over who the fuck needs hotplug memory in the first place. That is a very niche feature that has no application in the vast majority of devices and should never inform the defaults.
It made it very clear - virtualization builds where memory can be dynamically added and removed by the emulator. I haven't done this with Android but it can be quite useful for running lots of test emulators, they can adapt their memory to the workload to not overwhelm the host.
So you agree, it has no place or purpose when running on an actual device.
[deleted]
This, having the whole physical memory mapped all the time, reminds me of a another issue that was exploitable in KVM hypervisors [1]. I wonder what is the reason to have it all mapped? Not everybody seems to do it.
[1] https://www.vusec.net/projects/rain/
[1] https://www.vusec.net/projects/rain/
Funny how Google is paying people to find exploits in their product, and also pays people to ignore those vulnerability reports.
Pixels seem to be pretty secure when running Graphene, from what I have heard.