> I reported these two separate issues, lack of linear map randomization, and kernel lands at static physical address in Pixel, to the Linux kernel team and Google Pixel respectively. However both of these issues are considered intended behavior. While Pixel may introduce randomized physical kernel load addresses at some later point as a feature, there are no immediate plans to resolve the lack of randomization of the Linux kernel’s linear map on arm64.
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.
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.
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.
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.
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.
> I reported these two separate issues, lack of linear map randomization, and kernel lands at static physical address in Pixel, to the Linux kernel team and Google Pixel respectively. However both of these issues are considered intended behavior. While Pixel may introduce randomized physical kernel load addresses at some later point as a feature, there are no immediate plans to resolve the lack of randomization of the Linux kernel’s linear map on arm64.
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.
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.
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/
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.
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.
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/
[flagged]