 Thank you very much for joining our CIP mini-summit Europe, this is the third mini-summit, we are very pleased to have this mini-summit for this time, oh sorry, yeah maybe I need to mute. The first presentation will be a State of Civil Infrastructure platform by Urs Graem from Siemens and Yosuke Kobayashi from Toshiba. So Urs, please start your presentation. Okay, thank you, Yoshie. Yes, as always we start for the people who are new to this topic with a short introduction, what is a civil infrastructure platform and yeah maybe Yoshie, can you go to the next slide or should I take over sharing? Okay, yeah we have some trends in industry and also in what we call civil infrastructure, which is all the systems keeping our systems for life, our civil systems like power and water and transportation up and running and can you move on? Next slide. So what we see around us is that things get smarter, that means they get processes integrated, but also they get connected and they are connected among each other and connected to the internet and that's not only in these obvious cases like the connected cars, if you look at car sharing offers, it's also in systems which are not so visible, so in the production of factories and also in systems who make our city smart, that means we make the traffic control more intelligent, we have new transportation ideas which are possible with this, energy management is optimized and so forth. Next slide. Yeah and maybe just click through the animation, so this is just a few examples of the systems we don't see every day and they are really running 24-7 the whole year and some of these systems are really at critical places so we need to ensure that they are up and running and yeah because of this special purpose of these systems we have some certain requirements. If we compare this to the home automation and more consumer oriented systems these systems have differences compared to that world. On the next slide we see then that just open the next animation so one more click that things get much more complex in this area, so if you look what we know, so we know our smartphones and we know our home automation things which are basically one-to-one connections of one device to cloud services in the systems we are talking about, we have much more systems interacting, we have higher hierarchies of systems and as I already mentioned these systems have to be robust and up and running all the time and we have other non-functional requirements like real-time requirements for example, we need guaranteed latencies for some tasks, we have guarantees of throughput and responsiveness and so that's why companies like the companies who are running CRP are really interested in focusing on that topics which are not addressed by the typical commodity and consumer technologies at the moment. Let's go to the next slide so there we see that one of these aspects is that these systems live really long so this is maybe an extreme example but a power plant runs for 25 to 60 years and has to be maintained for that time so and a special thing in this platforms is that we cannot update things and always run the latest and greatest software version so because there is certification behind and there's a huge amount of tests and and verifications done to to guarantee the robustness of these systems so that means that people running these systems and now we are coming back to to our basic topic which is Linux as an operating system they cannot update the operating system every every few years so they want to run a certain version as long as possible this means this version has to be maintained for quite a long time maybe not for 25 and not for 60 years but we are definitely not changing the operating systems every two three four years in these kinds of systems. Next slide please. Yes I said everything gets connected this imposes new risks in terms of security so we have to ensure that all our devices are secure and this in most cases means that we have to be able to update things online and so we have to maintain these security holes because these systems are reachable now and we have to be able to do the firmware updates of all these devices and this in older systems was just not a topic because there was no network connection so the only way to access the system was to drive by and to have physical access to the system. Next slide please. Yes and this summary is the special requirements of the products we have in our companies so they are industrial grade this means we have non-functional requirements like reliability, functional safety, real-time capabilities. We have these long-running systems so we need to guarantee the maintenance for the whole lifetime and connected to this we have to ensure that these systems are secure especially if they are placed at critical spots in our infrastructure and next slide please. Now the question is how to solve this and there's another trend going on and even in those companies we are using a lot more commodity software as a couple of years ago and we are focusing basically on the domain-specific applications on top but the software stack underneath gets bigger and bigger and most of it is open source today and as I said at the beginning the many projects do not address these civil infrastructure needs and industrial needs to the extent we needed and that's why we said it makes sense to team up and address several challenges in this area. Next slide so we have more and more devices they are connected we have similar software components and we have these industrial IoT requirements and we started from a world where we really have a lot of different flavors and versions of the operating system out there so every company and it was actually even worse every unit in a company was maintaining their own Linux flavor and this of course increased the maintenance effort a lot and so that's why we said we need a common solution for these base building blocks team up to achieve a better quality a better sustainability and also of course to share the costs of doing this. So the next slide please yeah that's why we said we need a base layer and we started with the operating system and in more detail we started actually with the Linux kernel and on top of this we want to build our own flavors of course there are still flavors for the different domains but the common parts are getting more and more. Next slide so how does this look like so we have a typical Linux distribution of hundreds of packages and we started with the Linux kernel because that's also something we can handle in the setup and we are extending step by step to add some more packages which are kind of the least common denominator of what everybody needs to build a company specific operating system plus extensions. Next slide okay and if we zoom out it looks basically like this so we have the open source world on the left and the company world on the right side so we have CIP as a base have the domain specific and company specific extensions on top and that's what we would call an internal distribution and by doing this we achieve also harmonization inside the companies to build on the same software stack to use the same tools to use the same software testing infrastructure but Yoshi will come to this later okay so looking at the timeline we said we are at the moment targeting the 10 years plus scope so this shows a little bit already how we do this so we are closely aligned to Debian and the Debian long term support what we are adding is the hardware support for the embedded platforms we need to support that's basically decided by the member companies and so we continue to do the security fixes and to a certain extent back ports of new features we'll come to that later. Next slide so for those of you who are not familiar to how open source efforts are organized just a rough overview so we have a bunch of companies on the top so here you see also who is already participating here and these companies provide of course people who are driving this otherwise it's not working and they are also providing a budget and with this budget we can then fund additional people so to ensure really the sustainable of the development team itself but what we also do and Yoshi will talk about the upstream first strategy also we are also pushing activities or funding activities in other open source projects which are part of our software stack at the end so we try to not reinvent the wheel and we try to wherever possible to build on existing open source activities and extend them by the needs of civil infrastructure and products and industry products. Next slide. So from now on I'd like to explain how we are working for ensuring the CIP base layer to establish the sustainable products and this is our scope of activities so each box shows some technical topics and as you can see here there are a lot of topics we need to ensure to make sustainable products and as we have a limited number of companies we decided to define some priorities for each technical topic and our first and most important technical topic was super long-term supported kernels and so because we our first for us is we have to establish a base layer and in the bottom Linux kernel is there that's why we started from the super long-term support kernels then we extend our activities to real-time and CIP core and testing and security and so on so and this is a CIP governance structure we have governing board members to decide some strategies for CIP and under the governing board we have a steering committee so steering technical steering committee decides some technical directions to ensure our CIP base layer so this is why now we have six activities and the first one is a kernel team so SLTS kernel team are ensuring the maintenance for the super long-term supported kernels for 10 years and adding some embedded requirements to support for example some hardware packages and also some functionalities for the security and so on and the next one is real-time real-time is also related to the kernel activities real-time patch is currently not upstreamed so we joined the real-time relaxed project and also work together to ensuring the real-time patch to be upstreamed the third one is CIP core CIP core is focusing on to establish our base layer for the user land and the fourth one is testing so testing is important because without testing no one trusts our base layer is okay or not so we develop a continuously integration testing environment and we also open up the all test results to the public so this activity is also working with the kernel CI as an upstream project and the fifth one is security working group a security working group tried to they're working on the security extensions to meet some industrial technical requirement and currently we are working on the security standard IEC 62443 and this is a one with most important security standard and the last one is software update working group so this working group also working for the connected world now industry devices are connected to provide some features for the infrastructure and if we cannot update the software on the devices that cause a serious effect serious problem for our life so software update is also important for that topic for us and today we have two presentations from a CIP kernel team and testing team and and also the other presentations presented for the CIP security working group activities so our principle is upstream first so we once we decide to start some technical topics we at first we try to find some upstream project and once we have a project we decide to contribute first to the upstream then I use the upstream code inside the CIP project this is how we are ensuring the CIP open source base layer and I'd like to skip some of that right but yeah I really directly mentioned about the CIP kernel team so now CIP have a CIP kernel team to ensure the CIP super long-term stable kernel and our team is quite great performance and and also explains people's joined and working with upstream and also upstream stable kernel team so this is how we work together with upstream project and currently there are four kernels and the details will be presented by Kudosan and for the CIP core is a difference implementation for the base layer and now we have two profiles and tiny profile and generic profile so tiny profile using for the CIP base layer for small IoT devices and generic profile using for the IoT gateways that will have more functionality on it so we collaborated with Debian to ensure the CIP core reference implementations because Debian also have a long-term support project and also extended long-term support project so at the beginning we started to join LTS project and then extended to join to the Debian extended LTS project from this year and currently CIP core also working a lot to enhance our CIP core packages and also functionalities for the generic profile we have is a CIP core and we currently focusing on to create testing environment and we can recently added LTP to the layer that makes more easily to test kernel with LTP and for tiny profile we added new board we actually have some reference board but this new board not only includes reference board but also reference board candidates so we develop lots in this layer and for security we also develop a security layer for either CIP core and during these implementations we find some issues for the rubber and rubber is also a upstream project for our testing activities so we decided to upstream this kind of patches so this is how we are working on the CIP core and CIP testing will be present soon and security working group also present in this mini summit so yeah for software update this code incorporates a common solution for software update into CIP core so that means this software update try to working with CIP core packages to deploy base layer images and also to act safe update and we created some demonstrations recently to show how CIP base layer update more secure and more safe all source code is now available on GitLab so you can find this implementations on the CIP GitLab and also informations available on the CIP website so let me summarize our presentations we provide for the CIP base layer and we are currently working with six working groups and each working group focusing on the our key issues for the security, sustainability and so on so to conclude this presentation our civilizations need open source base layer so CIP will provide this using Linux and if everyone using a Linux CIP is one of the most important candidates to use it on your embedded systems and we make sure to ensure the sustainability by not only using open source code we also providing some contributions to upstream project to realize our open source base layer which means a contribution and collaboration with upstream is key activities for CIP so let me switch to Urs for the rest of presentations. Urs? Sorry, sick mute. Thanks for handing over and yeah we hope you have a good overview what is going on at the moment you see we have a list of respectable hardware and software companies already backing CIP and if you have products that have to be maintained for quite a long which have requirements like real-time requirements or you just need a robust operating system and industrial grade Linux you should have a closer look at CIP and we would be happy of course if other companies are joining this effort so contact us could you switch to the next slide so we have different ways so you can contact us directly it's even better to go via the mailing list the CIP mailing list is mainly the technical mailing list we have a twitter feed we have a website we also have a wiki which summarizes some of the latest informations and of course you it's an open source project you can look at the code so go to GitLab for a CIP project and the kernel actually is hosted on on kernel.org you see the URLs in the slides so thank you yes I don't know how we handle the questions just look maybe you just posted or is it possible to speak up on that platform do we have questions so maybe not if if you have questions and don't want to ask at the moment just contact us and I'll ask later during this event thank you very much thank you so the next speaker is Denish Kumar from Toshiba and Kent Yoshida from UNESCO's Electronics to speak to CIP security to achieving industry-grade security so please start your presentations okay let me share in the screen yeah please so thank you for attending this session I'm Kent Yoshida from UNESCO's Electronics Corporation I'm in charge of first part of this session and Denish from Toshiba Software India will talk at second part of this session we once explained our activities at the last CIP mid-summit at OSS North America and then security working group are continuing activities to achieve industrial-grade security today we will explain an update about the activities we've done over these four months in first session I'd explain about the progress of our assessment to visit the certification body accredited by IC secure certification program in second session Denish will explain about details of our development and testing environment in addition what we are actually doing to meet the requirements to repeat for those who are listening our presentation at the first time security working groups mission is to provide open source base layer needed for developing products compliant with IEC 6443 certification security requirements to achieve an industrial-grade security we focus on IEC 6443 certification as an international standard for industrial automation and control system more product suppliers who develop using relax and package software acting on it will take advantage of our solutions and get IEC 6443 certification to make industry more secure IEC 6443 was born by integrating the standards of measure industries in addition IEC 6443 is a standard series for all control system players for operators building a secure supply chain with reliable equipment it's very important to keep their control system secure system and components that built in your control system need to be implemented with secure development process and of course its security features should be measured by latest cyber security IEC 6443 series is an international standard based on a certification program to ensure that industrial security is constantly updated considered by IEC and ISA as well this is the reason why we focus this certification and standard as you know renax is running on many components for industrial automation and control system field in IEC 6443 requirements for components and their suppliers are defined defined in part 4 it means for the one requirements for development process and for the two requirements for security features of the component products for IECS among them the scope we are trying to cover is embedded devices and network devices since these devices are required to realize specific functions with a small amount amount of resources software optimization is always an important consideration however IEC 6443 part 4 is a product level certification and does not specify platform requirements or commonly used open source roles now we are about half position in our milestone so far we have internally investigated the standards selected about 20 packages that are essential to meet the standard and how much CIP can achieve for the items required as a secure development process and contracted with Exeter which is one of the accredited certification body for ISA secure certification program then proceeded that gap assessment of CIP capabilities against IEC 6443-4-1 and-4-2 this month we completed the gap assessment for development meant process requirements and started the gap assessment for security feature requirements the gap assessment defines how our project should address the challenges that should be addressed to meet requirements before the actual final certification as you can imagine of course it will be difficult for open source of development to meet all of the secure development process requirements for certification this is a general development lifecycle to be considered when we get certified for IEC 6443-4-1 we should define roles and identification of responsibilities for whom relevant with each development phase before starting development need to consider which environment shall be used for development and if that environment ensure protection from tampering or unauthorized use even in the other phases various challenges are required in requirement definition what threats are assumed for the security features in design where is the product places places how does it provide defense in depth and what is best practice for it in implementation all challenges of source code are reviewed by who or analyzed using static analysis tool is it conducted a test to ensure mitigating the specific threats however the facts or penetration test did anyone other than the designer run those tests in addition those measures are improved continuously finally those definitions are documented although open source is designed with sufficient security in mind there are many process challenges that open source project does not address that need to be considered to minimize risk but among them there are some tasks that can be addressed by open source development project the key point is how product suppliers control those tasks and mitigate the risk of the final product for that we should show how far the platform can address those works and what the user must deal with concretely for example by defining a snapshot of stable version package lists and controlling version of it and if we conduct vulnerability and risk assessment of them users will be able to reuse them or easily manage the configuration changes based on them threat modeling depends on use case so it's difficult to define all of them but at least we can create a threat model for general requirements and then users can reuse it as basis by defining the features that the security package considered by CEP security working group the features that must be implement implemented by the user application will be clear by defining the open interfaces implemented in the security packages and the appropriate configuration example it is useful as a generic use case when integration of security packages as a reference design we can apply static analysis to and report its results and its reference design should be tested periodically and we can check its vulnerabilities at cyclic periods users can use the report as the starting point to consider additional tests such as fast or penetration those definitions should be documented so here is the document list that we are preparing to meet IEC 6443-4-1 secure development process before conducting a final certification we need to complete to create documents listed here those documents will be published on the GitLab repository on the CEP project after completion on this activity users can reuse those documents for user certification as well because those documents are required also user certification we believe it may accelerate this certification program in parallel with rule definition and documentation we currently are working on the gap assessment for security functions of essential packages using IEC 6443-4-2 about 20 packages we selected will be affected for many requirements hold the entire requirement of IEC 6443-4-2 the challenges that user applications need to be addressed are clarified by the certification result in addition how to use the package is very important to keep secure the products appropriate configuration of the package should also be defined and documented documented through this certification and of course our certification results and evidences such as an assessment report can also be reused by users this slide shows the flow how security packages are suggested implemented and tested the security packages are considered by the security working group and then the security working group suggests those packages to CEP core team CEP core team familiar with the package software just double check of package selection it's carried out here the software reference design does implemented in combination with the super long-term support corner it's implemented on the CEP reference hardware and validate it on lava lab IEC 6443-4-2 has also security requirements that this hardware must meet in order to comply with security level three the target of the assessment that we are working on now is software and the compliance of those hardware requirements should be handled by each reference hardware provider in this way if the hardware corner and even the core packages that runs in the user space user space confirm to meet security requirements for IEC 6443-4-2 it can be said that it is the best platform for user product development to meet certification so thank you for listening my talk from here Dinesh will report more detailed implementation and testing progress I'll stop sharing a screen and pass to Dinesh Dinesh please share your screen so thank you let me share my screen okay so now onwards I will explain about the status of activities as part of security workgroup we are doing so as explained why can't there are certain requirements from IEC 6443-4-2 which is in terms of technical requirements to add the technical security capabilities in the products so first of all the main requirement which we understood from certification body was to define the security requirements so after having internal discussion we decided that as of now we will take the reference of IEC 6443-4-2 security requirements and on top of that we will define CIP security requirements so recently we have completed defining a draft security requirements for CIP and they have been documented and published and kept in CIP documents public repository and anyone can access the security requirements so as we can see here we have defined the security requirements and each requirement has one ID which will be used for mapping requirements like for each test case or how like which packages used to meet that requirement so for meeting these requirements basically we identified and investigated few devian packages and we have already added those devian packages we will see the detail in further slides so this is the security layer added in CIP core ESA also called generic profile so here as we can see we have added security layer and as part of the security layer there have been there we have added the recipe which includes all the security packages and also in addition to that we have added the security conflicts such as customizing conflicts like password strength or other security measures which can be further modified so this has been already completed and integrated in CIP core user main branch and it's already available in the JIT lab so anyone can have a look on the security packages which have been added as part of CIP security requirements similarly we have added security layer in tiny profile where you can see we have added another meta layer for CIP security which adds all the security packages which we have identified while investigating for us to specification and you can see here in debbie there is a slightly different way of doing the security conflict changes so here you can see for each package there is one folder and inside that folder there is one file which can be used to modify the default configuration so in both profiles tiny and generic profile the addition of security layer is completed as of now and currently as we are also reviewing a four dash two specification with Exida so there are few commands and we may have to slightly make some changes in order to completely meet the requirements based on Exida commands and while adding the security packages as of now we have defined certain default security conflicts like enforcing strong password currently we have taken the difference from NIST how to define the password strength similarly log user accounts after configured of failed login attempts so these default security conflicts can be changed as I already explained in previous slides so let's see next so how the CIP security test images can be created for ESER and debbie profile so this is the way all the source code is already available in jitlab so we already tested security packages and the test cases already verified we'll see the results in further slides this is about CIP debbie where we have also completed adding all the security packages so after adding all the security packages we developed lower test definitions and by automating all the lower test definitions we have verified how our security requirement tests are passing so first we did a local lower setup as part of the setup we have to keep our lower test definitions somewhere in jit server and we are keeping CIP images as of now in AWS so these lava scripts take lower test definitions and CIP images and automate this process of doing the testing and publishing the result and the results can be seen in the UI so even though this image depicts the setup for local setup but we have also completed this activity in CIP lava infrastructure and we faced some difficult issues which took a lot of time while doing the lava multi node test and as part of our investigation we found some issues the patch for those issues already submitted to lava upstream and once it is accepted it will be again available in CIP lava infrastructure so here we can see our test results when we executed our lava test definition on single node test so all the test cases which we have developed to meet IECs afford us to requirements all the test cases are passed and these test results are available as part of lava jobs so anyone can see the test results and the detail of all the logs the test results for lava multi node also available and as you can see each ID like tc underscore cr1.11 so it this ID belongs to one security requirements in IEC 6243.4.2 security requirements so for each security requirement there are either one or more than one test cases to test the security requirement so all the test cases in multi node case also passed and this entire thing is already available as part of CIP lava infrastructure next to meet certain requirements in IEC standards there are requirements like before making product releases critical security fixes should be incorporated and made available to end user receiving notifications for security related issues so these are the requirements from IEC standards and we have to meet these requirements to meet these requirements in CIP core which is user applications recently we have started working on this and we have developed a CIP core SAC as it has set up scripts on top of Tabion's tool for tracking CVEs so this tool will help us to track CVEs and integrate the fixes in CIP core and in the future this entire process will be automated and we can then we can say that we are meeting this requirement by tracking all the CVEs I think in next session you will see how CVEs are being tracked in CIP kernel so I will skip this slide so we can say in both CIP kernel and CIP core now we are tracking CVEs and it has been automated okay so this slide explains about recent activity which we have started doing threat modeling for CIP as a system so there has been very detailed discussion with certification body how should we do threat modeling for CIP since it has many deviant packages and the entire thing is open so how should we identify the points from where threats may emerge so we found the input from certification body that the threat modeling we can be done considering CIP as a system and we can do the analysis of how external entities are interacting with CIP what kind of data flows happening so considering general huge case we recently we had a dedicated session on threat modeling for CIP where we explained about how are we approaching threat modeling for CIP and what kind of activities we are doing so in this slide as you can see this is the summary based on the straight methodology of threat modeling how is spoofing, tempering, repetition for these kind of threats what all packages we have added in CIP so I will not go in much detail as we are running sort of time so these packages have already been added and tested as we have already seen the test results in previous slides so this slide explains like general advantages of using CIP distribution as compared to other distributions there might be a few things also available in other distributions but you can see here a dedicated kernel maintainers for SLTS up to 10 years is available in CIP which is generally not available in other distributions and one of the unique support in CIP which we see IEC assist platform by accredited certification body and as as it was already explained we have recently completed a gap assessment for 4-s1 and shortly we will complete the gap assessment for 4-s2 as well and then we will start working on final assessment for both 4-s1 and 4-s2 we are also closely monitoring CVS at both user level as well as kernel level and regularly integrating all the changes extended support from Davion ELTS for specific packages are based on specific CIP member companies and then regular automated testing on multiple associates with published test results on kernel CI so here anyone can see our test results which are regularly being published and strong support from big players as it was already highlighted in previous slides previous session also okay so from CIP security workgroup perspective what would be the next gap assessment for compliance with 4-s1 and 4-s2 so we are about to complete gap assessment for both and then we will go for actual assessment and all this final CIP assessment documents and test cases or scripts everything will be available to end users and I believe this will be great help and it will greatly reduce the effort for getting end product certified so along with our test cases or test scripts we are also developing some guidelines which will help end product owners to follow those guidelines and easily get their product certified so all these documents will be available in CIP documents repository so usually there are open questions like once the product is certified then how it can be maintained in long term so currently we are discussing with the certification body and we will make sure that our product remains compliant for long time so for that we are collecting inputs and we will be publishing all those inputs which will further help for end customers so that's all about our security workgroup status update I think I will pass the control to Kudosan Kudosan Kudosan we cannot hear your voice thanks very much for joining this session this talk is about CIP kernel team activities I'd like to talk how we are interacting with upstream projects in order to achieve our goals first of all let me introduce myself I'm Masashi Kudo from Cyber Trust Japan I have worked in software industry for both IT and network for more than 30 years and I'm currently acting as CIP kernel team chair upstream first is CIP's development principle I'd like to start my talk with upstream first CIP kernel team follows this principle to work on tasks in the next section I'd like to share what we are doing and what we have accomplished so far then let's get started with upstream first here two development models are pictured the model on the left hand side is own community model the project with this model branches its base from upstream and evolves by its own this model enables the project to ramp up quickly but in the long run it will be difficult to incorporate upstream patches into it due to conflicts the model on the right hand side is upstream first model the project allows patch commits only if those patches are already in the upstream it may take time to introduce a desired patch because the target patch should be accepted by the upstream at first but this model eliminates the risk of conflicts at the same time the project can share its outputs with the upstream please take a look at this graph it displays the growth trend of commit counts for each stable release as you can see a few hundred patches are committed to each stable release per month this trend makes cherry picking quite difficult because CIP is aiming a long-term maintenance upstream first model is a desired approach as explained so far the upstream first principle is essential to achieve industrial requirements especially in terms of long-term maintenance we collaborate with upstream projects before using the outputs we upstream what we have and don't keep them locally by rotating upstreaming and using continuously we are moving toward a goal here explains how CIP artifacts can be used by CIP users CIP refers to source of binary packages in Debian if you'd like to use Debian source packages you can use Yacht4key as a build system CIP core packages contain tens of packages which may not be sufficient for the development of end products so users can add necessary packages from Debian by writing recipes Debian provides LTS maintenance and even extended LTS can be provided so super long-term support including userland packages can take advantage of these maintenance frameworks then let's move on to the CIP kernel team activities primary goal of the CIP kernel team is to provide CIP as LTS kernel for 10 plus years by fixing versions to fulfill the required level of reliability sustainability and security there are two kernel maintenance one kernel mentor and one kernel developer in the team while we are highly motivated to work on the project we don't think we can achieve the goal by ourselves only we definitely rely on upstream project activities the question is how to use the upstream outputs and how to work with upstream projects so what does upstream first mean for the CIP kernel team upstream is linus mainlinus stable releases by upstream first principle only patches which are already in the main line or stable kernels are allowed to be incorporated into CIP kernel releases so CIP members proceed upstream the preferred code and once the code is incorporated into the main line of stable kernels the code is allowed to be backboarded into CIP kernels on the other hand the CIP kernel team takes actions from a different perspective one of the CIP kernel team's objectives is to maintain CIP kernels safe and sound for this objective the team monitors stable releases carefully and contributes to the stable releases where needed in general patches are committed to the main line at first then they are backboarded to each stable kernel however by some reason such backboarding might not be done on some specific specific stable kernels it may be because such patches are irrelevant to them or because backboarding is not trivial for such stable kernels due to the changes of implementations the CIP kernel team reviews those patch status if the team identifies some patches to be backported to some stable kernels the team contributes to them we are concerned about security patches as well we check the status of the security patches by using open source tools and if some patches are missing in stable releases the team contributes to such stable releases as well by incorporating necessary patches the team releases CIP kernels based on upstream artifacts this is the big picture of the kernel team activities and patch review cv check contributions and kernel releases are four major tasks of the CIP kernel team now i'm going to elaborate those four tasks each by each in the following slides the first task is patch review the CIP kernel maintenance review patches which are included in stable release candidates for 4.4 and 4.19 because CIP kernels are based on those releases as a result of the review if the team finds any issues patch review comments are sent to the kernel mailing list directly a black window on the right hand side is an example of such review comments review results are saved in the git lab and if the team identifies some patches should be backported the team initiates the contribution process the second task is cv check for security fixes the team follows a separate process by using cip kernel sec which was developed for this task the cip kernel sec gathers cv information from multiple sources such as stable kernels devian kernel and ubuntu kernel the kernel team focuses on maintaining the cv cv affected in kernel 4.4 and 4.19 and may backport the specific cv comments to the stable kernel where appropriate the cip kernel sec provides simple graphic layouts as well as cli interfaces the users can get detailed information via those interfaces it provides multiple information regarding kernel cv as i mentioned in the previous slide the purpose of the cip kernel sec is to track the status of security issues identified by cv id this tool is public and can be found in the git lab under the cip project you can also reach it on the website via the qr code the third task is contributions there are two for the contributions the first objective is to fill the gaps as a result of patch reviews and cv check we identify missing patches such patches are needed for cip kernels to fulfill industrial grade requirements so the team contributes them to upstream so that cip kernels can be based on the stable kernels which include those patches the second objective is to give back because we take advantage of upstream outputs we are grateful for upstream activities therefore cip kernel team works on contributions of bug fixes and security patches to all stable kernels not limiting to 4.4 or 4.19 these statistics show the counts of the contributions by the cip kernel team to stable releases i reported the statistics at elc north america 2020 in june since then the team keeps contributing to all stable releases as you can see here compared with june time frame the team added nearly 100 contributions in total the last but not the least task is cip kernel release again one of the cip kernel team's objectives is to maintain cip kernels safe and sound through stable patch review the team identifies missing patches and contributes them to stable kernels also cip members want to backboard their preferred patches they send patches to cip dev mailing list for cip kernel maintenance review by incorporating acknowledged patches the testing team starts testing after everything goes well the maintainer in charge tags it as a release candidate another maintainer checks and acknowledges it then the cip kernel is released the announcement of the release is sent out to cip dev mailing list so by subscribing to cip dev you are notified of the cip releases as i mentioned already cip slts kernels are based on 4.4 and 4.19 stable releases the first releases of 4.4 and 4.4 rt were done in 2017 we plan to maintain them to 20 27 for 10 years the first releases of 4.19 and 4.19 rt were done in 2019 and likewise we support them for 10 years until 20 29 currently 4.4 is released once a month 4.4 rt is once every two months because commit counts for 4.4 decreasing 4.19 is twice a month and 4.19 rt is once every two months respectively so far we have steadily released kernels thanks to our maintainers by following release frequencies i just explained i also reported the release statistics at elc north america 2020 compared with those in june the team made 20 additional releases and ea total so far is 46 so the end of this year several releases will be added for sure 4.4 and 4.19 stable releases are active and we are taking advantage of their outputs now we intend to maintain cip slts kernels for 10 years while the lifespan of 4.4 and 4.19 stable kernels are both six years so after they finish those main maintenance the rest of years should be maintained by cip because maintenance of 4.4 stable release will be finished in january 2022 cip will start to maintain cip 4.4 by ourselves the cip kernel team is discussing how to work on this we have been relying on upstream developers and other stable contributors for their outputs now cip cannot rely on this after the end of stable release maintenance so cip kernel maintenance would review each other's work the details are still being discussed and i hope we can share with you the plan at some event next before closing my talk i'd like to show us information sources relating to cip this page talks about our weekly iac meetings it is open to everyone come talk to us on cip channel at the meetings this page talks about repositories on gitlab links to open source tools including cip kernel sec are here the testing teams links are here and other info information is listed here that's all thanks for your time to join this talk are there any questions okay thank you very much for watching my video so if you have questions later on please send us email so let's move on the next speaker is min transom from runesus design vietnam so min san the floor is yours from runesus and now i would like to share my experiences integrating the cv slks kernel into a fully flashed v3 and here is the agenda i will have uh seven sections the first is some introductions about me in my company and the next some background information about our application field our access to the platform why cip is suitable for us and the correlations and next the the main part i will go through seven items of my experiences and then some quick information for next step qna thank you missus and reference link the first one is the introductions um my name is min and i'm a senior staff engineer from runesus design vietnam currently i'm the leader in the asset linux team and we provide a very fine enough package integrating the cv slks kernel into the v3 and i have 10 years experiences in embedded software development mainly linux and last one is my contact email and about the main company uh runesus is renaissance semiconductor for advanced solutions i'll headquartered in tokyo japan and we provide a platform for automotive hmi industrial and ot currently we have more than 18 000 tech house and for the major operation we have the research development design manufacture sales and servicing of some semiconductor products runesus design vietnam red rvc is a french company and we located in hokeyman city vietnam we measure in automotive and hmi with more than 800 employees and we decide for the semiconductor of software and hardware for some background product um today i just want to mention about the application field human machine interface with 3d graphics and video capabilities for some example like the intercoms the digital standard and the kiosk terminals and many more and as you see platform is our target product for above applications the first item i want to mention here is the punty media processor as the platform is a family of 64 bit and 32 bit amp based npu and uh with the specialty in imagination 3d graphics and provided video for testing up to 4k with many other concerns uh necessary for hmi we also have the evaluation kit and the verifying package that i will share more details next slide we also have the development tools and the software it on would add uh more optionals for the customer and make them easy to develop the product for the hmi solutions we provide the leaner package with many components that apply the cmi level three we also have the industry operating leaner we have the ui framework multimeter security wear and many samples and we provide them verified and super long-term support to satisfy this cib is our answer it has the 10 or more year support and so it's suitable for our target development we always enjoy the cib as a member and we provide the we uh propose the reference platform is either fz one for the m7 and as it is to aim for the mv3 and there are also all the reference platforms for all the members and totally seven we call x86 mv7 and mvh architectures next and we go to the main part my experiences the number one we have to start first the ideal development flow is from cb kernel team upstream to the mainline mts and i mean the cb kernel team here either kernel team and also cb member and then cb member who contribute to the upstream and in this upstream work it includes renaissance patches and then this mainline or hds kernel will be used in the cb slks kernel and finally into iterate to the misspeed however this is the only the ideal development flow in reality to satisfy the on-time delivery we have to start first we iterate the cb slts kernel into our resources by ourselves and we have to patch a lot for this work however we gradually get benefit this is the number two experience for the next update and super long-term maintenance we patch last less and less because it now the ideal development flow go into the reality and we have the work reduce for the first release for 15 maintenance for the second just 11 and gradually in the stable phase around seven maintenance even though the other roll number not real but actually at the redo development cost and it's the number three we continuously get the benefit in the past we have whenever we patch the kernel if we want to fix the both we have to stay investigate the reason for the solution now we can directly refer to the mainline and the hds patch to solve our similar issues and not only us for our customer they can have the same benefit and also to support the latest kernel if they want instead of self they can refer to remain like hds kernel and do this quickly so we renaissance and our customers spend less effort to fix much or to support the latest kernel number four experience we got a long-term benefit for the first one we renaissance vcs team have the patch for our kernel and i call the new vpatch also cb kernel team have the patch for the same version of the cb kernel and i call export patch we compare these two kernel and we can learn the difference and improve ourselves we also try the mailing list to join or to monitor or to join the expert discussion about the kernel and essentially if any discussion related directly to renaissance and pu we can get evolve more and get more benefit we also have the chance to join many cb mini submit and other open source concurrent to learn about the expert discussion and also i have a chance to speak here to share my experience and to receive better feedback from you guys so we have a lot of chance for the human development and we can learn and we can work with many experts and it's certainly number five we develop step by step cb slts kernel have two versions the normal and the return and we renaissance one to support botch we don't have we cannot support botch at the same time at the same level so we choose step by step the first is very final version and the next is just a patch for no more and verify for return and next one verify for no more and patch for return and continuously like this so we can stay with the pop botch but step by step from easy to difficult and to stable pace number six with a pop one version at one time for example in 2019 the latest cb slh version for hand for different versions however to choose which version for us basically we decide cb 10 for 4.14 and cb 36 for 4.4 to do to decide like this we have the unified supports the only difference between the normal and the real time basically just the real time fast set and the last one is we release once every three months for the cb slts kernel release 4.19 tricemen and 4.41 cemen for a time 4.19 tricemen and 4.4 once every two months when we release one every three months we always get the update from the latest cb kernel and also we have enough time for one development cycle we have six or six weeks for pop six weeks for verify and two for documentation even though number every row because we don't spend much for kernel it includes a whole development variety but it's either enough time for one cycle and that's under a certain I have to I have time to share now for the next step in the new future we would like to integrate a core package and we also want to expand the mode to and cobaltize the cb core package and in the future we may consider the test formation the security or even more and that's all for my presentation if you have any qa please give me and thank you for your time to attend my presentation and also finally I have some reference plans for you to refer for more details thank you so thank you very much for your presentations and thank you very much for all speakers and for this cip mini summit if you have any further questions and comment we have a mailing list website and also select channel and irc so please feel free to come our information channels and ask any questions the cip so now it's time to close cip mini summit and I would like to say everyone thank you very much and yeah hope to see you next time so thank you very much and bye bye thank you very much bye bye