Getting (more) Debian into our civil infrastructure

Talk given by Jan Kiszka at Minidebconf Hamburg 2018
https://meetings-archive.debian.net/pub/debian-meetings/2018/miniconf-hamburg/2018-05-20/civil_infrastructure.webm

Welcome back, the next talk will be
Jan Kiszka

on Getting more Debian into our
civil infrastructure.

Thank you Michael.

So my name is Jan Kiszka,

you may not know me, I'm not a Debian
Developer, not a Debian Maintainer.

I'm just an upstream hacker.

I'm working for Siemens

and part of the Linux team there
for now 10 years actually,

more than 10 years.

We are supporting our business units
in getting Linux into the products successfully

for that long time, even longer actually.

Today, I'm representing a collaborative
project that has some relationship

with Debian, and more soon.

First of all, maybe a surprise to some
of you,

our civilization is heavily running on Linux
and you may now think about

this kind of devices where some kind of
Linux inside,

or you may think of the cloud servers
running Linux inside.

But actually, this is about devices closer
to us.

In all our infrastructure,

there are control systems, there are
management systems included

and many many of them run Linux inside.

Maybe if you are traveling with Deutsche
Bahn to this event these days,

there was some Linux system on the train
as well,

as they were on the ???,
so on the control side.

Energy generation.

Power plants, they are also run with Linux

in very interesting ways, in positive ways

Industry automation, the factories, they
have control systems inside

and quite a few are running Linux inside.

And also other systems like health care,
diagnostic systems.

These big balls up there, they're magnetic
resonance imaging systems,

they're running on Linux for over
a decade now.

Building automation, not at home but in
the professional building area.

Actually, as I said, the train systems are
going to be more on Debian soon.

We have Debian for quite a while in
power generation.

"We", in this case, Siemens.

We have the box underneath,
on the third row,

the industrial switch there is running
Debian.

And the health care device is still
on Ubuntu, but soon will be Debian as well.

Just to give some examples.

These are the areas where we, as a group,
and we, as Siemens, are active.

But there are some problems with this.

Just take an example from a railway
system.

Usually, this kind of devices installation,
they have a lifetime

of 25, 30 years.

It used to be quite simple with these
old devices,

simple in the sense that it was mechanic,
it was pretty robust

I was once told that one of these locking
systems,

they were basically left in a box out there
for 50 years and no one entered the ???

No one touched the whole thing for 50 years

These times are a little bit over.

Nowadays, we have more electronic systems
in these systems

and they contain of course software.

What does it mean?

Just to give you an idea, how this kind
of development looks like in this domain.

So ???

development takes quite a long time
until the product is ready,

3 to 5 years.

Then, in the railway domain, it's mostly
about customizing the systems

for specific installations of the railway
systems,

not only in Europe, they are kind of messy
regarding the differences.

So you have specific requirements of the
customer, the railway operators

to adjust these systems for their needs.

And you see by then,

after 5 years already, a Debian version
would be out of maintenance and

if you add an other year, you can start
over again.

So, in the development time, you may
change still the system

but later on, it's getting hard to change
the system ???

because then the interesting parts start
in this domain, not only in this domain,

that's safety and security assessment and
approval for these systems.

And that also takes time.

For example, in Germany, you go for the
Eisenbahn ???

and you ask to get a permission to run
that train on the track

and if they say "Mmh, not happy with it",
you do it over again

and it takes time

and if you change something in the
system, it becomes interesting

because some of these certification
aspects become invalid,

you have to redo it.

And then of course, these trains on
the installation,

the have a long life as I mentioned
before.

So how do you deal with this in
an electronic device and

in software-driven devices over
this long phase?

That's our challenge

and just one example and there are
more in this area.

At the same time, what we see now is
these fancy buzzwords

from cloud business entering
our conservative, slowly moving domain.

We talk about IoT, industrial IoT, so
connected devices.

We talk about edge computing, it means
getting the power of the cloud

to the device in the field, closer to
where the real things happen.

So, networking becomes a topic.

In the past, you basically built a system,
you locked it up physically

you never touched it again, except
the customer complains that

there were some bug inside.

These days, the customer asks us to
do a frequent update.

And actually the customers ???
ask for this.

So you have to have some security
maintenance concept in this

which means regular updates, regular fixes

and that is of course ???
for this kind of doing the way you have

slow running and long running
support cycles.

To summarize, there's a very long time
we have to maintain our devices in the field

and so far, this was mostly done
individually.

So each company, and sometimes quite
frequently also inside the company,

each product group, development ???
did it individually.

So everyone was having their own kernel,
everyone was having their own base system,

