 Okay. Hi, everybody. Welcome. And my name is Ilana Koperman. I'm calling in from Israel and I work for Mobileye. And this talk will be about some work which we have been doing with the Linux Foundation for enabling the usage of Linux and safety applications. And just to set the context, I do not come from the safety assessment or safety standards community. I work as a system architect. So I have many years of experience in embedded Linux systems. And what I do is to try to help to design solutions for the safety and security issues. What I'm going to speak about here is what I call bridging the gap because the project ELISA is all about trying to help to allow, enable the usage of Linux and safety applications, something which has been a major problem in the past. And to see how we can all work together to make that happen. So to go into more detail, okay, a little bit of background. Again, I don't know who I'm speaking to. But deploying Linux and safety critical systems has been a major challenge to date. So those who are experienced in using Linux, they obviously are familiar with the benefits. Linux provides many features, subsystems which enable to, to develop complex software. It has strong security capabilities. And one of the really important aspects of Linux is that it gives us the necessary software interfaces to virtually any underlying hardware with which we need to work with and an amazing community with which we can cooperate and work together to provide real solutions. So for those reasons, people who develop safety critical applications have been looking to Linux to use it in safety critical systems. The problem is, though, that Linux, in order to be used in safety critical systems, it has to pass very stringent assessment processes which are defined by safety standards of different types. I'm not going to go into those details for those who are not familiar. But the process is a very strict and binding process which basically gives the liability to the people who produce those software applications to ensure that they have done the most possible to prevent any harm to human life or any loss due to the usage of that software. And that's where things start getting tricky because Linux, obviously, hasn't grown and hasn't been developed in a way that matches the strict documentation testing and assessment requirements for the safety standards. And that is where we have a major problem and where we are trying to bridge that gap and to bring the two sides together close enough so that we are able to actually deploy Linux in such systems. This graphic, and I think we should sort of keep it in the back of our minds. The work of Eliza, the group that we established for enabling Linux in safety critical applications, is really all about minding the gap. And it's really tricky in this sense. We deal on the one hand with people who come from the world of safety assessment, which has very strict standards, very strict compliance rules, because at the end of the day we're dealing with legal implications and potential risks to lives for these type of applications. And on the other hand, we have the open-minded community consensus, which we see in the Linux development. And the two communities need to work together, and that's what we're trying to do in this group, to bring Linux down into the world of safety critical systems in a reliable and effective way. So when we started, and this is sort of like, I don't know, the quality of maybe startup mode, trying to figure out how can we do this. So there's a lot of pressure from industry, and that's where myself and other people are coming from. There's a lot of pressure to use Linux in safety critical systems, and particularly where I come from, which is the automotive domain, but in many other areas as well. Linux is a strong choice for the reasons which we mentioned before. We had to get together in order to set up the foundation, which is what we have been trying to do now. And what happens, we are trying to define the necessary level of functional safety, which will basically give us the ability to manage the risk in our product development. As I explained before, when we deploy an application in a safety critical application, we have to be sure that we can evaluate and manage that risk, and to ensure that we are well, we have that well mapped, and we define relevant mitigations for any anticipated risk. But on the other hand, when we are using Linux as the foundation, we have to really, really understand the implications of what Linux on the one hand is providing the power, and the potential misuses or problems which can come up because of the different features, the configurations, the different ways in which we interface with drivers, hardware, and other elements of the Linux system. So we need to be able to really understand where we are coming from, what Linux can provide for us to enhance the safety of the system which we are trying to produce. And we also need industry collaboration because if we are dealing with theory, then we are not really getting anywhere. So we have to deal with practical, real-life examples which have a real business need, and to see how we can actually use Linux as the operating system in such systems. So a summary of what the Alliance Admissions Statement is all about. We want to define and maintain a common set of elements, processes, and tools that can be incorporated into specific Linux-based safety critical systems which will eventually be amenable to safety certification. So if you see the Mission Statement here, the real goal is to define different software elements, different processes, tools, anything that will help us so that when we use those in an appropriate way in a specific context, the resulting system will be more amenable to safety certification. I'll go into a little detail later what we are not trying to do. Just one point I want to make clear right now. We cannot provide and no one can do that. A one-size-fits-all Linux kernel which is perfectly secure for any application. Okay, anybody who is familiar with Linux will understand that that doesn't make sense even to try to go down that path. What we do want to provide is a supportive infrastructure, technical supportive infrastructure which will enable people who do want to develop Linux-based systems for safety critical applications. If they use those guidelines, those tools, actual internal patches, whatever it may be, if they use them in the correct way, they will then be able to bring their product to be certified for use in a safety critical context. And we are working together with the Linux Foundation and with the different standards bodies to make sure that all of those elements each on its own bring us a bit closer to that goal. But obviously that still leaves the choice, the integration, the implementation up to the individual user. And we cannot know project or working group can possibly provide a single Linux kernel which will be certified for use in any or all safety critical applications. Okay, so what are our goals? I mean I think more or less it's what I'm talking about. Before we want to provide those basic building blocks, we want to be able to, one of the things which we have been working on is what we call our reference process for safety assessment. We found that for many reasons to take Linux and to get that certified following the documents of the safety standards was not possible for many reasons. A, because different safety critical applications have to abide by different standards. And B, because the language that's used there is not so well understood by people who come from the Linux background. And also because not all of those documents are accessible to everybody who comes from the Linux community. So the idea was to work together with the safety standards communities and to do that in two stages that on the one hand to define a reference process as an intermediary step and then to have that reference process assessed and mapped onto one of the relevant safety standards. So that the people who are working within Linux when they want to define how they abide by the standards they can work with that reference process and then leave it to the safety experts to map what they are using and how they are doing it onto the original standards themselves. Which is a process which hopefully will enable everyone to focus on what they are best at doing. What we also want to do is to help support business entities in order to that they should be able to take the outputs of our projects, different tools, guidelines, processes, whatever we define and use them, package them, implement them, deploy them in their safety critical products. And this is all about communication bridging the gap between all kinds of different communities all together working so that at the end of the day whatever our work products that we produce will be acceptable by all. Okay, how do we measure success? I mean it's a bit early on the project but these are the standards which we define for ourselves and as I said before we're still a bit of a startup mode but we do have some preliminary results. So the first thing what we want to do is to have actual tangible deliverables. Okay, we want to focus on certain, we are doing that already and I'll go into detail soon into some of the work groups which are set up and working. But we want to identify which kernel features are most relevant for safety assessment, which tools we want to develop to be able to help us to that goal. And we are keeping track of work that's being done on different use cases so that those will be established as examples for future work as well. Okay, what I mentioned before defining that reference process which is an ongoing project, we want that it should be usable, maintainable, easy to maintain that product that is developed and is proven to be safety critical, we can maintain that over its lifetime. It has to be accepted and this is a very important point by everybody involved because I mean we can say that we love Linux and that we appreciate its features and how it works but we need that it should be accepted by the safety community as well. Okay and at the other end of the spectrum we have to get the hardware support from the underlying hardware to make sure that whatever we define actually is feasible and can be implemented on any relevant platform. Okay, so there are many goals here which all work together and as I said before I don't think we'll end up with a complete perfect one size fits all solution or anything near that but we do want to help so that business entities can come much closer to that goal than is possible today. Okay, what are the limits? Okay, we certainly will not engineer your system for you to be safe and we cannot ensure that you will do it properly and we won't create a single out-of-tree Linux kernel which you just have to plug in for your safety critical applications and obviously you have your own responsibilities legal obligations and liabilities to implement things appropriately but we certainly want to provide a path forward and do that in some way that Linux works by collaboration. Okay, if there's any questions? Okay, now currently we have three work groups with a fourth one which was just born last week and this is where I'm opening this to the public. If anybody wants to they can contact me afterwards see how they can get involved see where they can contribute see what they can gain from this collaboration and that's what I'm really looking for here so that we can have a more representative set of contributors so that we can actually work better and get better results. Okay, the work groups here are not listed in chronological order but whatever one work group which we have is called the kernel development process work group. This work group was really started because of based on one of the bullets which had I think on the second slide. In the past it was this concept of Linux as a non-secure a non-safe non-software product which was developed by people who didn't follow any process who couldn't make any clear statements about the quality or the or the or even the requirements architecture test coverage anything like that nothing could be well documented and proven about Linux. So I think anybody who works with Linux realizes that there's a lot of power in Linux there's a lot of power in the Linux development process but it just works in a very different way than the pretty much waterfall type of of execution flow that we see in or that is expected by from the safety standards. So basically what we are trying to do is to assess the kernel development process this is this is a project which took about six months and a lot of work was done here and together with the safety community to prove what actually I called you know the bringing out the good in Linux demonstrating that there are many aspects and we'll see in the next slide or whatever soon we'll see some examples we analyzed based on the common Linux safety standards and our reference process we divided the kernel development process into different categories and we're able to assess what is currently done to develop Linux even if it works differently than how the the safety assessor is expected to demonstrate that it we do have that quality which is built in we have the power of the peer review we have up the power of the mailing list how people communicate together how the release process how things work in Linux development to demonstrate that there is actually method a strong methodology in the way Linux is developed at the same time however obviously we found that there were some major gaps which were exposed and we'll go into that soon but one of the important things which we're working on now are trying to fill in those gaps so that we bring Linux closer to acceptance for usage in safety critical applications and we are working on different areas to fill in those gaps we have identified five areas which are currently in high focus and with time we hope to cover more a second group is is the kernel development process is really dealing with the nuts and bolts of of Linux as a software component the different features the another work group which we have is called the architecture process work group which takes things takes things up on a higher level and it looks at the architecture of Linux again as a software product and it divides it up into what they call chunks for lack of a better term it's not really components it's not features it's different areas for example memory management or schedule those are two areas which are very focused for safety analysis and what they're basically trying to do there is do this meta analysis of safety and to help people to understand how they can take those different areas and implement let's say for example memory management in a specific use case in a specific on specific hardware platform based on features which exist already in Linux and features which may need to be added okay so that's the focus of the architecture process work group which basically takes similar to the work which we're doing in the kernel development process work group but takes that up more on an architecture level we take into account interactions with other software and hardware components within a specific use case the focus here was on various use cases but because of the the current set of contributors I mean we're pretty much a lot of us are coming from the automotive domain so that and we ended up splitting this into a separate automotive work group which will focus on features and safety features and enhancements and what can be done specifically to meet the requirements for software products in the automotive domain and that's that's the new group the automotive work group which was just created last week and that work group will do similar work but focused primarily on the automotive domain and we have representatives there from AGL people are familiar with that and other major car manufacturers etc working together to try to define relevant solutions because there's a lot of pressure to be able to use Linux in automotive applications and the third group working group which is actually was the first one the third group which is actually the first one is the what's the name has been changed to the medical devices work group and I guess this is in the spirit of the times it originally started off this was the first work group it was really sort of as a as a brainstorming type of first use case there was a system called the open APS artificial pancreas system which is with open source to use to monitor glucose for diabetics and whatever but and I'll have some slides on that afterwards because of the pressure to produce increase the production of ventilators due to the corona crisis ongoing so there's pressure to develop open source ventilator systems but obviously ventilators are very safe to critical systems which are you know life threatening if there's some malfunction which is not properly managed so so it's expanded rather than focusing only on the open APS it's also expanding into other areas of medical devices okay there are two questions I'll answer my contact information I'll share it I guess at the end I don't think it's on my slides but I I thought that in the system for the conference so Nelia maybe can help me with that or I don't know maybe I'll put it in the chat and also definitely we are open to any use cases these are currently the use cases there's another question about industrial real-time use cases there is interest we just don't have people who are are there to to pick it up and take it and to lead the effort but definitely those are of interest they're important and we need more contributors okay so definitely they are related and the groups all should and will be working together with the same common goals but each one focusing on obviously different safety standards and different specific risks and and focal points okay so going back to what I said about the kernel development process work group I think I'll go quickly over this because I think I more or less gave the background in my speaking our work has been divided into two phases first we define this working reference process it took quite a while because like I said you know about bridging the gap we're dealing with two very very different kinds of communities and at times the communication can be a bit noisy let's call it but all in good spirits and the point really is that we want to develop this reference process to make it easier to communicate okay because people who are kernel developers or develop software or software architects or whoever it may be who develop drivers that are not really familiar with the bits and bytes of safety standards so a little bit hard for them to to deal with the legal terminology and the reference process was very helpful to again to bridge that gap I want to emphasize again that they're not in place of safety standards it leaves the work of of having that reference process assessed and accepted um as a second stage but that we've been working with the different standards communities to to to help ease that process as well okay because it's done in in a in a method method methodical way which which helped for the communication on both sides okay but as doing the in doing the assessment we found that there are certain gaps and for each of those gaps we can say okay well for example in the automotive domain from which i'm coming um those gaps are not relevant and we we don't have to deal with them or we can provide mitigation mitigations which are relevant um and which are specific to the use case and we and the other the final option might be to um to work within the community to promote change to get support to add features which are relevant both in that particular specific use case and in the more general domain and basically what we're aiming for is really to promote linux as a viable candidate for use and safety critical applications um you can hear different points of view and certainly when we started this work the attitude was no way linux and safety critical applications are totally far into each other there's no way that we can get that of linux to be approved but slowly we are trying to bring the gap bridge that gap and bring the two sides closer to each other okay um all right that's a bit of delay wow okay i have color markings on this and i see them on the bottom but now i see they don't show up so i'll tell you what color coded don't see it interesting okay anyway um this was the list of areas which we analyzed based on the reference process and um some of these areas for example change configuration management that's well managed by um by the linux development process so there wasn't anything really major to discuss um relating to gaps where we did have um we we did identify more major gaps which we need to deal with are and again if you'll get a copy of this slide you'll see they're color coded in yellow but okay i'll just have to tell you where they are requirements definition um obviously linux kernel developers don't have any formal process for defining requirements um static analysis there's some ongoing work but it's not a requirement we don't get full coverage there isn't a single tool but there's a lot of great ongoing work which can be expanded kernel testing similarly there's um linux has come a long way and there is a lot more available tools which can be used and which are being used and which are being enhanced all the time to ensure the quality of the the code that's being developed for obvious reasons i mean the the um the the maintainers have their own responsibilities for the quality of the code and they want to be sure that um there's no regressions when they or minimize the risk of regression when they release code because of the volume of users and the volume of the different applications and um so there's a lot of work that's ongoing there um the fourth area on which we're focused right now is the the build process how we configure um um how we configure the the kernel to be used in a safety critical application what type of criteria do we use to um to decide which features will go in and which won't and um et cetera okay we'll we'll have the next slide we'll go into some more details and the final area is the how we introduce new features and patches um both as safety mechanisms to deal with safety issues and in general if we want to introduce new features how we get them um assessed approved and released to to um meet the functional clients which we might have in a particular use case and to do that in a way which is acceptable by the safety standards so those are the five focal areas on which we are um working right now in this group okay so the first area was defining some kind of umbrella criteria similar to what we see in security what we would call bug classes so in a similar way to define um what are the criteria for a safe uh Linux release safe it's written with double quotes because it's it's not going to be really a safe Linux but it's basically criteria for assessing the safety level or the safety quality let's call it of of our kernel image which we're using in a particular application okay so for example I gave a list here of of different kernel configurations which we are currently assessing for use in safety application that focused on memory protection this is an ongoing work so this is not a finalist which is going to be deployed but basically to try to assess each of these um kernel configurations to understand to be able to define in terminology which is relevant for safety assessment what the expected value added value for any particular kernel configuration may be and perhaps um warnings caveats when it's less relevant more relevant for example if there's a performance impact or if there are certain um functional requirements which contradict are contrary contrary contrary to the use of any specific configuration okay the last line what talks um is about freedom from interference which is a common term used in the automotive safety domain we want to ensure that if you have a software component which we have tested and proven um in a standalone way that it it um satisfies certain requirements provide certain results give certain level of quality we want to be sure that we have um that is it won't be impacted in any way and I won't go into details of that but it won't be impacted by any other software or harder component which will interfere um with how we expect it to work and again here are some examples and again each of these has to be assessed and we have to provide guidelines when it's relevant and when these should be used and how they should be appropriately used but we want to give this as a set of tools that if somebody wants to um use these for the kernel configurations in a safe way that they will be able to to put them together and some of the configurations are more relevant for testing or approving that um there are no um memory memory violations etc and and and and those can be used as well in the safety context okay these are again these areas are ongoing work static analysis um where we focus on on different areas of um uh also again based on the the first bullet about the criteria um we've been focusing on on Cochinel there's some typos I apologize in this version which I corrected but when I post my final slides I'll correct them Cochinel it's misspelled here okay but anyway we've been analyzing different semantic patches how they're how they can be used and which and to define a sweet uh a set of semantic patches which are relevant um for safety analysis in particular and again covariate which is already aligned with various safety standards what is already covered what needs to be covered and how we use that effectively um to ensure the quality of of the kernel the Linux kernel and then there's kernel profiling a lot of ongoing work right now on ebps and how they can how it can be deployed to help with kernel profiling including the the definition of the capability of the bps capability and perhaps alignment with how that um can be um can work together not only for security um context but also for safety again these are ongoing projects and again people who are interested who want to join who want to contribute these are the kinds of things which we're working on long-term goals these are the next steps and long-term by us it's not you know whatever it's probably those projects are now where we worked on the reference process and the assessment for about six months this is the coming the current six months perhaps to the end of 2020 and towards the end of 2020 we're going to start working on these additional areas some of which are already started and again depending on the people who contribute um we want to be able to to do some analysis of developers mailing with to generate requirements from the mailing list and with appropriate tagging this is feasible and we need to work on some kind of proof of concept and start um expanding this work and the the goal obviously is once we have requirements we can generate requirements based test templates and this will come a long way of establishing the quality of um the linux kernel without forcing kernel developers um to I don't know what I like to call to wear a suit and a tie when it doesn't match their lifestyle and we can because the mailing list do have all this information in one way or another to have some um established play by using the appropriate tags and and appropriate crawlers um data mining tools um to put together to to generate those requirements document them and to generate from that test templates based on those requirements and similarly to to generate the architecture documentation which is needed as evidence of the the quality of the kernel I think this is probably even easier because the the linux kernel already has a very well established um software architecture okay testing there's a lot a lot of ongoing work this is not related only to safety there's a great deal of interest in expanding this and um different frameworks which exist and lots of great ideas and here I'm looking here I just noticed my time is almost running up this is the most fun part the kind of stuff which which I deal with mostly on a day-to-day basis defining different safety enhancements to the kernel source and getting the different contributors to upload those to the to the kernel and to have them available as templates as reference code reference implementations with appropriate guidelines for use by all people who want to um develop safety critical applications okay so there's a lot of work here and um and again I'll I'll send out one way or another I'll send out my my um contact information and people who are interested um certainly will be great um to see people joining signing up joining and contributing okay the safety architecture work group um I talked about before it deals with documenting the the linux the what we call the chunks defining the safety requirements on those chunks how we expect them to use and and those and and those requirements are basically derived from the specific use cases which the contributors bring with them and afterwards based on that we define we want we are aiming to propose architectural changes to make linux more robust and more amenable for use and safety critical application okay and from this the architecture group we formed the automotive work group okay here we have a specific use case I won't have time to go into it but it's a very typical automotive use case where we have tail tails tail tails are basically some kind of indication of malfunction for example in a car okay and the problem with it is we're trusting the the graphics rendering to display something which is really I mean if somebody's brakes are gone and and the graphics um display fails to to indicate that we have a real problem here because the the software underlying software and the hardware can be great and detects the problem that's with the the brakes but if the display somehow messes things up and doesn't actually give that indication to the driver we have a really serious um risk to that driver so the tail tail display is an important safety critical element and that's why it was used as a use case it's a pretty simple use case but it it has very complex implications and the solution is proposed is to have a display and a backup monitor which basically keeps tabs of what's happening if the display succeeded and it has a watchdog running in the background to make sure that that display is updated with the critical information um in in within the time limit which is necessary so that the driver can react okay so this is the type of architecture use case which is being analyzed and the different elements that are involved here for Linux are being analyzed to see where we can introduce enhancements so that the the entire flow can be accepted based on Linux features the watchdog whatever it may be the graphics rendering and accepted for use in safety critical application okay and the final work group are the medical devices okay this I spoke about before there's one area which I didn't mention and that's the the safety analysis based on scpa I won't go into that that's the whole I'm not that familiar with it I'm not we're I'm not involved in this work group but it's it's an interesting theoretical application of a way of analyzing the system and based on the scpa and um defining modeling the the safety of the system it's also being used now for of open source evaluation of open source ventilators and have been speed up the process of approval for those ventilators which are in critical need all over the world now okay and the the first model which they are working on you can see it it's pretty streamlined um um see what it looks like it's a pretty basic type of model of a of a ventilator produced by a team in France the the source code is available the documentation everything is open source they've they've been using scpa to analyze it and to help to speed up the the approval process but the fact that there are people who are well versed in Linux who are involved is also helpful to bridge that gap and to to accept the the different components that are involved here and choose to smooth the the analysis process okay um okay I'm not going to really have time I I um I think my time is is up in a few minutes so I'll just very quickly say we have very very um high hopes um to provide tangible deliverables and there are things specific things which are we are working on right now as I mentioned before a little bit I where I went into details and um obviously we do want more contributors people who who who believe in this who believe in in in the power which Linux can bring to safety critical applications who want to contribute especially on the technical side we're all for it I think there's a strong market need and different business entities who do want to take advantage and who can contribute their small share but that if we have a community we all together can make the assessment process and the acceptance of such applications so much easier and that's what we're aiming for okay um we have here a couple of slides which I won't have time to go into you can go look at them afterwards on your own time about different focuses anyone who can contribute it in any of these specific areas um and these are the the members okay I work for a company which is part of Intel and but we have representatives from all kinds of both automotive manufacturers as I said before that's currently a major focus because that's where our members are coming from but if there are people who can come to um from other areas as well we're all open for that and um we need that kind of synergy to to move ahead okay and the slides have links um to the different lives of materials and I will add my um contact information on the last slide here and um I guess Melia I'll send to whoever from the Linux Foundation or whoever it will be you can update the slide they'll send a slightly updated version of these slides also with correcting some titles and the contact information for all okay um questions let me see if there's anything uh they don't advertise them so so okay so I will add that to the slide that's fine and um there was a question here about common criteria certification in tips 140 to um to date we haven't worked with those standards I'm not so familiar with them because I come from the automotive domain and what we've been doing but again the the standards which feed our process are based on the use cases so that if we are coming from the automotive domain we're driven by ISO 26262 and if we're coming from other domains then that's what will drive the assessment process and as I said before we have a more generic reference process with which we work and because our certain basics for safe software which are common to all standards and then we have the second stage of taking that reference process and mapping it on to the details of any specific safety standard okay so if people are interested in getting involved in new areas the new use cases that's more than welcome I think there's a lot of the foundation will be in common but obviously we do need that specific work to translate it into the specific use cases for each specific domain okay so I hope I answered um that question um one more question was about sanitizers on the target I don't have too much time to answer that but if I understand that's dealing with your referring to static analysis I think um and here if you want to follow up afterwards you can contact me I can tell you more about how the work is ongoing what we have done what we will be doing but there's a lot of interesting work to um there okay um so I think I guess we're done and now yeah yeah you can share my contact information okay thanks but I'll share it as well thank you