►
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Developing Open Source for Safety and Security - Kate Stewart, Linux Foundation
Open source projects thrive when they can accept great ideas and developers are able to extend the code to “scratch their itch”. Developing safety critical applications, on the other hand, requires rigorous processes to make sure they won’t fail in critical ways and there’s a high threshold before change is accepted. Linux and Zephyr are both working towards achieving Safety Certifications with different approaches. Zephyr is designed for devices where Linux is too big to fit, or have long battery life needs. This talk will summarize the current state of Zephyr and the project’s plans for going after Functional Safety certifications in 2019 while still handling any potential security issues. This will be contrasted with the ELISA project and how the team on ELISA is working towards new processes and tools to help Linux become certified for use in functional safety applications.
https://sched.co/Nrsj
A
Well,
I
think
we
are
going
to
get
started
for
the
last
session
of
the
day,
and
so
thank
you,
everyone
for
sticking
around
to
the
end
here.
What
I'm
going
to
be
talking
about
a
bit
today
is
how
we
need
to
start
working
towards
getting
open
source
being
able
to
used
in
safety
and
security
based
systems,
and
up
till
now
it's
there's
no
really
good
precedence,
and
so
the
question
is
there:
we
want
to
use
the
features,
we
always
have
functionality,
but
we
also
want
to
make
sure
it
stays
safe
and
it's
secure.
A
So
the
big
question
is,
you
know:
can
open
source
be
used
with
safety
standards
and
security
standards?
For
that
matter?
I
suggest
this
live,
but
the
short
answer
is
yes.
However,
there's
a
lot
of
major
transformation
necessary
a
lot
of
forking
it's
expensive
and
the
standards
are
complex
and
have
been
designed
with
a
different
mindset
than
as
usual
in
the
open
source
space,
and
there
are
many
standards,
a
lot
of
which
you
have
to
spend
a
lot
of
money
to
get
copies
of,
which
is
also
antithetical
to
the
open
source
ecosystem.
A
61508
is
a
reasonably
good
generic
starting
point,
but
there's
a
lot
that
can
be
derived
from
it
and
there's
a
lot
of
different
standards
bodies
out
there
to
consult
with
as
well
and
in
the
end
of
the
day
we
want
our
software
to
be
safe
and
secure
and
so
figuring
out
a
pragmatic
path
to
getting.
There
is
pretty
much
what
this
talk's
working
towards.
A
A
Unless
you
know,
we've
got
someone
that
is
responsible
for
the
software
and
because
people
you
don't
want
to
be
a
lot.
You
know
like
it
or
not.
We
have
a
liability
ecosystem
here
and
especially
when
people's
lives
are
at
risk
care.
So
no
one
wants
to
be
first
too.
So
we've
got
this
interesting
challenge
for
open
source
and
we
also
have
to
some
degree
a
software
development
culture
clash
open
source,
pretty
much
thrives
on
you
know,
building
on
others,
work,
fail,
fast,
agile
development
methodologies
and
so
forth.
A
Software
development
for
certification.
It's
more
of
a
formal
discipline,
it
has
requirements
for
building
things,
it
has
formal
verification,
probability
and
so
forth.
So
you've
got
these
two
different
sets
of
engineering
tasks
to
be
worked
towards,
and
so
you
know
why
we
have
this
culture.
Clash
is
not
quite
enough.
It's
you
know
difficult
to
map.
A
Specification
of
features
is
key
here:
comprehension,
documentation,
there's
a
lot
of
documentation,
there's
a
lot
of
evidence
that
has
to
be
pulled
together
and
then
formally
proven
out.
Traceability
from
the
requirements
to
the
source
code
is
key
and
the
number
of
committers
and
who's
committing,
and
how
much
is
known.
These
all
play
a
role
in
the
certifications,
and
this
is
not
all
this
information
that's
gathered
as
part
of
the
open
source
ecosystem.
A
You
know
their
satisfaction
from
the
decomposed
requirements
and
then
the
implementation
links
for
user
stories.
So
there's
a
lot
of
documentation
and
argumentation
that
has
to
go
in
to
actually
go
after
these
safety
stories
and
when
you're
putting
features
in
and
changing
things.
You
know,
I
think
what
was
it.
I
think
the
kernel
changes
nine
times
an
hour
or
something
like
that.
A
The
approach
for
certification
on
open
source
seems
to
be
boiling
down
to
understanding
really
how
it's
used
in
the
system
and
limiting
the
scope
to
what's
actually
needed
for
that
system
and
then
as
much
as
we
possibly
possibly
can
automate.
So
we
can
keep
up
with
the
pace
of
change
and
generate
the
documents
from
the
testing
and
tracking
system
and
then
also
as
you're
going
forward
with
something
formally
make
sure
you
pull
your
certification
authorities
early,
prove
out
the
cons
sketch
out
the
concept
to
them
make
sure
they're
buying
into
it.
A
We
do
have
a
lot
of
strengths
on
terms
of
open
source,
our
code
code's
available
publicly.
It
can
be
scrutinized
by
anyone.
The
code
reviews
and
direct
feedback
are
all
there,
so
the
code
quality
is
high.
The
challenge
is
making
that
discussion
between
what
the
open
source
community
is
doing
and
the
certification
authorities
to
make
them
convinced
and
then
also
to
convince.
You
know
people
themselves
that
yes,
you've
thought
of
the
key
bugs
and
they've
been
removed,
and
so
you
know
have
you
actually
removed
the
key
bugs
is
a
function
of
who's.
A
Reviewing
your
code,
you
know
who
has
a
final
say,
and
how
do
we
guarantee
that
the
reviewer
is
aware
of
safety
implications?
This
is
a
domain
that
we
don't
have
a
lot
of
people
in
open
source
today
and
in
influential
roles
anyhow,
so
we've
got
a
lot
of
bootstrapping
to
do
in
this
area,
and
you
know
how
long
should
you
be
waiting
for
changes
to
be
reviewed
so
open
source
certification?
A
A
A
A
Okay,
and
when
you
talk
about
the
ones
that
are
actually
of
a
public
path
to
try
to
aim
for
that
security
goal
or
the
safety
goal
here.
The
ones
that
most
people
know
about
are
freeart
tosser,
which
has
become
amazon
free
toss.
And
if
you
want
to
go
after
safety,
you
have
to
go
through
a
proprietary
story.
A
A
Now,
when
I
talked
about
lts
and
auditable,
what
I'm
talking
about
here
is
the
development
is
what
we've
been
doing
up
until
april
of
this
year
with
zephyr,
and
we
finally
got
it.
The
interface
is
in
a
good
enough
shape
that
we
basically
cut
our
long-term
support
version
or
lts
version.
This
is
very
much
like
what
the
linux
kernel
is
doing.
We're
trying
to
use
that
some
of
that
models
to
stabilize
it.
A
It
has
to
be
a
foundation
for
everything,
and
that
means
getting
rid
of
the
bugs
and
not
letting
them
come
in
in
the
first
place,
and
so
it
should
be
a
goal
of
any
project.
I
think
the
linux
kernel
has
a
high
quality
standard,
as
does
zephyr
we're
working
towards
it,
and
then
it's
a
question:
how
do
we
improve
it
and
demonstrate
it.
A
The
other
sort
of
strategy
we're
following
with
this
one,
is
building
up
from
the
guidelines
that
are
familiar
to
the
certification
authorities.
We've
got
this
clash
between
cultures
going
on
and
there
are
certain
things
that
they
there
are
certain
things
that
people
agree
on
and
the
certification
authority,
and
that
we
have
ability
to
run
as
automation,
tools,
and
so
miseracy
is
probably
one
of
the
standards
we're
going
to
follow
on
this
project,
and
it
is
challenge
there,
though
specifically
it
is
controversial.
A
It
does
reflect
to
proprietary
standards
and
there
are
proprietary
truly
required.
There's
no
open
source
options
right
now
that
I'm
aware
of
again
input's
welcome
and
our
approaches
to
it
again
from
a
pragmatic
perspective,
are
being
very
public
about
documenting
our
deviations
and
limiting
what
we're
actually,
first
working
towards
to
a
well-defined
scope
and
basically
building
up
for
developer
and
contributor
buy-in
into
this,
as
well
as
having
the
contribution
guidelines
public
so,
but
there
are
things
that
are
going
to
cause
ripples
and
discussions
and
cause
some
problems.
A
So
that's
what
we're
trying
to
work
our
way
towards
so
more
about
zephyr.
I
think
from
the
audience
everyone
here
in
the
audience
knows
zephyrs.
I
won't
go
too
much
into
it
a
hand,
a
hands
up
quickly.
If
anyone
wants
me
to
talk
about
zephyr,
okay,
fine,
so
I'm
just
showing
you
the
code
repositories.
This
is
how
we
structure
it.
A
A
We
have
the
things
that
parts
in
orange
have
been
identified
and
we
have
people
ready
to
work
on
them
for
going
after
this
first
version
and
that's
basically
doing
the
documentation,
requirements,
traceability
and
the
things
that
the
v
model
is
calling
for
and
we're
trying
to
build
this
into
the
code
base
as
much
as
possible.
So
we
can
get
the
regressions
going
there
and,
if
there's
other
and
like
I
say
once,
we
start
with
that,
as
other
people
want
to
add
in
we'll
have
a
framework
and
a
precedence
to
build
from.
A
And
of
course,
zephyr
has
arrived
for
the
use
cases
it's
working
on
today
from
the
single
core
mcu,
all
the
way
to
a
hypervisor
guest
supported
on
opening
mp
and
obviously
the
requirements
of
complexity
grow
with
these
use
cases.
So
this
is
why
it's
important
to
start
with
well-defined
starting
points
and
then
go
from
there.
A
Zephyr
is
one
of
the
few
open
source
projects,
it's
a
cna
right
now,
and
so
we
have
researchers
reaching
out
to
us
with
vulnerabilities
and
we
are
working
in
addressing
them
in
the
security
group
and
reaching
out
the
right
maintainers
to
get
them
addressed
and
then
publicly
disclosing
them
with
our
releases.
So
we
are
taking
it
very
seriously
and
we
are
publicly
documenting
things
by
the
best
practices
badge
we're
one
of
the
few
gold
badges
out
there.
A
A
A
On
the
other
end
of
the
scale,
we
have
this
larger
footprint,
which
is
alisa,
which
stands
for
enabling
linux
and
safety,
critical
applications
and
one
of
the
key
insights
there
is.
You
really
need
to
understand
if
your
system
is
your
system
and
how
linux
is
going
to
be
used
in
the
system,
and
so
you
have
to
understand
the
context
and
use
of
linux,
because
the
same
thing
we'll
be
doing
in
sephora
won't
be
applicable
necessarily
here.
A
A
There's
a
key
there's
a
clear
need:
people
are
caring
about
it.
People
are
wanting
to
try
to
get
together
solve
it.
No
one
has
a
good
idea
how
to
do
it
right
now,
but
the
functionality
and
features
that
are
out
there
right
now
in
open
source
are
too
enticing
for
people
and
it's
too
slow
to
develop
other
ways.
A
So
we're
going
to
be
using
this
basis
about
managing
the
risk
in
the
product
development
cycle
and
making
sure
that
we
understand
more
and
more
about
details
about
the
system
that's
being
used
in
the
kernel
and
how
they
are
interacting
and
then,
quite
frankly,
understanding
the
traceability
understanding.
What
happens
when
you
do
a
security
update,
understand?
Okay,
if
you've
done
your
analysis
and
a
security
update
happens,
do
you
have
to
redo
your
analysis
or
not?
Or
can
it
apply?
These
are
the
sorts
of
questions
we're
going
to
be
tackling.
A
So
I
think
some
more
tooling
is
going
to
be
needed
that
we
have
today
and
that
is
kind
of
how
we're
working
towards
it.
So
we
don't
have
a
solution
today,
but
we
have
a
paths
and
ideas
for
closing
this
goal.
Elisa
got
launched
to
share
the
development
effort
on
this
part
of
the
things
there's
enough
people
that
seem
to
buy
into
the
thinking
that
they
can't
solve
it
on
their
own.
A
They
want
to
get
together
with
other
smart
people
and
try
to
get
these
things
figured
out
and
then,
quite
frankly,
we've
got
the
certification
authorities
on
the
other
side
who
are
sort
of
saying.
Oh,
my
god,
it's
coming
at
us.
How
do
we
do
this?
So
we've
got
people
from
the
certification
authority
side,
as
well
as
the
company
side,
making
products
coming
together
and
starting
to
have
discussions
and
we've
also
started,
have
some
discussions
with
some
of
the
regulatory
authorities
as
well,
because
they
also
see
that
things
need
to
change.
A
They
just
don't
quite
know
how
so
figuring
out
how
we
can
get
linux
and
simple
things
like
zephyr
engaged
is
going
to
be
the
challenge
for
the
next
year
or
two
and
how
we
actually
can
gather
evidence
in
a
standardized
fashion
and
how
we
can
actually
do
the
better
analysis.
We've
got
tracing
tools
in
the
curl
right
now.
How
can
we
actually
make
sure
we
actually
have
a
better
feel
for
which
interfaces
are
being
called
on
a
system?
A
A
So
we
can
make
the
proof
point
to
people
that
it's
there,
it's
possible
it's
doable
and
then
we
also
probably
have
a
lot
of
work
with
working
with
the
integrators,
who
are
actually
making
systems
and
making
sure
they're
doing
the
right
things.
Thinking
about
the
right
questions
as
they
go
forward,
and
you
know
part
of
the
open
source
methodologies
fail
fast,
quickly,
etc.
But
how
does
this
work
with
a
large
long-term
industrial
grade
product
lifetimes
over
20
years,
which
is
where
a
lot
of
these
safety
things
are
running?
A
So
getting
reference
systems
with
reference.
Hardware
is
certainly
one
of
the
goals
we're
trying
to
get
here
and,
as
a
result,
we've
got
a
mission
statement.
This
is
our
mission
statement,
which
is
to
get
these
elements,
processes
and
tools
that
can
be
incorporated
into
making
the
systems
amenable
to
the
safety
certification,
so
try
to
do
the
heavy
lifting
as
a
group
so
that
people
are
just
doing
the
deltas
on
top.
A
The
goals
are
pretty
much
as
I've
talked
about
already
it's
having
those
elements,
it's
having
a
reference
limit
system
and
that
companies
are
feeling
confident
about
incorporating
the
output,
as
well
as
the
open
source
community,
the
safety
community,
the
regulation
authorities,
standards
bodies
and
system
developers
all
accept
the
project.
So
it's
a
bit
of
a
quest
to
change
the
ecosystem
here
and
so
companies
welcome
the
project.
A
Deliverables
are
related,
obviously
to
the
goals,
and
we
would
like
to
obviously
get
the
safety
community
to
actually
start
engaging
with
us
in
the
discussion
and
in
the
definition
so
that
when
they
see
this
stuff
put
in
front
of
them,
they're
in
good
shape,
we've
actually
gotten.
Some
really
good
participation
from
two
suit.
A
So
one
of
the
things
always
that's
important
is
understanding
what
melisa
will
not
be.
We
will
not
make
your
system
safe
where
your
system
is
any
arbitrary
system,
we're
not
going
to
be
ensuring
that
you
know
how
to
apply
the
processes
and
methods.
You've
got
to
educate
yourself
and
engineers,
but
we
will
probably
give
you
paths
and
training
and
we're
not
going
to
create
one
kernel
that
will
rule
them
all.
A
It's
we're
trying
to
figure
out
how
anyone
can
take
a
relevant
upstream
kernel
and
make
the
argumentation
appropriately,
because
one
kernel
to
rule
them
all
has
been
shown
to
be
a
problematic
over
time.
So
it's
better
to
actually
try
to
figure
out
how
we
can
have
the
process.
So
you
can
pull
the
pieces
together
to
prove
something
out
and
we
won't
relieve
you
of
your
liability
because
we
don't
know
what
your
system
is.
A
This
is
an
open
source
project,
that's
been
started
by
a
bunch
of
type
1
diabetes
and
various
technical
friends,
and
everything
on
that
project
is
open
source,
including
the
boards
they're
using
they're,
so
using
raspberry,
pi
they're
using
linux.
On
that
raspberry
pi
they've
documented
source
code.
Everything
is
available
without
an
nda,
and
that
is
key.
A
A
lot
of
the
stuff
that
has
liability
associated
has
ndas
associated
with
it.
So
we
don't
have
a
good
reference
systems
to
work
with
until
now,
but
this
one
is
all
there,
it's
public
and
it's
an
interesting
problem
to
solve
basically
you're
putting
the
human
today.
If
someone
has
type
1
diabetes,
they
use
a
glucose,
monitor
to
monitor
their
glucose
levels
and
then
potentially
have
an
insulin
pump
to
keep
their
insulin
levels
coherent,
and
they
have
to
do
everything
manually
and
there's,
alarms
and
there's
alarm
fatigue
from
dealing
with
these
alarms.
A
And
so
the
idea
that
came
up
a
couple
years
ago
was
basically
oh
hey.
We
can
monitor
it,
we
can
adjust
it
and
then
we
can,
you
know,
feed
the
data
in
and
they
were
able
to
do
it
because
there
was,
quite
frankly,
a
bug
in
one
of
the
devices
in
the
glucose
monitor
and
that
was
able
to
broadcast
the
information,
so
they
could
consume
it
and
then
use
it
for
the
analysis.
A
A
A
A
A
Part
of
that's
going
to
be
in
some
cases
working
within
a
well-defined
scope
and
focus
on
the
interfaces
that
matter
to
the
system
and
then
understand.
Realistically
what
system
you
know
you
want
to
be
using
and
get
buy-in
from
people
early
that
the
approach
you're
taking
is
going
to
be
paid
worth
the
time
at
the
end
of
the
day,
and
the
certification
authorities
are
usually
quite
willing
to
work
with
people
on
that
type
of
model
of
understanding.
A
Okay,
in
fact,
they
tend
to
be
very
happy
if
you're
coming
to
them
and
say
this
is
what
I
do.
Here's
what
it
is.
Is
this
approach
reasonable,
because
they'd
rather
course
correct
you
earlier
than
later,
and
so
hopefully
they'll
be
by
just
participating
in
this
group
they'll
be
helping
the
course
correct
us
as
we're
going
along
on
the
methodologies
as
well,
and
with
that
I
just
have
questions.
If
anyone
has
any
questions
about
this,
go
for
it.
Andy.
A
But
that's
not
an
initial
first
goal,
because
we
don't
know,
we
don't
know
as
a
group
right
now
in
some
ways
and
they've
got
the
full.
I
like
say
there's
a
lot
of
you
know
a
lot
of
entrenched
interests
in
this
space,
and
so
the
open
source
side
is
coming
into
this
from
a
new
perspective,
and
so
the
data
should
get
interesting
from
that
side.
C
C
It's
not
really
a
community
open
source
project
in
the
way
that
the
linux
kernel
is,
and
these
people
clearly
want
to
put
it
in
a
product,
and
so
the
fact
that
there
is
these
barriers
to
getting
that
certified
for
them
to
put
it
in
a
product
that
is
safety
and
security.
Critical
I
was
sort
of
like,
but
then
things
like
the
insulin
pump
example,
then
that
yeah
that
changed
my
mind.
So
I
know
I'm
going
to
ask
the
question,
but
I
thought
it
was
interesting
topic
to
bring.
A
C
A
A
And
so
basically,
the
project
made
it
available
to
the
members
to
go
and
have
the
developers
there.
So,
all
of
a
sudden,
it
wasn't
just
one
person
who
understands
safety.
There
was
a
couple
handfuls
to
reinforce,
like
you
know,
there's
about
10
people
there
to
be
able
to
reinforce
each
other
and
as
you're,
trying
to
build
a
community
and
shape
the
direction
having
that
sort
of
mutual
reinforcement
is
going
to
be
key
for
actually
making
it
happen.