 Hello everyone and welcome to this presentation. My name is Arnaud and I'm a software engineer at Collabora. I've been working on the AGL application framework over the past few months. So I'm giving you an update about what's going on in this area and where we're heading to. I'll start with defining what an application framework is and why we need one on AGL. But in fact we already have one implementation of such a thing. So I'll give you a brief analysis of what the current implementation is and more specifically point out the problems and issues we're having with this framework. I'll expose then the reflections and choices we made for a new application framework and what we're going to include in the redesign and rework of this framework. Then talk to you quickly about what the current state is and introduce the next steps and what we plan for the future. The first thing first, AGL stands for Automotive Grade Linux. It's a Linux foundation project aiming at providing a reusable and customizable system for building Linux systems for the automotive industry. It provides and targets automotive applications such as in-viical entertainment which stands by IVI in general, instrument clusters and so on. So the application framework, what is it and why do we need one? The first use of such a framework is to provide a unified way of developing and deploying applications and by that I don't mean a framework is a software library or something like that but instead it's mostly a set of rules and low-level implementations to allow developing user applications in a unified way no matter who is doing the job and how we can integrate into the system. It's also designed to make interactions between applications and the base system predictable and safe. To ensure in particular that applications will not affect the system or other apps in unwanted ways or insecure ways and it basically sets the expectations for deliverables and integrations of applications into the final system. An app framework should provide the following features. It must be able to manage sessions or in-unix sessions because we're obviously willing to make applications run as a user process and not a system process so we will manage the sessions in which those user processes will be able to run. We also want to manage application lifecycle from start-up to termination and potentially for sensitive services have them restart automatically when they crash. We also want the application framework to provide or at least specify a standard set of APIs so that applications can use the underlying systems services. We also need a common inter-process communication mechanism so all the IPCs can be clearly handled and controlled. And last but not least an application framework must provide security and isolation of applications from the base system. Let's keep in mind that app developers are usually not the same people as the system developers and as such they don't necessarily have any knowledge of Yocto which is the base technology of HGL. So applications should be developed without having to interact with Yocto or deal with it in any way and it should as such provide a convenient way to ease application deployment and integration. So what about the current implementation of the app framework? Well this is mostly a custom implementation with lots of software services and many different pieces which doesn't use any of the existing standards or best practice. Session management relies on the system day libraries but they are handled by custom demands specifically developed for the app framework. The application lifecycle management is likewise implemented through custom services and the inter-process communication is using a really specific format which is data serialized into a JSON format and then transported by WebSockets. So clearly something really unusual in this field and the security aspects of the app framework are handled through SMAC which is a Linux security module much like AC Linux or APARM. On this slide you get a brief overview of how the current app framework is working so you see the separation between the system processes and user processes which are on the top of the slide and you'll see a few exotic things I'd say non-standard elements at least which are the AFM user and system demand the AFM main binding. The point of all of this is that for a single application you have a binding service embedded into the application security context you also have still in the user processes the actual service running into its own context and all of this is managed through the AFM user demand for user processes and AFM main demand for session management and all the security interface. Unfortunately this approach comes with a number of issues the first one the most visible one at least is the JSON of a WebSockets protocol it's really something that isn't widespread in the industry and actually it's a wholly custom implementation which requires custom bindings and libraries for every language you would want to use for writing your application it also comes with a significant performance overhead due to the nature of JSON and the WebSockets interface itself too and it has to provide an abstraction for basically every system API the application developer might want to use so you have a translation slash abstraction layer for APIs and it's of course biased because you want to well the app framework was designed with the goal of providing simple APIs and abstracting completely the complexity of the system APIs already existing so a few choices were made and obviously this abstraction cannot fit every single use case you might have so in this sense the API abstractions themselves are biased SMAC is also a problem because in the context of the HGL app framework it's very complex and difficult to get right and it's not an easy piece to deal with and finally all these app frameworks have received absolutely no support no adoption from the wider open source community so this makes basically HGL the upstream for the whole app framework it makes maintenance very difficult and complex and requires significant engineering time to maintain and evolve this framework so we decided to rework all of this redesigned from scratch mostly a new application framework which would be easier to deal with and easier to maintain the first point for this is to rely on upstream projects and widely adopted technologies in the open source ecosystem that way we can benefit from the work of the whole ecosystem and significantly reduce the engineering time we need to maintain the app framework itself and with this goal in mind we obviously want to limit to the bare minimum any custom implementation we would need for this framework or re-implementation as well and all of this should make in the end the new app framework easier and simpler to work with and hopefully make it more widely used and adopted so for the first item which is session management the basic building block we're using is basically system D as it provides everything we already need to manage user sessions including starting these sessions and monitoring the status and terminating those and so on so by using a custom system D target we can define a user session which is specific to AGL and have this session being started with a system level service and the session will contain pretty much every user service and user process needing to be started with login D and all the features of system D we already have a pretty good privilege separation and relatively normal and useful level of security next topic is the inter-process communication and for that part we decided to rely mostly on Divus I'm saying mostly because there are a few cases where we need high bandwidth data streams and Divus is not the best choice for that so that's a subject we still need to reflect a bit on and we need to work on a bit more in the end Divus still covers most of the needs and allows any application to place API calls to system services and to relive in the end on the existing system and to be able to communicate with both the system services and other applications if you want to allow them to do so lots of services already provide a Divus interface as it's a relatively standard technology now in the Linux world and just to put a few examples, Bluezy for Bluetooth Geoclue for Geolocation Modem Manager, Network Manager all provide already pretty complete Divus interfaces so that user applications can make use of those services in a really quite simple way Bindings and libraries exist for most languages so we don't have to maintain a specific or custom implementation of the IPC library we can just rely on what the community provides with Divus and have access to this IPC system pretty much no matter what language the application is developed with Regarding application lifecycle management there are three use cases we want to address the first one is background services so that services which would be started as user processes as soon as the session starts and which would continue to run throughout the session's duration so these are started using SystemD and we define SystemD user services for those ones and the interest of using SystemD is that we can first manage the lifecycle of such services and have SystemD restart them in case they fail automatically of course and monitor the stages and the service health in a sense then we can also make use of the SystemD sandboxing and technology and security features to restrict the rights of a user process so it can for example we can allow or deny access to certain devices or simply allow access to all devices or deny it we can also use C-groups and namespace and capabilities to make the services more restricted and we can also restrict which part of the file system should have access to so that's a pretty much complete solution and it already allows to do quite a lot of advanced things simply by using SystemD user units the other use case is on-demand services some of those one example could be a media player do not need to run for the whole duration of the session but they can be only needed by a few applications and so we can have the service not be started when the session starts but instead be automatically activated through D-Bus every time an application requires it and so we'll start the service through D-Bus and it will be really used on-demand and if you have a whole session during which you never need the media player then it won't be started at any time finally for what I'm calling here the one-time applications which could be for example a navigation application requiring user interaction we don't need to start those automatically or through D-Bus but we can simply have an app launcher service which will react to the user request to start this particular app pretty much what you have on your smartphones and you just have to touch the icon and get the application started so applications and services would be discovered and enumerated using the desktop entry specification by free desktop and we rely for that on desktop files obviously much like any desktop environment on Linux does nowadays and we also are able to discover D-Bus activated services so we can also present them to the user if they might be useful and might require user interaction the desktop entry specification also specifies a D-Bus interface which is dedicated to activating applications that way and so we're really using and sticking to standard mechanisms and widely adopted technologies on that finally, regarding the security aspects of their framework we still need a way to sandbox and contain applications even those which would not be started through SystemD so we considered at some point flatback because it provides efficient sandboxing and is quite simple to deal with unfortunately it lacks some fine-grained permissions in a few areas, for example network access can be either granted or denied but you can't limit it to a single family of protocols or to a single interface type for example you can't just tell the application that it can use IPv6 but not IPv4 so we... it's a bit limited in some ways and the most problematic thing with flatback is that there's no proper support in Yocto for flatback applications there is an existing metaflatback layer however it's not been much maintained over the last few years so it's not really fit for production right now and it lacks several features such as not starting but installing flatback applications directly on the IMAGE at a bit time so on the topic of security we're still considering which backend and which technology which should implement in the new app framework or at least we should move forward and we're considering relying a bit more on systemd due to the reasons and features I explained a bit before or we could also consider security modules such as app armor and maybe just have a mix of various technologies to make it more flexible and more simple to deal with depending on the use case we're trying to implement so what's the current status of this app framework? over the past few weeks the old app framework was fully removed from AGL in the master branch so we basically burned it to the ground in order to have a clean start and begin without the technical depth and historical depth we had with the old app framework we've already implemented the session management bits with a new system-level service and user target which are both systemd units the AGL session service will start the AGL session target for the selected user and AGL session target will basically pull in all its dependencies and systemd will start any service and application the target would depend on so this part is relatively simple and already implemented for now next topic is the application lifecycle management and for that we had a bunch of existing user services which are mostly AGL compositor, the Wayland compositor home screen which can be seen as the Wayland shell or window manager and launcher which is the graphical application you can use to display app icons and select which application you want to start these existing services have been converted I'd say so they use systemd user services for their lifecycle management they've been also ripped off every bit of the old app framework so we can start re-implementing our own framework on top of that and these services are obviously wanted by the AGL session target so they're automatically started when the session starts these old targets are obviously the IVI use case which needs a display and most likely a touch screen for the user to interact with but we can see a similar implementation being used for headless systems in the instrument cluster case just with no requirement of user interaction the principles are basically the same and this can be translated and moved on for a different scenario still on the topic of application lifecycle management Launcher, well the name isn't quite right because previously it was used to actually launch applications but that's not the case anymore it's only used for now to discover applications using desktop files so it will go through all the standard folders where such files should be found and retrieves the icon and presses the desktop files so they can be displayed on the screen and the actual starting and monitoring of the applications is offloaded to a new Launcher Demon which is AppLaunchD a really simple demon which provides a deeper interface with a method other applications can call to request a specific application to be started either through command line or divorce activation AppLaunchD itself is started as a SystemD user service and is started obviously as part of the user session as I said it can execute a specific command line or simply activate a divorce service with the divorce name of such a service and it monitors the lifecycle and stages of the started applications and it's able to notify other applications when an app successfully started and when it terminated both by monitoring the process or by monitoring the divorce name owning for divorce services so what's next for us first we need to port existing demo apps to the new app framework as HGL had a bunch of demo applications which were quite interesting to show what's possible but they're all really tightly integrated into the old app framework so we need to port these ones to the new framework and make sure they can work without all the custom plumbing that were present previously I've mentioned that Launcher has really a few features so we're going to merge this with the home screen application so that we have less services and also it makes much more sense to have one single application for those because otherwise you would have the Launcher request the application startup but still need to notify the home screen when the application actually started for it to show the window and put it on the foreground and having separate processes for that makes it a bit more complicated we also need and that may be the most important part of the remaining work select a security backend and deployment access control as part of the new app framework and of course we need to document all of those here are a few links that you can have a look at in case you want to know more about HGL, the application framework and the current implementation state you also have the link to the repositories for the current implementation and current work please note this is all work in progress and depending on when you will see this video things will probably have evolved a bit more in one direction or another so if you have any questions feel free to ask those in the chat and thank you all for watching this presentation