October 23, 2017 – The Civil Infrastructure Platform (CIP), which aims to provide a base layer of industrial grade open source software components, tools and methods to enable long-term management of critical systems, today announced the release of the CIP Core. The CIP Core, a ​reference ​minimal file system ​that offers a customizable environment that developers can use to test the CIP kernel and core packages, was on display at Embedded Linux Conference Europe with planned workshops, demos and Q&A sessions.

CIP aims to speed implementation of Linux-based civil infrastructure systems, build upon existing open source foundations and expertise, establish de facto standards by providing a base layer reference implementation, and contribute to and influence upstream projects regarding industrial needs.

Hosted by The Linux Foundation, CIP addresses the needs of long-term software for the power generation and distribution, water, oil and gas, transportation and building automation industries. CIP members such as Codethink, Hitachi, Plat’Home, Renesas, Siemens and Toshiba are working to create a reliable and secure Linux-based embedded software platform that can be sustained more than 10 years and up to 60 years.

“CIP is committed to creating, testing and maintaining an open source software foundation needed to deliver essential services for civil infrastructure and economic development on a global scale,” said Yoshitake Kobayashi, Chair of CIP’s Technical Steering Committee and the Senior Manager of Open Source Technology Department at Toshiba. “The CIP Core is a major milestone that will provide a platform for developers to easily build a reference file system and quickly test the CIP kernel with specific application and use cases. This customizable testing will eventually became a part of the product solution.”

CIP Core features include: - Creating reference file system images to test and demonstrate use of the CIP kernel and core packages, a selected set of open source software components that require super long-term support. - Achieving its first milestone after releasing reference file system images for the Beaglebone Black, the iWave RZ/G1M Qseven Development Kit, QEMU x86_64 and the DE0-Nano-SoC development kit. - Consolidating the CIP kernel and core packages into a minimal reference file system that can be tested and used for further development. - Leveraging released file system images that were generated with Deby, a reproducible and maintainable embedded Linux distribution currently based on poky and Debian LTS source code.

Board at Desk v1.0: CIP also recently launched Board AT Desk (B@D) v1.0, a customized and easy to deploy instance of the kernelci and LAVA projects that should allow developers to test Linux kernels on boards connected to their own development machines using the tooling provided by one of the most successful Open Source testing projects, kernelci.org. B@D v1.0 is provided as a vagrant virtual machine (VM) image/recipe and as a VM image, known as a Vagrant box.

With this release, CIP is moving towards a “shared and trusted testing” target for not just those directly involved in maintaining the CIP kernel but any kernel developer that has physical access to a board. It reduces the deployment, configuration and maintenance costs. B@D introduces a “local” approach to kernelci.org which is a distributed service centrally managed. In addition, CIP intends to increase the number of developers and organizations willing to participate in kernelci.org by providing a simple mechanism to evaluate the technologies developed by that community (LAVA and kernelci) which CIP considers upstream. For more information about the B@D v1.0, read this blog post https://www.cip-project.org/blog/2017/10/18/cip-launches-bd-v1-0.

When does CIP define/label a kernel as SLTS (Super Long Term Support)?

New major versions of commercial Linux distributions are released at 3-4 year intervals, so that typically only 4 versions need to be supported at one time. Given that CIP's support period is meant to be even longer, it won’t be sustainable to extend every LTS branch, but only to take on a new branch every 2-4 years.

The longer the intervals between new SLTS branches, the greater need there will be for CIP or individual members to backport new hardware support (which carries its own risks). This trade-off is perhaps the most difficult issue to decide.

CIP will measure the effort involved in maintaining the kernel branch we already labelled as SLTS (4.4) and study the technical implications of this work during 2017 in order to define when the next SLTS branch should be started.

How long will 4.4 SLTS branch be maintained?

The use cases CIP project is targeting have a life cycle of between 25 and 50 years. In theory, this is the time in which products shipped with the CIP kernel will be under maintenance. However, identifying and backporting relevant fixes becomes increasingly difficult as upstream kernel development diverges further from a stable branch. Any given SLTS branch is unlikely to be maintainable for more than 10-20 years.

The Linux kernel 4.4 was released on January 10th 2016. It was declared LTS (Long Term Support) by the stable team which means Greg Kroah-Hartman will maintain it for two years (Feb 2018) following the kernel LTS process. Another stable maintainer could extend LTS maintenance for some time beyond that. After that period, CIP will maintain it.

The policy for which changes to accept is based on stable-kernel-rules.rst. For reference, these are the rules with numbering added:

1. It must be obviously correct and tested.
2. It cannot be bigger than 100 lines, with context.
3. It must fix only one thing.
4. It must fix a real bug that bothers people (not a, “This could be a problem…” type thing).
5. It must fix a problem that causes a build error (but not for things marked CONFIG_BROKEN), an oops, a hang, data corruption, a real security issue, or some “oh, that's not good” issue. In short, something critical.
6. Serious issues as reported by a user of a distribution kernel may also be considered if they fix a notable performance or interactivity issue. As these fixes are not as obvious and have a higher risk of a subtle regression they should only be submitted by a distribution kernel maintainer and include an addendum linking to a bugzilla entry if it exists and additional information on the user-visible impact.
7. New device IDs and quirks are also accepted.
8. No “theoretical race condition” issues, unless an explanation of how the race can be exploited is also provided.
9. It cannot contain any “trivial” fixes in it (spelling changes, whitespace cleanups, etc).
10. It must follow the Documentation/SubmittingPatches rules.
11. It or an equivalent fix must already exist in Linus' tree (upstream).

In practice, exceptions are sometimes made to rules 2, 3, 8 and 9, and we will likewise treat those as should rather than must rules.

After the end of LTS at kernel.org, the fixes made to a SLTS branch will be more restricted:

• Architecture and hardware support will be limited to the needs of CIP members; fixes for other hardware will not be applied except where that makes it easier to apply the fixes we do need. For the 4.4 branch, the architectures we've committed to so far are arm (32-bit) and x86_64.
• Some features, particularly those labelled as experimental, may also be excluded from support. We have not done so yet.

Unlike an LTS branch, an SLTS branch may include larger changes to support new hardware, to bridge the gap between SLTS branches. However, this should only be done on the newest SLTS branch.

CIP will release sources, not binaries, except for the CIP platforms once we start to build a more complete platform. The SLTS kernel maintainer will push a signed tag to the kernel git repository for each release.

Once we have automated testing in place, a release candidate must be tested on all the platforms that are covered, with no regressions, before it is tagged as a release.

As we will be backporting fixes from mainline, which may change in-kernel APIs, we will not guarantee API or ABI stability within an SLTS branch. It is the responsibility of members to update any out-of-tree components they use in case they are affected by such a change. However, incompatible changes to user-space APIs or ABIs will not be acceptable.

CIP maintainers will support and respond to bug reports from CIP members and their developers, but not system administrators or end users.

The embedded systems that CIP will be used in will also often require out-of-tree drivers and will sometimes include other changes of unknown quality to their kernel. These modifications are in general unsupported. If a bug is found in such a modified kernel, Members will first demonstrate that it exists in the CIP source release in order for the CIP maintainers to act on it.

CIP works towards reducing the window of vulnerability to zero. To achieve this goal, CIP will collaborate with the wider kernel community in initiatives like the Kernel Self Protection Project.

Although this goal may be achievable for CIP, its members may take much longer to release and deploy binary updates, maybe due to valid concerns about the risk of regression or limited opportunities to deploy updates. In the worst case, they may use CIP as an advertising/compliance point - please don't do that!

We plan to track CVE status in each branch and provide this information either to members or publicly.

Back to the parent page