Announcement

Collapse
No announcement yet.

Google Rewriting Android's Binder In Rust With Promising Results

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by Volta View Post
    Android's security and performance in single sentence sounds like a joke. Binder makes it even more comical:

    Binder Flaw Threatens to Blow Apart Android Security. Check Point researchers say new vulnerability could enable covert data and comms theft


    But what to expect from clown company like google?
    Your link is from 2014.

    I'm the first to criticize Google but if there's is something they did right it's Android.

    Bug bounties for a new Android version is similar or higher than iOS these days.
    Last edited by wagaf; 02 November 2023, 02:19 PM.

    Comment


    • #12
      Originally posted by wagaf View Post

      Your link is from 2014.

      I'm the first to criticize Google but if there's is something they did right it's Android.

      Bug bounties for a new Android version is similar or higher than iOS these days.
      Okay. Any effort to do it?

      Comment


      • #13
        Originally posted by timofonic View Post

        Binder is an old and non-standard IPC mechanism that clashes with the Linux kernel's design and goals. It complicates the kernel, isolates Android from other Linux systems, and exposes the kernel to user-space bugs and attacks. Binder should be replaced by a new IPC mechanism that uses standard Linux features, such as cgroups, namespaces, seccomp, and epoll. Improve them to reach the same feature and performance at least. This would make the kernel simpler, faster, safer, and more collaborative.

        ‚Äč
        Well at least you aren't suggesting they use SysV IPC. I don't really see how this is clashing with linux's kernel's design. after all it's been accepted upstream and uses things like linux threads and selinux. i think there's some namespace/cgroup usage on android, so I binder is somewhat orthogonal to that. i'm not sold on the idea that whatever android needs the linux desktop needs. for example, they don't need images for apps but they need them for operating systems, and linux servers/desktops don't need images for operating systems, but needs them for apps. I think there's a lot of bad thinking that there's one model for desktops/appliances/servers, and I think it's quite different. for example everyone these days thinks image based OS's are the future, but I'm less certain.

        anyway I'm more pragmatic about the capability of shaping the linux desktop. we are long past the days of having pathfinders like keith, nat, miguel, and havoc moving the desktop forward. I'm just hoping the crew we have these days will spend more time on standards, like xdg-portals, dbus, wayland extensions, so the remaining app developers on linux can get their stuff working cross desktop consistently, and hopefully enable as many app developers to run their stuff on linux (such as via waydroid, wine, or plain old web).

        Comment


        • #14
          Originally posted by fitzie View Post

          Well at least you aren't suggesting they use SysV IPC. I don't really see how this is clashing with linux's kernel's design. after all it's been accepted upstream and uses things like linux threads and selinux. i think there's some namespace/cgroup usage on android, so I binder is somewhat orthogonal to that. i'm not sold on the idea that whatever android needs the linux desktop needs. for example, they don't need images for apps but they need them for operating systems, and linux servers/desktops don't need images for operating systems, but needs them for apps. I think there's a lot of bad thinking that there's one model for desktops/appliances/servers, and I think it's quite different. for example everyone these days thinks image based OS's are the future, but I'm less certain.

          anyway I'm more pragmatic about the capability of shaping the linux desktop. we are long past the days of having pathfinders like keith, nat, miguel, and havoc moving the desktop forward. I'm just hoping the crew we have these days will spend more time on standards, like xdg-portals, dbus, wayland extensions, so the remaining app developers on linux can get their stuff working cross desktop consistently, and hopefully enable as many app developers to run their stuff on linux (such as via waydroid, wine, or plain old web).
          I think there'sreal innovative stagnation.

          kdbus was a failure, many devs dislike D-Bus, there's people deceived with Wayland (alternatives such as Arcan exist, but n o t mainstream at all), systemd is the Galactus of Linux.
          Last edited by timofonic; 02 November 2023, 03:14 PM.

          Comment


          • #15
            I'm patiently waiting on first security bug in rust code in kernel space.

            Comment


            • #16
              Originally posted by kloczek View Post
              I'm patiently waiting on first security bug in rust code in kernel space.
              So it begins...

              84pmoz.jpg

              I hope it's not busy waiting.

              And no, I'm not thinking rust is a silver bullet. There are probably going to be memory bugs in the unsafe wrapper code. But that's missing the point of using it in the first place.
              Last edited by oleid; 02 November 2023, 05:07 PM.

              Comment


              • #17
                Originally posted by bug77 View Post
                Poor sobs, they didn't ask kpedersen, he would have warned them they're heading towards doom abandoning C. Oh well...
                He would have explained that Rust was just a dying fad.

                Comment


                • #18
                  Originally posted by wagaf View Post
                  The path forward should be to merge Binder in the Linux kernel.
                  It already is (Devices, IPC, Filesystem...). Is some critical part missing ? I have yet to see any non-android software that makes use of Binder though.

                  Comment


                  • #19
                    Originally posted by kloczek View Post
                    I'm patiently waiting on first security bug in rust code in kernel space.
                    So you can attack the strawman argument that Rust is a silver bullet, while carefully ignoring statistics on security bugs in C code ?

                    Comment


                    • #20
                      Originally posted by kloczek View Post
                      I'm patiently waiting on first security bug in rust code in kernel space.
                      It is a certainty that there will be one, because nothing is perfect, and no one is pretending that Rust is perfect. That is not really interesting. What would be interesting is to compare statistics of vulnerabilities after a long period of time after there is some volume of Rust code in the kernel to compare with C.

                      Comment

                      Working...
                      X