106 pointsby aa_is_op3 months ago4 comments
  • Hendrikto3 months 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_explore3 months 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.

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

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

    • fn-mote3 months 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_w3 months 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_3 months 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.
          • jmalicki3 months 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_3 months ago
              So you agree, it has no place or purpose when running on an actual device.
    • 3 months ago
      undefined
  • i-con3 months 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/

  • rvz3 months ago
    [flagged]