About this talk
This talk discusses the cybersecurity challenges faced by operating systems in software-defined vehicles, highlighting the critical need for collaboration between the automotive industry and the open-source community. The speaker emphasizes the importance of standardizing middleware and operating systems to streamline the automotive software stack, which has become increasingly fragmented. They introduce the ECADA initiative by the European Commission aimed at fostering competitiveness and technical sovereignty in the automotive sector. The dialogue also examines the transition to a centralized vehicle architecture, enabling enhanced software updates and functionality over the vehicle’s lifespan. Additionally, the role of hypervisors and the need for security assertions in operating systems is explored, particularly in ensuring safety for automated driving. The talk concludes with a call to action for shared solutions through open-source projects like Eclipse's SDV S Core, which could address current software gaps and improve overall cybersecurity.
Full transcript
Thanks everybody. Thanks for coming back from the lunch break without significant break off in participants and choosing our talk. We know there's a lot of variety of excellent talks on this conference and we are honored you choose us. Today we bring you a topic which is of high relevance to the so-called old economy which can only be accomplished with you, with the representatives of the free and
open source community. We need you. And in particular, we bring you a talk about cybersecurity challenges in operating systems for the software defined vehicle. And who is we? We is basically my colleague Dr. Rodrigo de Campo of Sekunet company. Sadly, he was stricken by a sudden illness and he can't be with you. But I'm trying to make it up to him, of course. And myself, Michael Gerhardt
Schneider, I'm principal expert for product at Arriver and Arriver is a name which is not around for that long, but you might know Continental Automotive Systems. That is the company which actually you know is this company after its spin-off on the stock market last year. So let's look a little bit what we have for you today. And we're starting with nothing less than the attempt to explore
why open source might just be the silver bullet to meeting all the challenges of the automotive industry. Then we will be looking at the role of operating systems through the lens, through the goggles of cybersecurity for the safety of the road user, of course. After that, we will try a comparative view on operating systems and their role in automotive use cases, and then nicely finish it off
with some insights into the challenge space of harnessing under security aspects and auspices. So, let's take a little time to state the stage where we are as an industry and as a society. We all know that we are undergoing a steep and and grave demographic shifts, and we are moving towards a digitally empowered society. Trends like urbanization, indus- individualization, and the digital lifestyle is, you know, just
how our socie- our society evolves at the moment, and which um also shapes our consumption behavior. And as an industry, we cannot deny that we uh we shape our product offerings to what the market demands. Is that is what enterprises do. And that's why we are all experiencing the next-generation mobility, which is characterized by exponential evolution of technology and technology offerings. We talk about the software-defined vehicle,
and when we do that, we mean server-zone architectures, edge computing, what have you. And all of this is cloud-empowered, is working robustly, and of course cybersecure, because nobody wants to be in danger. And no slide these days can can be complete without mentioning AI and virtualization and big data. You just have to have those buzzwords. And they are basically um no show. They are really driving our
life these days. You all know that. But there's even more to it. Um the underpinnings of all of those evolutions is a change of our ecosystem um on which user behavior and product offerings uh work as a substrate. We see that we have a lot of new market actors. You see that people and companies from far away continents are entering the market with force. A market that
decades ago was more or less um firmly partitioned but today is fiercely fought over about market dominance and and having share in Slides like this I'm sure you are no stranger, but they are necessary to exemplify where we came from and where we're heading to. So, on the very left side you see what we refer to as the old or the traditional architecture in vehicles which was
characterized by gazillions and um a large number of individual electronic control units with their isolated functionalities and at best there were certain networking connections between um the units which shared certain domain functions or had to interact. And on the very right side you see a projection where this could be heading over time. And this is basically the end stage of a centralization evolution, which is two mega
trends. The one is up integration and domain and zone centralization, reducing the number of individual computational units. And the other one being a radical rearrangement of software. Because obviously, if you want to keep and contain the software and functionality you had in the past, and you don't want to miss in the future, you have to rearrange it, to repackage it, to refactor it. And as we all
know, being software people, that presents a lot of challenges. After this more statical view about what's happening in the inside of the vehicle on architecture perspective, let's look at the software life cycle perspective a little bit. On the upper half of the slide, you see your past as a vehicle um purchasing customer. So, in the past, after you have bought your freshly configured car in the car
dealership, you only could expect to get software updates in cases where there were, you know, imminent callbacks uh or you were safety or security problems of any sort, major bug fixes. And for the rest of the usage period, more or less, you were left alone with what you had purchased. But then, enter the software-defined vehicle, by a decoupling of hardware and software using the magic bullet mechanism
of abstraction. And what this mechanism does is it allows companies to maintain the so-called middleware in the vehicle over time. And this again presents the opportunity to provide the customer with new function and new service offerings over lifetime. That is what the market thinks, what is needed and that what we see the customer is calling for. But of course, that requires to do something on the level
of the software platform, middleware and operations system. But I was being uncordial. I've been using all these terms for which I know there are multiple definitions around even on the technical stage. And that's why I take a second to define what we will refer to a software platform, middleware and operating systems. So basically, the platform consists of the middleware and the operating system. And when I talk
about middleware, I refer to the part of the software stack which is between the application and the operating system facilitating mainly data exchange and communication tasks. And when I mean operating system, I mean basically what is between the middleware and the hardware itself. Both very uh important you know, parts of the stack which have to do with hardware abstraction and also um providing new software offerings. So,
let's take a further look of why we think that there is evidence that uh open source software might just be the solution for Europe's problems. Just lately uh by the European Commission, the so-called ECADA initiative has been launched, the European connected and autonomous vehicle alliance. And if we look at the mission statement, you find all the right buzzwords. Autonomous, software-defined, and being geared at competitiveness and technical
sovereignty. So, thank you. if we take a deeper look, we we see the individual um work packages or items uh which are part of this initiative, uh predominantly projects of common European interests, and to have input on European regulation. And um as I heard many people say on this conference already, when you talk about input and regulation and open source, the CRA cannot miss in this context.
And especially on the ORC compliance track, you will hear a lot of these talks, and I am sure they will be very interesting. So, all in all, ECADA is trying to put a nice wrapper around all these seemingly independent initiatives, all in order to borrow the words of Mike Milinkovich today is, we need an umbrella project management for all of what is going on in Eclipse and
the the this uh ECADA initiative might be just that. ECADA itself has been suggested by the automotive industry in a white paper, and you will see the link of the white paper on the bottom of the page, so you find that on the internet. I'm not going to read it to you here. you know, it's interesting to see um that this white paper is kind of a
dissection at the problems which the automotive industry and supply chain thinks it is facing at the moment. And there are a lot of categories of challenges, but for the sake of brevity and keeping it together in this talk, I only want to um focus myself on the software stack and operation system and middleware. And there is the clear um statement that inconsistent operating system and middleware building
blocks are a huge part of the problem what we are having. And we will dissect this further going forward. Elaborating on the problems we have with the the software platform and the middleware is we have to rebuild the middleware basically from the ground on in every project that we have. We see a lot of OEMs, we see a lot of suppliers, and somehow the industry has the
impression we are reinventing the wheel for this part of software which kind of should be standardized already for decades, but we're still doing it uh seemingly for every project individually. And here come the open source benefits which could just be the solution. So, in the open source hemisphere, we share see shared and open source stack solutions for non-differentiating functions. We see um advanced mechanisms for hardware and
software abstraction and to create modular software. And we see also um industry-wide standards for middleware involving uh through the participation and evolution of open source. So, it's obvious we have problems, open source has solutions, so let's bring it together. And here we're coming back where problem, solution, and initiative meets the cover initiative and what Eclipse does with the Eclipse SDV S Core project, which in the mind
of many uh participants and and uh representatives of the automotive is a crucial initiative um that feeds into this overall picture of what we're trying to do in Europe. But, you know, I I put it out front. I'm you know, a cybersecurity person and so that's where I want to put my point of view and and the lens of what I'm looking through. So, let's look at
all of this through the lens of cybersecurity as supporting property of safety on the road. And what you see here is a first glimpse at I would say that's the scope of S Core. And I talked about, you know, standardizing this whole software platform. And this is what you basically see um in the dotted boundary in the middle. That is the scope of S Core. That is
what it is trying to standardize. And it's trying to reach a point where we standardize all non-differentiating software in this stack, where we have working bridges for operating systems and applications, where we have standardized work products and solutions for safety and security in order to deal with the compliance overhead of creating all the evidences and all the work products where we reach hardware independence and what's important
because we are free market, we are leaving nobody we have behind, no vendor no supplier, no OEM this is a democratic solution. In that sense I I basically have to um to elaborate a little bit that when we see the operating system and the hypervisors in the bubble of the self-software platform we still will have operation system and hypervisor vendors, don't get me wrong. It is just
that they will be, you know, hidden away under a different layer which is called operation system abstraction. And that is one of the the main topics that I want to treat or that we wanted to treat in this talk is elaborate what we should pay attention to when we are abstracting away the operation systems and the hypervisors to make sure that we still have a functioning vendor
market in all of this. So, why are operating systems and hypervisors so important for the safety and the security perspective? Because they run in privileged and protected modes and they encapsulate a lot of software which is often used, which is often called system calls. And the operation system governs the the scheduling and the interrupt handling and makes sure that in fail operational systems like in automated driving
certain applications can fail and can be restarted while other ones which are safety critical keep on going and keep you safe as a driver. Very important. And at this point we introduce the term of a master hypervisor, which many of course you know, but for for all others, that's basically another mechanism for example running many guest operating systems on the same silicon and creating another layer of
hardware abstraction. And the hypervisors again, they do a lot in the term of safety and security assertions. They help us create freedom of interference, and there's different kinds of that, like for example spatial, temporal, and functional freedom of meaning memory protection mechanisms, meaning control flow integrity for the software, and meaning um separation of functional concerns with different safety and or security requirements. And especially the hypervisor helps
us also keep confidentiality, keep availability of system resources, and helps us to keep our software in the state of integrity. For example, that software cannot be manipulated, cannot be tampered with, and that you have all those assertions which you have also heard of, you know, in the previous talk about automotive operating systems that of course applies to this project, too. And what we see here is a
first attempt looking at the complete scope of the AS Co project from a functional um showing all the desired functionality uh as functional blocks on the system level. and what we have done in order to create kind of a scope for what we first to as operation system and hypervisor relevant we have created this red delineation line which basically is a boundary box of all the functional
concerns which we see as operation system and hypervisor related having affinity as we say and you will see that there are functional blocks which are marked with the shield symbol signifying particular affinity to cyber security and those are the functional blocks with direct security focus. All the others of course having indirect cyber security focus or exposure. And if you look at the sheer magnitude of this boundary
you see that operation system hyper security and security relevance makes quite a lot of the overall concern of the scope of this S core project from functional perspective. And so in order to give evidence you know for for our argument you know creating this um partitioning we have looked at hardware abstraction aspects of operating systems we have looked at um the elements of low-level networking like for
example creating low-level networking stacks and and routing mechanisms and lastly we have also looked at functionality for resource and process management. And uh in the last bubble one line item sticks out and that is for example the of system call interfaces. And that is basically where the term abstraction, for example, of operating systems meets a vocabulary that many have used. Also, you know, the last talk about
operating systems, which is POSIX. And for those of you who don't know what POSIX is, that's a generalization of operation system functionality, which is around for a long time and which was originally conceived in order to deal with portability needs and demands. And so, this term is going to stick with us for a while. Operation system abstraction is important because all the functionality that you have seen
will be abstracted through the Escort project. what we can see so far is, of course, on GitHub, in the official documentation, we have requirements for the operation system abstraction. And this is fantastic because that is a good starting point. And what we also see is that we have an idea to create this operation system abstraction on the POSIX standard in order to enable POSIX-like or POSIX-based operation
systems like Linux and QNX. And also, what what I found very good and encouraging is that are also safety assertions or safety requirements tied to this requirement. So, it's hard to see on this slide. So, I have rephrased it um for you as the audience. So, explicit requirements coming from what I can see on GitHub are the OS abstraction security concept shall enable safety assertions up to
ASIL B and you have heard that a lot. That's a safety requirement on a scale from QM less safe to ASIL D more safe in very general terms. And the OS abstraction layer shall accommodate POSIX-like operating systems and shall be vendor neutral. But at this point, I like to introduce an implicit requirement which is not written there, but what I think needs to be injected in order
to tell the whole story. The operating system abstraction layer shall address the functional gap not specified by POSIX, but being created between POSIX specification and the aggregate functionality of all operating systems which are on the market. this is just a selection of a few of the specification gap which are uh basically manifested through evolutions for example in the real-time Linux kernel um evolution and between the lack
of specification uh on the POSIX level and you will find deltas in scheduling, interrupt handling, hardware tuning, timing, and and kernel configuration. if S-Core wants to create an operating system abstraction which is really vendor neutral, which helps the industry, and which uh maximizes the effect uh for, you know, different operating systems and different this should be dealt with. Now, take it, you know, on a more general
level. So, now that we know that there is a gap, how do we look at the aspects of this gap? What is the good, what is the bad, and what is the ugly? And at this point, um you know, I'm I'm not going to tell you all about the line items. I'll just read you the first line, which contains two quotes of the absolute fan favorites in
the cybersecurity community. So, what is the good about the gap? Knowing the gap and knowing that it might be a trap is avoiding it. That is an uncredited quote of Admiral Ackbar after the Battle of Endor. The bad is, while POSIX gap analysis is in going, security has to work with claims and assumptions. And if you have ever uh talked to security people, they are chronically critical
and they don't like uncertainties. So, they always want to know what they're dealing with. And in order to to drive this point home, this is the real ugly of, you know, projects in their, you know, concept stage or in the beginning stage, you can only know what you protect or protect what you know, and this is from Bruce Schneier, um the number one cybersecurity evangelist. So, let's
now dare to take a comparative view about what today is reality in the automotive industry in terms of mixing operating in the same system. So, this slide in itself is very busy and would merit a complete talk of itself, but I'm going to simplify the chart in order to amplify my message. What you see here is from left to right four guest operating systems on four distinct
cores on one silicon. And they all have their own operating They all have their tailor-made application stacks. They all serve different purposes and they have different safety assertions. What you see with the different ASIL levels on the top of each stack. they will be um more or less in most projects OEM chosen or be dictated by the properties which are expected. And the applications um range from
applications which are statically installed, for example, of on the leftmost core to uh quasi app stores uh on container runtimes on the second to the left QM core. And to drive this point home, this is what a a cover or S core has to enable to make sure we can do things like that and even more complex things already in the future. Mixed credit criticality let's say
driven uh to the excess, I would call it. So, this is no science fiction. This is actually an architecture of an H and I system which is really in serious production. So, in order to measure the depth of the challenge which this project is facing, we tried to measure the depth of this challenge. And what you see here is an overview chart uh on the Y axis
featuring the most um prevalent or more distinctive properties of operation systems. And then on the X axis um a selection of the most prevalent operation systems in use today from our vantage point in the automotive And they are being separated by a thin red line in the middle according to their criticality focus. On the left side, the most highly critical geared operation systems. And on the right
side, the ones with intermediate or lower security or safety focus. And of course, there can be debate where the red line should be. But the point we are making with this slide is not to intimidate anybody. It's to measure how deep is the challenge for the product to pipe all this functionality and its uh variants through an API interface of an operating system abstraction without creating a
tech surfaces or hindering portability and vendor neutrality. as it is very uncurtious or it would be rather uncurtious only to show problems without giving hints for solutions, we have tried to conceive a set of, if you will, um best practices or or rules, which we have shamelessly stolen and derived from the OWASP top 10 of API security, and tried to um you know reformulate it in the
scope of operation system you know as we are short in time, I'm just going to you know pick out a few of those. For example, what we think is essential that APIs should be strongly contract driven. It means that between the user space and the operation system there should be explicit and kernel enforced mechanisms. Or on another note, there should be a so-called version minimization, which means
you have the choice when adding a new functionality to create a new version of an old interface, don't do that. Rather, create a complete new functions or as some scientists say, no mutations in semantics of existing ones. And and all of this information is out there. It's basically state-of-the-art. None of this is rocket science, I'm sure, but somebody has to do it or a group of people
with the same goal has to do it. It is just what we need to do in order fulfill our vision with this initiative and with this project. And if I had only one slide, you know to drive the point home or to give you know good advice to people who actually you know put their finger on the buttons and and type source code or tell it to
an AI for coding these days, let's let's make the scope of a project very very clear. Tell what you do. Tell what you not do. and that is very important because even if the project is too ambitious and you see you have to cut back cut back explicitly because then other people can develop better workarounds and make safe and secure workarounds. With regards to the innovation and
portability trade-off. That is just the fact in our ever evolving technology. You have from the get-go to plan an API to be deprecated for example if you bring a product into production. So when you create those abstractions for also plan for the deprecation of interfaces that will in the end make the code a more secure. to get back to the specification gap between POSIX and the aggregate
functionality of all operating systems. Get it documented. There's no way around it. It needs to be explicitly laid down because then it can be filled with communalized definitions or new specifications that again can be standardized. But overall all of this is doable because really you know we put people on the moon and we again made them surround the moon and the challenge is doable. We just have
to know what we protect and do it. And there is an overall positive message around for those who are forced to accomplish those goals in a short time or have similar goals in their you know product development. You don't have to do it alone. There are business partners and for example, my company automotive prides itself with having system integration services, uh tool support, providing developer environments, safe
and secure compliance, work products, processes, and consultancy, as well as virtual test environments. And we pride ourselves in supporting the S-CAR initiative and the CAR and we hope this is off to a good start because to re-quote Admiral Akbar, to know a trap Thank you for your attendance.