it was easy to build up so it should be
easy to maintain.

Of course it's not.

This was one thing, one important thing.

And then, of course, we not always are
completely happy

with what the free software gives us.

There are some needs to make things
more robust,

to make things more secure, reliable.

So we have to work with these components
and improve them, mostly upstream,

and that, of course, is not a challenge
we have to address in this area.

And catch up with a trend coming in from
the service space on the cloud space.

So with this challenge…

it was the point where we, in this case,
a number of big users of

industrial open source systems,

came together and created a new
collaborative project.

That's what you do in the open source
area.

This project is called Civil Infrastructure
Platform.

It's under the umbrella of the Linux
Foundation,

there are many projects of the Linux
Foundation you may have seen,

but most of them are more in the area
of cloud computing

or in the area of media.

Automotive computing, this one is actually
even more conservative than the other ones

and it's also comparably small.

Our goal is to build this open source
base layer for these application scenarios

based on free software, based on Linux.

We started two years ago.

That's basically our structure, to give
you an idea.

Member companies, the 3 on the top are
founding platinum companies,

Hitachi, Toshiba and Siemens.

We have Codethink and Plat'Home
on board,

we had them on board for the first time
as well.

Renesas joined us and just recently also
Moxa.

So if you compare this with other
collaborative projects,

it's a pretty small one, comparatively
small one,

so our budget is also limited.

It's still decent enough, but, well,
we are growing.

And based on this budget, we have
some developers being paid,

Ben is paid this way, you will see
later on why.

And we have people working from
the companies in the communities

and we are ramping up on working with
communities

to improve the base layers for our needs.

Everything is open source, we have
a GitLab repo as well and

you can look up there what's going on there.

So, the main areas of activities where
we are working on right now.

4 areas.

Kernel maintenance,

we started with declaring one kernel as
the CIP kernel to have

an extended support phase for this kernel
of 10 years.

This is what we're aiming for, which is
feasible already

for some enterprise distros
in a specific area

but here we are talking about an industrial
area, an embedded area

so there is some challenge.

I'm saying 10 years, there's sometimes
written 15 years,

we will see after 10 years if we follow
on to this.

Along with this, of course, comes the need
for real time support.

Currently, it's a separated branch, but
it's going to be integrated eventually

to have the PREEMPT_RT branch
??? doing this.

As I mentioned before, Ben is currently
our 4.4 CIP kernel maintainer.

This is the core, basically where we
started activities.

We continued in extending this on
test infrastructure,

so we invested a bit in improving on
??? infrastructure,

we are now ramping up an internal
??? just to enable

the kernel testing of course.

And then, that's actually what I'd like
to talk about today a bit more,

there's a CIP core.

The kernel alone doesn't make a system,
you need a user space,

you need a user land and that's basically
where we are now focusing on,

ramping up.

Our activity is to define this CIP core,
means a base system,

user space base system which you want
to maintain as long as the kernel,

so an other 10 years thing.

Our group had a couple of members which
were already familiar with Debian before.

So it was pretty easy for that group
to decide on

choosing Debian as the base source
for our core, CIP core package.

So, why was Debian chosen?

Well, it has an outstanding maturity and
a focus on stability,

so we are pretty much aligned regarding
how conservative we see certain things

which is a positive thing for us.

It has very professional security properties
but we also rely on heavily.

And also another interesting aspect for us
is the license hygiene that you are after

to ensure that there is only free software
in these packages

and that is properly documented.

We, when we are using and redistributing
software,

in contrast to, for example, the service space

when you don't usually redistribute things,

we are redistributing devices, so we are
redistributing software,

we have to take care of the licenses
that we are redistributing

and that we are compliant with all these
licenses included.

So it's very important for us that this is
a consistent picture we get from the package.

Someone looked at this already, we are still
looking ourselves on this

but that's a very important thing.

With these characters, we chose Debian
as the base system.

So, what does it mean right now?

We are currently in the process to select
the core packages from the Debian packages

There is still a little bit of ???
obviously.

So we are already working with Debian on
certain long term support aspects

Just to mention 2 activities,

we were sponsoring already the staging
repo for security master.

Actually I'm ??? aware of the current
state of the project

but we got the feedback that it's
apparently a valuable thing for LTS activity

We just joined LTS platinum sponsoring
and we are now involved in discussion

for this extended LTS activity,

so anything beyond 5 years

and in the end, that's what we committed
to our users.

We want to ensure that for the base system
the 10 years is reached.

Of course, ideally, in the community,
not only based on our personal activities

but in the end, we have to fill the gap

and that's basically our commitment
on this.

