SFSCON 2023 - beyond Google and Apple duopoly

Community Forum
1

Hi all,

I did a talk at SFSCON 2023 in Bozen about mobile devices market. I wish to invite you to download my slides from t.ly/zHgAV on which in the last part, there are some slides proposing the idea of containerising AOSP to free it from the hardware and adopt a bootable image with kernel, firmware and a basic root filesystem as a supervising OS that can provide firewalling, OTA and app violation catch.

In those slides there is also a simple scheme about revenues and costs along the current value chain in the mobile market. On the right side, I have presented an alternative that increases the revenues and reduces the costs reducing the fragmentation and scaling up the revenues from firmware support to a more comprehensive upper layer (supervising OS) which would work like the supervising OS embedded in the server racks.

1 Like
2

a deshortened link to the duopoly pdf: https://github.com/robang74/redfishos/blob/main/sfsconf-2023/beyhond-google-and-apple-duopoly.pdf

I liked your page 3 introduction in https://github.com/robang74/redfishos/blob/main/RedFishOS-presentation-A4.pdf - redfishos seems like a reasonable idea.

Do you have candidates for the hypervisor, a proof of concept? Google is coming around with KVM itself, but that’s not what you’d aim for, as in you want a minimal hypervisor.

3

Well, first of all, I started to work on smartphone on 26th May 2023. This means that I have a lot of things to learn about this specific sector. On my side, I can leverage a long experience in UNIX and GNU/Linux systems since 2000 and I developed the architecture of many systems from embedded firmware up to large cluster include real-time and networking. Just to put in clear that on some topic I can teach something but in other topic I have to learn a lot.

A supervising system (OS), in my mind is not a hypervisor nor a virtual machine but more similar to the embedded system in the blades server rack that allows to control the hardware and also the OS installation on the blades in many ways included boot from Ethernet. I think that this difference in PoV is very important not only because performance but also in terms of IoT fleet management which can be a significant advantage for any business that wish to set their roots in the gap between iOS and Android.

My first approach is to boot the AOSP in chroot jail in which /sys, /proc and /dev are shared with the supervising system (kernel + firmware + root filesystem currently based on busybox). Obviously, this approach does not grant security for obvious reasons but in normal conditions can be used as described above, for fleet management or system rescue.

The second step is to adopt some kind of container. I would say that a layer that imposes restrictions betweens real /sys, /proc and /dev and those mounted into the chroot jail could be enough. However, I do not see any specific reason - at the moment - to reinvent the wheel and an open source container system seems a more reasonable choice.

Which one? I am not an expert. Docker is the most famous but for this specific sector, alternatives should be considered especially because Docker is for cloud / server and can be over-dimensioned for this specific task.

https://www.simform.com/blog/docker-alternatives/

Among this alternatives, I would give a chance to RTK which is described in this way:

Rkt – Simplicity and security amplified

Formally known as CoreOS Rocket, Rkt is an application container engine known for its simplicity and security features. It is well-used by consumers and offers excellent support. Rkt integrates with other systems thanks to its pod-native framework and pluggable execution environment.

I did not tried it yet and the choice can be wrong because it is presented as an application container engine. The AOSP is not an application therefore it might fit or not. However, I found also “applications” that in fact were an almost complete GNU/Linux system with several services installed and running on it.

Anyone that can enlighten me about containers engines, is welcome! :blush:

Anyone that can help me to make the wireless working, is welcome as well. I have the firmware, it is read by the kernel. The WLAN hardware is switched on, etc. but I do not know the procedure to instruct the kernel to present the network interface. Device: Sony Xperia 10 mark 2.

POST SCRIPTUM

I have added a link to the video of my speech at SFSCON 2023 uploaded on youtube editing the my comment at the top of this thread.

4

Hello @robang74,
You wrote “The second step is to adopt some kind of container”.
Perhaps you can take a look in the distro “easyos” from the developer Barry Kauler.
He created his own container.
Huib43.

5

The distro works in a similar manner of my RedFish OS. The reason is pretty straightforward: every boot image that can be used as restore / recovery image should be the same at each boot. In my case, I have added a small writeable partition inside the boot-able image using a trick. However, that writeable area does not interfere in any manner with boot and system start-up. It can be mounted manually when it is needed to save few (4MB) data (e.g. Wi-Fi credentials).

