Jonni Bid­well

Jonni Bid­well al­ways sus­pected Linux would save the world. In­dus­try ex­perts Yoshi­take Kobayashi and Urs Gleim all but con­firmed his hunch…

Linux Format - - Contents -

The Civil In­fra­struc­ture Plat­form (CIP) is a Linux Foun­da­tion ini­tia­tive. It aims to es­tab­lish a base layer of in­dus­trial-grade soft­ware to power crit­i­cal ser­vices such as en­ergy, wa­ter, trans­porta­tion and com­mu­ni­ca­tions – the lifeblood of to­day’s civil­i­sa­tion.

Many of these projects run on open source soft­ware, and many more will do so in the fu­ture. Yet it’s com­pletely un­fea­si­ble to update the soft­ware run­ning these things ev­ery five years (the cur­rent life­span of LTS distros), and many of these sys­tems are look­ing at life-spans be­yond 50 years. So the CIP in­tro­duces the idea of a su­per long-term sup­port (SLTS) ker­nel.

Lin­uxFor­mat’s Jonni Bid­well caught up with Toshiba’s Yoshi Kobayashi and Urs Gleim, head of the Cen­tral Smart Em­bed­ded Sys­tems Group at Siemens AG at the Linux Foun­da­tion’s Open Source Sum­mit in Prague in Oc­to­ber 2017. There, he got the low­down on how the CIP hopes to keep its ker­nel and base layer “in­dus­trial-grade”. Since then, there have been a num­ber of key de­vel­op­ments, so we’ve sum­marised those, too.

Linux For­mat: Linux is run­ning in all kinds of places, and lives de­pend on some of those ap­pli­ca­tions. What is the Civil In­fra­struc­ture Plat­form and how is it go­ing to help civil­i­sa­tion go­ing for­ward? Yoshi Kobayashi (YK) and Urs Gleim: (UG): Yes, early on in our pre­sen­ta­tion we have a slide en­ti­tled Our Civ­i­liza­tion is Run by Linux, and it’s not an ex­ag­ger­a­tion. Things like rail­way in­fra­struc­ture, health­care and in­dus­trial au­to­ma­tion, these all have lon­grun­ning sys­tems. We’re talk­ing be­tween 10 and 40 years, maybe even longer.

So we can’t af­ford to change the soft­ware, say, ev­ery two years (as a cau­tious desktop user might). This is es­pe­cially the case where safety cer­ti­fi­ca­tions are in­volved − trans­port net­works and power gen­er­a­tion for ex­am­ple. Here, it can take close to two decades just to put a new sys­tem into ser­vice. So a bet­ter strat­egy is to ap­ply se­cu­rity patches and small up­dates.

For CIP the idea is to stick with one ver­sion of the Linux ker­nel and main­tain it for as long as we can. The CIP ker­nel is much more fo­cused on em­bed­ded de­vices than other long-term ini­tia­tives. So we have sup­port for all the em­bed­ded board ports, but in most cases don’t sup­port desktop PCs or servers. The sys­tems we’re deal­ing with all run on ded­i­cated hard­ware and em­bed­ded chipsets, so that’s what we sup­port.

Many of these kind of sys­tems have al­ready been us­ing Linux for some time, and in­di­vid­ual com­pa­nies have al­ready been work­ing on their own su­per longterm main­te­nance. What we want is ev­ery­one work­ing on the same plat­form, which will avoid some du­pli­ca­tion of ef­fort. But most im­por­tantly, we want this work to be done col­lab­o­ra­tively with the up­stream com­mu­ni­ties, not lo­cally.

LXF: When did the project start and who were the ini­tial in­dus­trial back­ers?

YK: CIP started in April 2016 and the ini­tial sup­port­ers were Hi­tachi, Siemens and Toshiba. Since then, a num­ber of other

part­ners have come on board: Re­ne­sas Elec­tron­ics, Code­think and Plat’Home. They sup­port CIP by contributing di­rectly to up­stream projects and fund­ing work re­lated to the CIP’s goals.

LXF: How do you go about test­ing and cer­ti­fy­ing dif­fer­ent boards? This sounds like an aw­ful lot of work…

YK: These sys­tems run on lots of dif­fer­ent hard­ware plat­forms, so each one needs to be in­di­vid­u­ally tested and cer­ti­fied. But there’s a lot of sim­i­lar­ity across the tests that each board needs to run. So for ex­am­ple, the ker­nel has to be tested on ev­ery board, and there’s a com­mon soft­ware stack that runs these tests. So yes, we have to test all the dif­fer­ent hard­ware, but by shar­ing these com­mon parts, the work­load is re­duced.

