Google developers released a few days ago a plan to implement a mechanism to run unmodified programs compiled for Linux on and operating system Fuchsia.
To run Linux programs in user space, it is planned to provide a "starnix" layer to support Linux ABI. In the developed layer, the Linux kernel system interfaces are implemented in a driver that is launched as a process for the Fuchsia operating system, which runs in user space and translates requests from Linux programs into calls to the corresponding Fuchsia subsystems.
It is observed thate during project development, many Fuchsia subsystems will have to be modified to implement all the system interfaces available in Linux. The architecture of starnix is largely the same as the Windows subsystem for Linux that Windows uses to translate Linux system calls to Windows system calls.
It is planned to implement the starnix code in Rust to minimize the possible vulnerability vectorss that can potentially be used to elevate the privileges of a Linux process to the starnix process.
To ensure security at starnix, standard Fuchsia protection mechanisms will be used whenever possible.
For example, when accessing system services such as the file system, network stack, or graphics subsystem, starnix will only translate requests, converting the Linux ABI to the Fuchsia system ABI, allowing the same restrictions as apply to common Fuchsia processes.
This will also implement Linux-specific authorization mechanisms, for example defining in which situations one Linux process has the right to terminate another.
Fuchsia developers have developed support for launching Linux applications in the past, but they experimented with an implementation that works by analogy with the way Linux application launch is organized on Chrome OS.
For Linux compatibility, Fuchsia offered the Machina library, which allowed Linux programs to run in a special isolated virtual machine formed using a hypervisor based on the Zircon kernel and Virtio specifications.
The use of virtualization is not ruled out, since the full implementation of the Linux system interface is not a trivial task.
In addition to the starnix cape, it is possible to create a mechanism to run Linux executables using a Linux kernel running in a separate virtual machine. This method is considered the easiest to implement, but also the most resource consuming.
At one point, Microsoft started developing its Linux compatibility layer from the translator, but eventually switched to using the native Linux kernel on the Windows Subsystem for Linux 2.
In addition, Fuchsia already provides a POSIX Lite compatibility layer which runs on top of Fuchsia System ABI. POSIX Lite allows you to run some Linux programs, but requires recompiling the application code and, in some cases, modifying the source code.
One of the problems with POSIX Lite is the incomplete implementation of all POSIX functions, including calls to change the global state of processes (for example, the kill function), which are at odds with security concepts in Fuchsia, which prohibit changing the global state of processes. Express.
The use of POSIX Lite is justified in the process of porting open applicationss, but it does not solve problems with launching programs for which there is no access to the code (for example, it is impossible to achieve compatibility with Android applications that contain compiled native inserts).
Let us remember that within the framework of the Fuchsia project, Google is developing a universal operating system capable of operating on any type of device, from workstations and smartphones to embedded and consumer technology. The development is based on the experience of creating the Android platform and takes into account the shortcomings in the field of scaling and security.
The system is based on the Zircon microkernel, based on the developments of the LK project, extended for use in various classes of devices, including smartphones and personal computers.
Source: https://fuchsia.googlesource.com