 Good morning. Welcome to this talk on Bluetooth in Cockpit Systems. I'm Shruti Gaikwad and I'm working with KPIT Technologies as a senior software engineer. I have 4 plus years of experience in IVI production and Agile-based POC programs. Okay, few words about KPIT. We are an independent software integration partner to global automotive leaders. We are focused on automotive and mobility and we specialize in embedded software, AI and digital solutions. We are a company of 7000 plus people and we have 51 patents and 25 innovation awards. So let's get started. What is the motivation for this talk? As we know that the automotive industry is moving towards cockpit based systems. So it could be a hypervisor based or a containerization based cockpit system. As a part of containerization based cockpit system, there is definitely a need to run Bluetooth in containers. So in one of the cockpit systems that we are currently working on, we have managed to get Bluetooth access from a container. However, we have faced certain challenges and in this talk, we want to discuss the challenges that we have faced while running Bluetooth in a container and the approaches that we have taken to get Bluetooth running in a container. We also want to work with the community to come up with an upstreamable solution to get Bluetooth accessible from a container. We also want to discuss the merit and demerits of making Bluetooth kernel module accessible inside the container. So let's understand why Bluetooth in containers. This is a reference architecture of one of the Linux based cockpit system that we are currently working on. As seen, there are three containers Dom0, Cluster and IVM. So Dom0 is the minimal container and it takes control of the audio and graphics resources. It is also responsible for maintaining policy and permissions for resource access for the other containers. As depicted over here, Cluster and IVM are running as separate containers. So as you can see, all the IVF functions like USB media, Wi-Fi, projection, audio, radio, BT are running in IVI container. As there are various reasons to have IVI run in a container, we know that the security that this offers by isolating Wi-Fi and other network services from the rest of the cockpit systems is one of the biggest advantage of this architecture. This slide shows a reference architecture of an agile based cockpit system and this is taken from one of the world presentation by Walt Minor. As you can see here, the IVI is run in a container with BT being part of the IVI container. So we understand that having cockpit systems with IVI as a container is something that is being considered by the automotive industry and it is also very much required. So BT being part of IVI, such integrated cockpits require Bluetooth to be run in a container. However, there are certain challenges for enabling Bluetooth access from the container. So before we discuss those challenges, we need to have a clear picture of Bluetooth hardware and some of the Bluetooth stack software architectures. So let us discuss the Bluetooth hardware and Bluetooth software stack architectures. Let's start with the Bluetooth hardware interface architecture. As seen in the slide, the Bluetooth core system consists of a host and one or more controllers. The SCI driver which is located on the host is responsible for exchanging data and commands with the SCI firmware that is located on the BT hardware. The Bluetooth controller typically uses UART, USB and STIO as some of the physical interfaces to the host. And UART is the most dominant PT interface that is used in the embedded world. Here you can see a diagram of UART PIN out which is SCI H4 which is 4 wire UART with data flow control. So as you can see there is RX and TX which are the UART serial input and output respectively. And there are TS and RTS which are UART serial data flow control signals. So now that we have a clear picture of Bluetooth hardware architecture, let us discuss some of the BT stack software architectures. So let's start with Bluetooth software architecture. Bluezy is the most widely used Bluetooth stack and it is also the official Linux Bluetooth stack. As represented in this diagram, here you can see that the Bluezy is split in between the kernel and the user space with most of the implementation done in the kernel. So layers like RFCOM, L2CAP, SCO etc. are present in the kernel and this offers a socket-based interface to the user space. So as you can see there is a Bluetooth daemon and SCI tools that are present in the user space which interact with the Bluetooth hardware using the Bluetooth socket interface that is offered by the kernel Bluetooth subsystem. This architecture provides hardware abstraction as the upper layers do not need to worry about the underlying physical transport that is being used. So now that we have discussed Bluezy software architecture, let's check the next software architecture, Bluetooth stack software architecture. Okay, so this is one of the software, Bluetooth stack software architecture used on Android. As you can see, there is a Fluret stack being used and there is a Wender library. This Wender library is responsible for opening HCI sockets and it gives control to the upper layers. So the HCI sockets are used to communicate with the HCI directly from the user space. So this architecture as well uses the Bluetooth socket interface that is offered by the kernel Bluetooth subsystem. So this Wender library is responsible for opening HCI sockets and these sockets are used to send and receive raw HCI frames. So as you can see, all the higher level protocols are implemented in the user space whereas this uses the BT socket interface that is offered by the kernel Bluetooth subsystem. So this benefits from the hardware abstraction that is offered by the Linux kernel Bluetooth subsystem. So here a single Wender library can be used with any BT controller that is already supported by the Linux kernel. So let's check the next software architecture. Okay, this is one of the software BT stack software architecture that is used in Android. As you can see the Fluret stack is used and this is implemented entirely in the user space. It interacts with the Wender HCL and as we know that the UART is the dominant BT interface in the embedded world. The default implementation of Android's HCL is also based on HCI, it's for UART. So here the Wender HCL is responsible for interacting with the UART and exchanging HCI frames, raw HCI frames over the serial port. So as you can see this is a complete user space stack and it does not use the Bluetooth socket interface that is offered by the Bluetooth kernel Bluetooth subsystem. So this does not benefit from the hardware abstraction that is offered by the kernel Bluetooth subsystem. So here a re-implementation of the Wender HCL is required if a new chip or any other interface other than the UART is to be used. This architecture though it requires re-implementation of Wender HCL, this has certain advantages over the other architectures. We'll discuss those later. So now that we have a clear picture of Bluetooth hardware and some of the Bluetooth stack software architectures. Let's check the challenges that are associated when we try to access Bluetooth from the containers. The software architectures that were dependent on the Bluetooth socket interface offered by the kernel Bluetooth subsystem. They have certain challenges when we try to access Bluetooth from the containers using these BT stack software architectures. So let us discuss those challenges. As we know that the namespaces are the fundamental aspect of containers on Linux and the Linux offers six types of namespaces where network namespace is one of them. So in our containerization based cockpit system, a separate namespace is created for each of the container, apart from the host root network namespace, which is also known as the Indit network namespace. So each container will be associated with a separate network namespace. As you can see in the snippet of BT socket creation code, there is a check for Indit network namespace. So this specifies that the Bluetooth socket, the mainline kernel will not allow to open Bluetooth sockets from any other network namespace than the Indit network namespace. Hence, with the software, with the Bluetooth stack software architectures that were dependent on the Bluetooth socket interface, we cannot access Bluetooth hardware from the containers. So let us check a demo of a cockpit system where we will try to open Bluetooth socket from a container and we will try to access Bluetooth hardware from container. The demo for testing Bluetooth access from the container is being performed on the cockpit system that we are currently working on. We have used LXS as a containerization engine and we have created three containers wherein IVI is run as a container. So we have implemented this on Renesha's Rcar M3 starter kit and we are using the TP-Link's Bluetooth USB dongle. The stack used here is Bluezy. So first, let us check the status of all the three containers. So, as seen, all the three containers are in running state and IVI is run in a container. Now, let us check the network namespaces that are accessible on this system. As seen, there are four network namespaces that are created. One is the default root network namespace and other three are each associated with one of the containers. So a separate namespace other than the init namespace is created for each of the containers. Now, let us run a demo program in order to open a socket, Bluetooth socket from the host and the containers. So this program actually tries to open a Bluetooth HCI protocol socket. So let us run this and check if it is successful. As seen, the attempt to open the Bluetooth socket is successful. As a success message is printed and this attempt was done from the host. So as the host is associated with the init network namespace, it was able to open Bluetooth sockets. Hence, it will be able to access the Bluetooth hardware and control it. So let us try to run the same demo program in a container. So let us attach into a container. So we are attaching in the IVI container. Now let us try to run the same demo program which is used to open the Bluetooth HCI socket. As seen, the failure message is printed on the terminal which states that the Bluetooth socket cannot be opened from the container. As the container is associated with a different network namespace than the init network namespace that is the root's network namespace. So it won't be able to open Bluetooth socket. Hence, any attempt to communicate with the Bluetooth hardware fails from the container and hence Bluetooth is not accessible from the container. From this IVI container. This challenge of accessing Bluetooth from container, it arises only with the Bluetooth stacks that are dependent on the Bluetooth socket interface. So if we go with the complete user space stack, this challenge of accessing Bluetooth from containers will not be applicable. So as we discussed that with BTUART interface and UART being a simple character device, it could be easily added to a container and with complete user space stack and with UART BT interface, we can easily access Bluetooth from the containers. However, we do not want to focus on the complete user space stack. And here we want to focus on the Bluetooth stack that are dependent on the Bluetooth socket interface offered by the Bluetooth kernel subsystem. So let us check some of the solutions that will allow us to open Bluetooth sockets from the container. So the first approach is to share the host network namespace with the container. So the containers can be configured to share the host network namespace with LXs. This can be easily done by setting the network virtualization type to none in the container config. So this indicates that a separate network namespace will not be created for the containers in our containerization based cockpit system. The containers will be associated with the host network that is the root network namespace. So here this will allow us to open Bluetooth sockets from the container. However, sharing the host network namespace with the container is something that we do not recommend as it will break the fundamental aspect of having IVI as a container and Bluetooth to be running in a container. So as we know that by sharing host network namespace with the container, it will expose the host entire network interfaces to the container. And this will bring a lot of security challenges as it might expose the other cockpit system to the external attackers. So this is something that we do not want. And so let's check some other solution that will allow us to open Bluetooth sockets from the container. So there is an out of three patch that allows us to open Bluetooth socket from any network namespace. The snippet of the kernel patch is seen in the slide. As you can see the check for internet network namespace is bypassed and the check for current network namespace has been added. So this will allow us to open Bluetooth socket from any network namespace and this Bluetooth will be accessible from the containers. This patch works with all the physical layers. So it works with UART, STIO, USP and this ensures the primary benefit of hardware abstraction that is offered by the kernel Bluetooth subsystem. So let's check a demo of accessing Bluetooth inside containers with this out of three patch kernel. In this demo we'll be using the same cockpit system that we have seen in the earlier demo. Here we have actually applied the out of three kernel patch which allows the access of Bluetooth hardware from all the network namespaces. So let's first check the state of the container. I've seen all the three containers are in running state. Now let's check the network namespaces that are associated that are created on this system. So as seen from the output there are four network namespaces that are formed. One being the internet network namespace associated with the host and other three are associated with each of the containers. So now let's try to open Bluetooth sockets from the host. So we'll be running the same test program. I've seen the attempt to open Bluetooth socket from the host is successful. Now let's try to open both the socket from IVI container. So we are attaching into IVI container. Let's run the same test program. As seen from the output the attempt to open both the socket is successful from the IVI container as well, which indicates that the check for internet network namespace while creating Bluetooth socket is bypassed. And thus we can actually access Bluetooth hardware from the containers as well. Now let's try to control the hardware. I've seen the Bluetooth hardware is accessible from the IVI container. Now let's check if it allows to open Bluetooth socket from any other container. So let's attach into cluster container. We'll be running the same test program. I've seen the attempt to open Bluetooth socket is successful from this container as well. So it indicates that the output repatch that we have used allows the Bluetooth access from any network namespace. So the Bluetooth hardware can be controlled from any network namespace. And so it could be controlled from the IVI cluster or from the host as well. Although this approach is better than the previous approach, as we are not sharing the host entire network stack with the container, but applying this patch causes Bluetooth to be accessed from all the containers as well as from the host. So as we saw in the demo, the Bluetooth was accessible from cluster container as well as from the host. And as we know that this breaks the fundamental reason of having cockpit systems wherein IVI is run as a container. So as Bluetooth becomes accessible from all the network namespaces, this is the reason that the patches thought made upstream. So as there is a need from commercial OEMs to use only upstream solutions, we need to work on something that can be made upstream. Let's discuss one such solution. So one such potential solution is to make kernel Bluetooth subsystem namespace aware. As we know that the can which provides AFCAN family of socket works within a container. So the approach here, approach taken here is to understand how namespace support has been added for the CAN bus subsystem. And similar network namespace support can be added in the kernel Bluetooth subsystem. However, while working on this, we have come across certain challenges. So let's discuss those challenges. So as we know that the CAN implementation is based on network device abstraction. That is CAN devices are network devices. So CAN devices can be added to and removed from a network namespace. However, Bluetooth devices that is ACI devices are not based on the network device abstraction. So we cannot add Bluetooth devices or ACI devices to a network namespace. So here, as you can see, there's a, this slide shows the core snippet of ACI Dev struct. And as ACI devices are not network devices, that is, they are not based on a net dev structure. We cannot add them to a network namespace. So here either we'll have to create a separate namespace for handling Bluetooth or we'll have to make a Bluetooth ACI devices behave like network devices. However, a lot of effort is required to move ACI devices from a global management to a namespace aware implementation. So your considerable amount of effort is required and to avoid certain deadlines. We have used other approaches to enable Bluetooth access from the container. The out-of-tree patch that we discussed previously, it allowed Bluetooth to be accessible from all the containers. However, in our cockpit system, we want to restrict the Bluetooth access to only IVI container. So let's discuss some of the approaches to restrict Bluetooth access to the IVI container. One such approach is to use a hostname check instead of the network namespace check. As you can see, this slide shows the patch that we have, kernel patch that we have come up with. We have added a new option that is quantific hostname. And this option can be set to the hostname of the container to which we want to restrict Bluetooth access. And as you can see, we have bypassed the check for init network namespace. So by setting the config hostname option to the hostname of the IVI container, we can restrict the Bluetooth access only to the IVI container. However, this approach works and in this demo, we are going to use the cockpit system that we have used in earlier demos. The kernel patch to restrict Bluetooth access only to IVI container has been applied. So the option that is quantific hostname was set to the hostname of the IVI container. First, let's check the status of all the containers. So all three containers are in running state. So there are four network namespaces. Each container has its own separate network namespace. Now let's try to open Bluetooth circuit from the host, as seen from the output. The attempt to open Bluetooth circuit from the host fails due to the hostname check that we have added in the kernel code. Now let's attach into IVI container and try to open Bluetooth circuits from IVI container. As seen, the attempt to open Bluetooth circuit is successful from the IVI container. We should be also able to control the Bluetooth hardware from... So let's do it. So we are actually performing scanning operation. So it was able to access the Bluetooth hardware from the IVI container. Now let's check if we can actually access Bluetooth hardware from any other container. So we'll attach into cluster container just to verify if the Bluetooth access is restricted to IVI container. Let's run the same demo program. So from the cluster container, we can see that the attempt to open Bluetooth circuit fails and hence the hostname check that we have added is actually working. Though this is a workable solution, it is just a hack and something that cannot be made upstream. So let's discuss one more approach by which we can restrict Bluetooth access to IVI container. Here we can use the mandatory access control to restrict Bluetooth socket creation to IVI container. So this approach is extension to the out of free patch that we had discussed earlier. As we know that the downside of the out of free patch was that the Bluetooth was accessible from all the containers. Here by using upper level mandatory access control policies, we can restrict the Bluetooth access to the IVI container. As you can see in the slide, we are using the SE Linux policy rules wherein a Bluetooth domain is the only domain which can create, read and write Bluetooth to Bluetooth sockets. Whereas any other domain is not allowed to do so. So by assigning the label Bluetooth domain to the process running in the IVI container, we can actually restrict the Bluetooth access to the IVI container. So processes in any other container will not be given this label and this will make sure that the Bluetooth access is only restricted to the IVI container. So now that we have discussed all the solutions that can be used to access Bluetooth from the containers, let's summarize those solutions. This table here shows the comparison of all the candidate solutions that we have discussed so far. The first approach was to share the host network namespace with the container. As we saw that by sharing host network namespace with the container, it exposed the host entire network stack with the container. So this breaks the fundamental aspect of containerization and it also increases the security threat as it could expose the rest of the cockpit system to the external attackers. So this is not an acceptable solution. The next approach that we saw was to use the out of free patch. This patched allowed Bluetooth sockets to be opened from any network namespace. So Bluetooth could be accessed from IVI container but it was not restricted to the IVI container. As we saw in the demo video that Bluetooth was being accessed from cluster container as well as from host. So as this does not restrict Bluetooth access to a specific network namespace, this patch is not upstream and it is a partial solution. So additional implementation is required to restrict Bluetooth access to the IVI container. The next approach was to use the mandatory access control to restrict Bluetooth access to IVI container. So this was an extension to the out of free patch that we discussed earlier and this requires MAC based LSM support. So here the implication of the solution is that the upper level data policy needs to be changed every time the Linux security framework changes. So suppose we were to use MAC instead of SC Linux, we'll need to write a new data policy for the same. So this is viable for specific product but it cannot be reused across multiple platforms. The next potential solution that we discussed was to make a Bluetooth kernel subsystem namespace aware. So we saw that this requires a lot of effort as SCI devices are not network devices and they cannot be added to a network namespace. So here we can either create a separate namespace for handling Bluetooth or we can take the effort to move SCI devices from a global management to a more namespace aware implementation. So here we want to understand from the community the upstream able way to implement this. And we want to discuss if the effort required to make the SCI devices act as network devices is worth the effort. So the next approach that we discussed was to add a hostname check. So this works without the out of free patch. Here we just need to add a new config that is config hostname and set it to the hostname of the container to which we want to restrict the Bluetooth access. And the Bluetooth will be restricted to that specific container. However, this is something that we should not go with as it is just a hack and it cannot be made upstream. So the next approach not approach but rather a BT stack software architecture that we discussed was to use the complete user space stack. As we know that there are certain user space stack and as the dominant BT interface is like UART and USB are just simple character devices. They can be easily added inside the container. So by using complete user space stack along with such a BT interfaces, we can access Bluetooth from the containers. But this is a product specific and though it is visible, it does not benefit from the hardware abstraction or it does not utilize the other benefits of the Linux kernel Bluetooth subsystem. So now that we have compared all the candidate solutions, let's move to the conclusion of this session. As we have discussed the challenges that are associated while accessing the kernel Bluetooth subsystem from the containers, we think that the best possible solution that can be made upstream is to make the kernel Bluetooth subsystem namespace aware. As this has certain challenges, we will really need to understand from the community if Bluetooth is to be made part of the network namespace. In this case, how do we add the Bluetooth devices to the network namespace? If Bluetooth is not to be made part of the network namespace, then should we go ahead and create a separate namespace for Bluetooth? So there are a lot of questions to be answered where we will need to sit with the community and the industry experts to understand how can we work and contribute in making Bluetooth subsystem namespace aware. On the other hand, we see that the trend of using complete user space stack which provide Bluetooth access from the container without these challenges is increasing. So if we are moving towards such complete user space stack, we want to understand from the community if it is really worth spending the effort to make Bluetooth namespace aware. And we need suggestions from the community and the industry experts to take this forward and we would really like to work to find an upstream solution for this problem. So the floor is open for any suggestions. We will be more than happy to take any suggestions on how can we move forward with this. So thank you.