UG: Part of the CIP’s role is to pro­duce this test­ing in­fra­struc­ture too, so ev­ery­one is us­ing the same test tools, the same test au­to­ma­tion. It’s im­por­tant to har­monise all these test­ing in­fra­struc­tures, be­cause once that’s in place it’s not that much work to sup­port ad­di­tional ded­i­cated boards. There are a few talks on this, one of the projects is called Board at Desk (B at D − see box, be­low), which en­ables you to eas­ily set up a de­vel­op­ment en­vi­ron­ment on your lo­cal work­sta­tion, which is con­nected via se­rial link to a board. B at D can cur­rently be tested on our ref­er­ence board: the Bea­gle­bone Black and the Re­ne­sas RZ/G1M.

LXF: Se­cu­rity is ob­vi­ously a big is­sue for these kind of sys­tems. How are you go­ing to tackle this?

YK: We’ll port all the se­cu­rity patches from the Linux ker­nel com­mu­nity to our CIP ker­nel and test them on the rel­e­vant hard­ware − hope­fully that’s not too oner­ous.

The other con­cern is user­land, above the ker­nel layer. We have what we call the CIP base layer, which is our com­mon soft­ware stack. We want as much of this stack to be shared across the hard­ware. This would be too much work for just one team, so col­lab­o­ra­tion is im­por­tant here: col­lab­o­ra­tion with both Linux dis­tri­bu­tions and other projects.