Moreover, reading the home page of easyos - it seems to me that Huib43 is specialised for user space applications. Hence, it can be nice to have in Android not for containerize Android.

The RTK is podman compatible, support TPM and can works with Docker images plus is oriented toward security. In fact, it support SE Linux. Moreover, Docker images are very useful for developers as far as they can run it in an virtualised environment.

For my own personal purposes, the chroot is enough and it will be enough for long time. Unless, the things start to accelerate or I will be involved in some project which aims to quickly reach the market.

6

POD vs CONTAINERS vs VM

I received this video presentation from the IBM newsletter and I like to share with you.

In this video, Red Hat developer advocate, Cedric, explains the differences between containers and pods, providing example scenarios, and steps for getting started with Kubernetes on your local server or laptop.

https://www.youtube.com/watch?v=vxtq_pJp7_A

IMHO, the most interesting part is summarized in this picture which shows the main difference in usage from virtual machine and containers

Screenshot from 2023-11-15 10-30-05

Therefore the first guess to using a VM to separate the AOSP image from the supervising OS was a good try.

As we can read in the link above about KVM, also Google feel uncomfortable about kernel fragmentation among various Android version. Therefore, providing a supervising OS that free the Android from a specific version of the kernel but a range of version. We cannot expect that the same system will work effortlessly from 1.0 and 10.0 but a reasonable range like 4.x and 6.x can be a HUGE advancement.

I am quite optimistic that when a functional PoC about this kind of abstraction will be presented, it will receive the attention of Google Android team and probably adopted by them as well.

Now, being back to the separation of the AOSP from the supervising OS, the container model seems the best fit for this goal because the OS (the kernel) stays out of the container. The next question is:

  • should the root filesystem shared among the supervising OS and the AOSP container?

It will be nice but the standardisation of a basic filesystem will bring in a lot of effort from 3rd party independent projects like busybox or toybox which does not sound feasible nor a good choice to go, not immediately for sure.

Even this standardisation can not even been necessary among various supervising OS because after all, competition among different implementation is also based on this aspect. After all, who cares?

Fragmentation among root filesystems never be a big issue as long as and as far as some general rules - well established by now - are respected. This also apply about the start-up system (e.g. initd or SysV), the two can be completely separated. However, it would be important that the two would not interfere.

On the long term along the developing line, the supervising OS should be able to initialise all the hardware and load all firmwares properly. Therefore there are different components:

  1. monolithic kernel with all the drivers embedded
  2. root filesystem with shell and busybox or toybox
  3. a set of firmware for the specific hardware

The #2 can be generic and specific for each supervising OS, including the system start-up stuff. About the #3, we are used to have one partition that contains all these firmware specifically selected for each mobile device and there is no reason to change this. About #1, we might decide that a monolithic kernel is not any more the best approach to go with. A generic kernel might be combined with a partition in which will contains all the modules selected for each mobile device. This partition can be contained into the boot image - boot partition itself, not necessary a real partition.

About #3, also an hybrid approach can be used: essential modules in the boot image in order to being able complete the boot and mount the extra kernel modules partition. Why do not embedded some essential modules into the kernel, instead?

It is not just a matter of taste but about hardware fragmentation among the same smartphone family. It is faster to have a build procedure that choose different modules to be included into an image rather than recompiling the kernel image. Imagine to have 6 devices belonging to the same hardware family - this group of device, we might call a hardware platform - the best is that the essential modules are the same and probably the hardware vendors and smartphone producers will move in this direction but we cannot take it as always given.

I wish to ear some opinions about the idea of returning to the kernel modular approach. Also about everything else I wrote, but for this specific topic - which breaks the current default approach - in particular.

UPDATE

Removing the firmware loading and the hardware initialisation from the AOSP allows the AOSP to be containerised on different hardware. Obviously, in those system in which the hardware is missing, e.g. GPS, all the related functions and apps. will fail unless that hardware would not be simulated.

However, the simulation of some hardware sub-system like GPS can be very important to debug the functionalities and apps. also in corner cases which are quite difficult to see in the real-world but possibly can be meaningful for real-life or real-world emergencies or security.

7

This topic was automatically closed after 7 days. New replies are no longer allowed.