Don't take literally what is written here.

This is basically to reflect the package set
we are discussing

and there are some 30 to 300 packages
on the discussion, so to say right now

We're condensing basically all the input
from our users, from our members,

what they are using already

and there is a difference we will later
on where this comes from

in the amount of packages, if the way
they're using.

So, the kernel currently is not part of
the Debian thing we import,

although some of our users would directly
use a Debian kernel

but as I said, when there's a need for
additional activities and

that's why CIP Core comes in

but then we have a set of base packages

and then of course, we also have to have
a certain set of packages that we need to keep

in a usable way to ensure reproducibility
of this base set.

Because if we want to fix something
after 9 years in the field

on a base system produced in the past,

we have to ensure if we can come up
with the same result

plus the delta.

So there are different ways how to build
a system

and compared to the classic installation

you may know from a desktop or a server
you're not installing,

we are prebuilding images and then deploy
these images on the devices

either in the factory or out there
in the field.

So the challenge for us is, if we have
this package list,

how to get to the device image.

So just to give you a brief idea, of course
there is some input

from the CIP kernel in source form

then we are using ???
prebuilt binary packages from Debian

and/or source package, the source feed
from Debian,

the upstream source but the Debian patches
as input feeds

and that comes bound to a minimum
base system to be generated

and we are currently working on this.

There is no defined way of producing
this image within CIP at this point,

we are basically following two paths.

One of them is the path which is dominated
by the idea

"Ok, we have to ensure we, in this case
the ??? environments

have to ensure to reproduce the image
ourself, the binaries ourself"

so we take the maintain sources from
the Debian community

but we rebuilt and then generate a new
binary ??? out of this.

That's one way and that's an activity
which you have heard about,

meta-debian project prominently driven
by Toshiba,

which uses the ???
way of producing a base system

but out of Debian sources so that you have
a maintained source input feed

for this production.

That's one path.

The other path is using predominantly
binary packages

and personally and specific also at Siemens
we are more following this path here.

So there is for example the ISAR project,

??? is one of their developers here
as well

We are working on this path, it means that
95 or 99% of your image consists originally

of binaries, Debian binaries as they are
shipped, as they are released

and then there is often the need to modify
a little bit,

it might be the kernel, it might be
the bootloader,

it might be a special patched package
for whatever reason,

hopefully good ones.

You have an infrastructure to assemble
the binary images and

to produce the source packages
on demand

and install that into an image that you
then can flash on the device.

That's the second path we are following,
as I said,

that's just to describe the workflows,
the technology behind it is

not yet standardized in the CIP.

For us at Siemens, currently,
???

it's also ??? based

yocto-like production,

but based on the Debian binaries
producing a ready-to-install device image.

We look at the situation.

So what is Debian providing?

Well, a large set of packages, a nice
level of support, 3 + 2 years LTS mostly.

That's already great, I mean there's
everything available,

almost everything in the world of
Free Software, we can get via Debian.

The build, it supports native build.

That's also an advantage, because finding
after 10 years, 15 years with cross build…

There's always a problem with
cross building, even a little bit.

So this is a good strategy to go, although
you're also working on cross build

that may be interesting for certain
scenarios as well for us

and we're all discussing this these days,

reproducible builds is also very important
for us

because we also have to prove that
the delta is really only on the delta

that has to be changed and not anything
else and

we have to rebuild something for
whatever reason,

we don't want to produce a completely
different image in the end.

So it's a very important topic.

I mentioned already before the license
compliance topics.

I'm not really deep expert on all the
licensing thing,

except when I have to be because some
customer asks us internally

how to be compliant and how to solve
certain compliance findings.

A colleague of mine, ??? example
who's maintaining the fossology project

is way more in this because we have also
our infrastructure

to ensure license compliance and identify
packages, ???

and the idea, as far as I heard, is to
combine these kinds of activity

so that Debian can also use the information
that this kind of scanners produce

like spdx formats and build it into
the Debian 5 next generations.

In turn, we can extract this information
and ensure that they are still valid

when we take a package.

So there's a lot of activity already
in this area

and of course testing, not to mention.

So, what we need to require here,
as I said.

One thing is we will need a longer support
phase.

The number of packages fortunately is
much lower.

As I said, something like 200 at most is
what we're currently heading for

for most of our devices.

We have the need to both build natively and
cross build predominantly

in the development phase,

but there might also cases where it might
be useful for a product image

but predominantly it's for development
phase, you want to

??? when you are building on on x64 ARM
for example.

The binary source packages should be
managed and reproducible.

The license compliance already
mentioned.

And the testing activity is also something
that we want to improve on further.