3 ms·

Why does this run in a virtual machine (per the article) and not a container?

seabrookmx 1y ago
Two reasons I can think of: 1) security. Container breakouts are much more common than VM breakouts 2) compatibility - the Android kernel is known to be heavily modified and Debian may benefit from being run on a more vanilla kernel as it does on desktop/server
- charcircuit 1y ago
  What changes do you think makes the Android kernel heavily modified?
  - pjmlp 1y ago
    For starters, the microkernel like driver model, where classical Linux drivers are considered legacy, since Android 8 all modern drivers run on their own processes (Java or C++) and talk with the kernel via Android IPC, known as Binderized HAL. https://source.android.com/docs/core/architecture/hal/archive https://source.android.com/docs/core/architecture/hal/archiv... https://source.android.com/docs/core/architecture/hal https://source.android.com/docs/core/architecture/hal Processes are sandboxed, in which app gets its own user id, everything that Google considers not a public API gets blacklisted, via a mix of LinuxSE and seccomp. Native executables are not allowed per se on userspace, native code outside system processes has to always be a shared object loaded into the Zygote process fork, which takes the init role on Android. There are ways to launch executables, but they are frowned upon. https://source.android.com/docs/core/runtime/zygote https://source.android.com/docs/core/runtime/zygote Android is quite stright in memory consumption, an application that is seen as misbehaving gets killed without remorses. For all details, you can go from here https://source.android.com/docs/core/architecture/kernel https://source.android.com/docs/core/architecture/kernel
    - anthk 1y ago
      Modern distros supports binder too. In the reverse, you can run Waydroid, which is an Android userland under a Wayland distro. On native executables and such, file and objdump once I installed clang under termux to compile a simple binary tells me otherwise.
      - pjmlp 1y ago
        I bet you didn't install Termux from the PlayStore. What matters is how an Android device as bought on a random shop as consumer behaves, not how one can hack around Android and AOSP.
        anthk 1y ago
        Install it from F-Droid. If you are advanced enough to run Terminal bound software, using PlayStore is not the developers' fault.
        pjmlp 1y ago
        Thus my point is made, should have placed the bet.
        charcircuit 1y ago
        It is the developers fault for Termux's architecture not being aligned with Android's app model.
      - Hackbraten 1y ago
        TIL that binderfs is a mainline kernel feature now, Back when I used Waydroid, I had to use an out-of-tree module picked from the Anbox project. I have stopped using Waydroid but good to know that binderfs is a thing!
    - charcircuit 1y ago
      This reply doesn't address why a container would be unable to work due to "heavy modification."
  - LtWorf 1y ago
    Try to run a mainline kernel on a phone and let us know how it goes!
    - charcircuit 1y ago
      It's not the Android part that would get in the way. Assuming the kernel supported the hardware, Android would work.
ajross 1y ago
Presumably because container breakouts are fairly common and "external Linux software downloaded by the user" is at least as presumptively malicious as an app from the store. Modern consumer systems need to be safe vs. the user being tricked to run terrible things. A docker or whatever isn't quite up to the standards[1] required on its own. [1] Though I'm very much not one of the pedants who refuse to see any security value at all in container isolation. Containers isolate software access (e.g. limiting access to libraries with vulnerabilities) and network communication (writing firewall rules for a container is a lot easier than it is for an app) really well, for example. Use them! But not for this.
transpute 1y ago
Development independence of guest VM from host kernel, security policy, attestation, etc.
heavyset_go 1y ago
If you have to depend on the host kernel, you will likely be stuck on some old kernel fork at some point in your device's life. You can run whatever kernel you want in a VM, though.

Two reasons I can think of: 1) security. Container breakouts are much more common than VM breakouts 2) compatibility - the Android kernel is known to be heavily modified and Debian may benefit from being run on a more vanilla kernel as it does on desktop/server

charcircuit 1y ago
What changes do you think makes the Android kernel heavily modified?
- pjmlp 1y ago
  For starters, the microkernel like driver model, where classical Linux drivers are considered legacy, since Android 8 all modern drivers run on their own processes (Java or C++) and talk with the kernel via Android IPC, known as Binderized HAL. https://source.android.com/docs/core/architecture/hal/archive https://source.android.com/docs/core/architecture/hal/archiv... https://source.android.com/docs/core/architecture/hal https://source.android.com/docs/core/architecture/hal Processes are sandboxed, in which app gets its own user id, everything that Google considers not a public API gets blacklisted, via a mix of LinuxSE and seccomp. Native executables are not allowed per se on userspace, native code outside system processes has to always be a shared object loaded into the Zygote process fork, which takes the init role on Android. There are ways to launch executables, but they are frowned upon. https://source.android.com/docs/core/runtime/zygote https://source.android.com/docs/core/runtime/zygote Android is quite stright in memory consumption, an application that is seen as misbehaving gets killed without remorses. For all details, you can go from here https://source.android.com/docs/core/architecture/kernel https://source.android.com/docs/core/architecture/kernel
  - anthk 1y ago
    Modern distros supports binder too. In the reverse, you can run Waydroid, which is an Android userland under a Wayland distro. On native executables and such, file and objdump once I installed clang under termux to compile a simple binary tells me otherwise.
    - pjmlp 1y ago
      I bet you didn't install Termux from the PlayStore. What matters is how an Android device as bought on a random shop as consumer behaves, not how one can hack around Android and AOSP.
      - anthk 1y ago
        Install it from F-Droid. If you are advanced enough to run Terminal bound software, using PlayStore is not the developers' fault.
        pjmlp 1y ago
        Thus my point is made, should have placed the bet.
        charcircuit 1y ago
        It is the developers fault for Termux's architecture not being aligned with Android's app model.
    - Hackbraten 1y ago
      TIL that binderfs is a mainline kernel feature now, Back when I used Waydroid, I had to use an out-of-tree module picked from the Anbox project. I have stopped using Waydroid but good to know that binderfs is a thing!
  - charcircuit 1y ago
    This reply doesn't address why a container would be unable to work due to "heavy modification."
- LtWorf 1y ago
  Try to run a mainline kernel on a phone and let us know how it goes!
  - charcircuit 1y ago
    It's not the Android part that would get in the way. Assuming the kernel supported the hardware, Android would work.

ajross 1y ago

Presumably because container breakouts are fairly common and "external Linux software downloaded by the user" is at least as presumptively malicious as an app from the store. Modern consumer systems need to be safe vs. the user being tricked to run terrible things. A docker or whatever isn't quite up to the standards[1] required on its own. [1] Though I'm very much not one of the pedants who refuse to see any security value at all in container isolation. Containers isolate software access (e.g. limiting access to libraries with vulnerabilities) and network communication (writing firewall rules for a container is a lot easier than it is for an app) really well, for example. Use them! But not for this.

transpute 1y ago

Development independence of guest VM from host kernel, security policy, attestation, etc.

heavyset_go 1y ago

If you have to depend on the host kernel, you will likely be stuck on some old kernel fork at some point in your device's life. You can run whatever kernel you want in a VM, though.