102 pointsby aa_is_op6 days ago4 comments
  • Hendriktoa day ago
    > 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.

    • londons_explore19 hours ago
      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.

      • UltraSane9 hours ago
        It is the same principle behind sexual reproduction causing genetic variation that makes it harder for bacteria to kill everyone.
  • nolist_policya day ago
    The post on lwn.net has some more context in the comments:

    https://lwn.net/Articles/1044867/

    • fn-mote21 hours ago
      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.

      • scott_w19 hours ago
        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.
        • stefan_16 hours ago
          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.
          • jmalicki15 hours ago
            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.
            • stefan_11 hours ago
              So you agree, it has no place or purpose when running on an actual device.
    • 20 hours ago
      undefined
  • i-cona day ago
    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/

  • rvz20 hours ago
    Great writeup as always from project zero and this could not possibly have been generated by an AI, nor did the author ever use an AI to find this very powerful vulnerability.