UG: The most work in terms of se­cu­rity is done in the server area. Google and other big com­pa­nies are the ma­jor con­trib­u­tors here. There are a few rel­e­vant projects, the Core In­fra­struc­ture Ini­tia­tive (CII, see www.cor­e­in­fras­truc­ture.org) and the Ker­nel Self Pro­tec­tion Project (see https://kernsec.org/wiki/in­dex.php/ Ker­nel_Self_Pro­tec­tion_Pro­ject) for ex­am­ple. We take things from those and back­port them to the CIP ker­nel. The CIP ker­nel is based on Ker­nel 4.4, and we back­port se­cu­rity patches and fea­tures from newer ker­nels to it.

LXF: Re­pro­ducible builds, par­tic­u­larly in De­bian, have been get­ting a lot of at­ten­tion. Might these be used in the CIP? What ex­tra tool­ing and test­ing would be re­quired?

YK: Re­pro­ducible builds is a fu­ture topic for the CIP Project. We haven’t started work on this, yet but plan to soon. Cur­rently, we’re fo­cus­ing on De­bian ac­tiv­i­ties and long-term sup­port. In the next year, you’ll see more col­lab­o­ra­tion and strat­egy with De­bian and plans for both groups: work done in CIP con­text and/or sup­port­ing the De­bian ef­forts on this.

LXF: The re­lease of CIP Core was just an­nounced at this con­fer­ence [in Oc­to­ber 2017]. Is this like a dis­tri­bu­tion for your ker­nel ef­forts?

UG: We’re fo­cused on the ker­nel first. The CIP Core sits on top of that and pro­vides a min­i­mal ref­er­ence filesys­tem. It’s not a proper dis­tri­bu­tion by any stretch of the imag­i­na­tion, mind. We have only the ba­sic pack­ages, a shell, some pro­to­cols (pro­vided by OpenSSL), a boot­loader, glibc, busy­box, binu­tils and com­pil­ers. That’s re­ally it for the mo­ment, so you can see it’s not re­ally com­pa­ra­ble to Ubuntu or some­thing.

The CIP core is the low­est com­mon de­nom­i­na­tor; in­di­vid­ual sys­tems will add what­ever they need. The re­lease is like a first mile­stone to cre­ate our soft­ware stack. This gives us our ker­nel and can­di­dates for user­land pack­ages. It’s based on De­bian source code and bi­na­ries. We de­cided to col­lab­o­rate with the De­bian com­mu­nity be­cause they al­ready pro­vide long-term sup­port.

Note that the com­mu­nity pro­vides sup­port for five years (through the De­bian LTS ef­fort), whereas CIP needs to be sup­ported for at least ten years. We need to work with the com­mu­nity to bridge that sup­port gap. Once we gain ex­pe­ri­ence with this kind of sup­port longevity, fu­ture ker­nels will have even longer sup­port pe­ri­ods. CIP is a plat­inum-level sup­porter of De­bian LTS.

LXF: Other In­ter­net of Things projects have been talk­ing about do­ing up­dates atom­i­cally, rather than per-pack­age. Can you say if this ap­proach be adopted by CIP Core?

YK: At the mo­ment that sort of thing would have to be im­ple­mented on top of the CIP base layer, so we’re not strongly fo­cused on that at the mo­ment. But IoT use cases, and pack­age/firmware up­dates in gen­eral, are im­por­tant, so we may in­tro­duce some­thing like this in fu­ture.

UG: Yes, this will be an op­tion for projects later on. In­ter­nally, in our com­pany for ex­am­ple, we have dif­fer­ent so­lu­tions de­pend­ing on the projects: some based on pack­ages, some based on bi­nary up­dates with bin­diff, and so on.

LXF: There’s men­tion of real-time patches at http://bit.ly/cip-ker­nal-patch­set. Can you elab­o­rate on this? Is there an of­fi­cial real-time CIP ker­nel on the way? UG: Yes, we have a real-time patch at https://git.ker­nel.org/pub/scm/linux/

ker­nel/git/wagi/linux-cip-rt.git. Since the CIP ker­nel is based on Ker­nel 4.4 and there’s a ver­sion of the PREEMPT_RT patches be­ing main­tained for 4.4, main­tain­ing a vari­a­tion of that 4.4 sta­blert patch­set is pos­si­ble with­out too much over­head. The CIP real-time patch­set will be fol­lowed by the 4.4 sta­ble-rt patch­set as closely as pos­si­ble. The sta­ble-rt patch­set won’t gain new fea­tures (such as hrtimer re­work, cpu hot­plug re­work and no_hz fixes) be­cause back­port­ing has a high risk of break­ing sta­ble-rt. There­fore, the sta­ble-rt main­tain­ing goals over­lap with the cip-rt goals, which en­ables us to keep the vari­a­tions of the real-time patch­set smaller.

LXF: So you two are rep­re­sent­ing Toshiba and Siemens, both huge com­pa­nies. Who else is on board here?

UG: We have Hi­tachi, Codet­shink (a Manch­ester-based com­pany that’s very ac­tive in Linux de­vel­op­ment) and Plat’Home (a Ja­panese IoT com­pany). The lat­est mem­ber is Re­ne­sas, which is the first sil­i­con ven­dor to step in and so this is a very im­por­tant step for CIP. When we have sil­i­con ven­dors and their board sup­port pack­agers on board, this re­ally helps the plat­form get yet more dis­tri­bu­tion and sup­port.

LXF: Re­ne­sas is very much in­volved with Au­to­mo­tive Grade Linux (AGL) too. The goal there is to pro­vide a stan­dard Linux base for use in au­to­mo­tive things, mainly in-ve­hi­cle in­fo­tain­ment (IVI) sys­tems at the mo­ment. Is it fair to say the CIP is try­ing to do a sim­i­lar thing, to stan­dard­ise the plat­form for in­fra­struc­ture type things?

YK: In a way that’s right. The main dif­fer­ence is that AGL is try­ing to cre­ate a big soft­ware stack as soon as pos­si­ble and share it. It’s not so much fo­cused on the main­te­nance. We want to start us­ing the CIP plat­form in ac­tual prod­ucts as soon as pos­si­ble, so we need to be fo­cused on reli­a­bil­ity and sta­bil­ity. Su­per long-term sup­port is some­thing com­pletely new, and there’s a lot we need to fig­ure out.

main­tain­ing project mo­men­tum “When we have sil­i­con ven­dors and their board sup­port pack­agers on board, this re­ally helps the plat­form get yet more dis­tri­bu­tion and sup­port”

Yoshi and Urs’s CIP talk at­tracted a crowd, pre­sum­ably due to in­ter­est in pre­serv­ing civil­i­sa­tion.

Yoshi demon­strates a com­pact server full of en­vi­ron­men­tal sen­sors run­ning the CIP ker­nel.

Jonni’s me­dia pass, de­spite get­ting tan­gled up in dread­locks, does grant him a sneak pre­view of the CIP launch.

Urs tack­les the topic of com­pil­ing older code years in the fu­ture, when cer­tifi­cates have ex­pired.

Newspapers in English

Newspapers from Australia

© PressReader. All rights reserved.