►
From YouTube: Securing Critical Projects WG (September 24, 2020)
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
E
E
B
We
see
your
image,
but
all
I
get
is
a
blank
screen
with
your
picture
on.
B
D
B
D
B
G
B
C
Sorry
all
right:
well,
we
can
give
dimitri
a
minute
to
try
to
figure
out
just
keep
trying
dimitri,
maybe
we'll
jump
on
to
some
of
these
other
topics
at
the
bottom
of
the
agenda.
C
C
Yes,
where
so
so,
david
david
had
put
together
a
proposal,
that's
linked
in
the
agenda,
and
there
are
a
couple
efforts
that
were
under
the
cii
that
we
could.
We
saw
as
as
this
working
group
being
a
potential
home
for
them
where
this,
where
this
gets
a
little
bit
weird,
and
I
think,
maybe
we're
not
gonna-
be
able
to
sort
of
flesh
this
all
out.
Right
now
is
many
of
these
things
require
funding.
C
Currently,
this
foundation
does
not
have
any
funding
attached
to
it,
and
I
think
the
funding
question
is
going
to
be
something
that
we
have
to
bring
up
in
our
next
board
meeting.
You
know
if
this,
I
might
I
think,
of
this
working
group,
which
is
sort
of
looking
at
the
projects
from
the
project
perspective.
Then
they
all
make
a
lot
of
sense
to
me,
but
I
think,
since
the
funding
is
so
tightly
attached
to
them,
it's
a
little
bit
hard
to
discuss
within
this
group,
but
I'm
happy
david.
B
So
here's
what
I
would
propose
regarding
funding
these
efforts
are
actually
already
funded.
I
think,
through
the
end
of
the
calendar
year,
so
this
working
group
doesn't
have
any
doesn't
have
to
make
any
decisions
unfunded
as
far
as
funding
for
the
moment,
they're,
already,
funded
and
and
so
on.
I
think
the
goal
was
really
to
put
them
in
a
working
group
so
that
they
have
somebody
to
talk
with
report
back
to
get
feedback
from
interact
with
now.
B
The
funding
I
think
the
notion
here
is
that
moving
of
these
things
into
the
working
group
doesn't
require
new
funding
because
they're
currently
funded.
It
also
doesn't
give
them
funding
for
the
following
year,
and
I
think
basically
the
at
least
my
theory
was
that
this
group
would
look
over
these
things,
decide
which
ones
they
want
to
continue
and
how
work
with
these
folks.
My
expectation
is
that
there'll
be
some
suggestions
on
here's,
what
we
think
funding
should
be,
and
then
the
governing
board
actually
and
other
folks
actually
can
make
decisions
about
funding
in
the
future.
B
It
officially
disbanded
there
were
some
activities
that
were
felt
to
be
so
important
that
the
elf
didn't
want
to
disband
them
and
so
kept
going
these
three
this
list
here
being
some
of
those
and
if
the
open
ssf
is
interested
in
bringing
them
in
then
let's
get
those
coordinated
everything
in
one
place
and
then
people
as
a
group
can
have
discussions,
because
I
don't
think
anybody
wants
to
discuss
funding
without
somebody
looking
it
over
and
saying
yeah.
Does
this
make
sense?
B
Does
this
not
make
sense
that
sort
of
thing,
and
I
think
that's
what
the
hope
is
that
this
working
group
could
review
and
at
least
provide
you
know
that
extra
set
of
eyes
on
and
also
frankly,
in
the
case
of
some
of
the
harvard
work,
I
think
there's
hope
that
the
harvard
work
will
result
in
products
that
can
be
used
by
this
group
to
help
identify
the
critical
projects
that
need
resources
of
various
kinds.
H
So
can
I
add
a
bit
please
from
yes
so
from
my
role
in
the
governing
board,
so
we
will
be
two
things.
One
is
that
we
between
lf
and
open
ssf.
We
very
much
want
these.
H
The
openness
assess
project
to
be
successful
and-
and
we
want
to
you-
know-
merge
these
security
related
efforts
so
that
you
know
they're
kind
of
all
working
together
and
we
get
the
benefit
of
you
know
of
people
with
like
minds
and
projects
of
similar
sort
of
scope
and
needs.
Are,
you
know
happening
under
the
same
umbrella?
H
There
are
open
funding
questions.
I
think
that
we'll
be
able
to
work
through
those.
We
will
have
a
discussion
about
funding
at
the
governing
board
meeting,
which
is
next
week,
and
you
know,
will
I
I
recommend
that
this
group
proceed
by
as
david
suggested,
which
is
just
thinking
about
you
know.
Do
we
think
that
these
things
are
aligned
in
charter
and
they
and
they
make
sense
here
and
we'll
go
forward
and
we'll
we'll
figure
out
what
needs
to
be
done
for
funding,
but
between
lf
and
open?
B
Okay,
so
I
put,
I
don't
know
what
the
right
way
to
do.
If
this
is,
I
could
propose
a
vote
or
something
or
you
know
either
within
this
group
or
later,
but
I
think
the
notion
is
you
know
that
this
working
group
decide
do
they
want
to
bring
these
projects
in
and
if
not,
you
know
that's
I
mean
that's
something
this
working
group
also,
but
oh,
hey,
wait
a.
B
Okay,
so
I
mean
I,
I
don't
know
what
the
right
way
to
do
this
is
and
and
such,
but
you
know
I
would
eventually
like
some
I'd
love
to
see
some
closure
on
on
this,
because
we
want
like,
as
just
mentioned,
we
want
like-minded
folks
working
together
instead
of
in
splendid
isolation.
A
So
that'll
make
sense
to
me.
I
think
it
definitely
fits
here.
I
guess
my
only
concern
is
just.
I
don't
know
that
anybody
can
actually
make
promises
that
we're
gonna
find
funding
so
far
like
for
2021.
So
you
know
here
or
the
lf
and
so
it'd
be
a
little
sad
to
you
know,
move
this
over.
Do
all
that
work
and
then
not
be
able
to
continue
the
work
in
three
months
and
have
the
whole
thing
die,
because
we
couldn't
figure
out
the
funding
situation.
B
I
I
I
don't
think
that
I
I
don't
think
those
two
things.
Oh
hello,
can
somebody,
okay.
B
That
was
fun.
Okay,
yeah
I
mean
I,
I
think
that's
true
actually,
no
matter
what,
but
I
I
think
actually.
I
think
I
personally
think
that
moving
into
the
open
ssf
increases
the
likelihood
of
it
being
funded,
because
I
think
one
of
the
issues,
if
I
were
asked
hey,
should
I
fund
it
is
well
who's
kind
of
who's.
Looked
it
over
and
who's.
You
know,
monitoring
it
and
having
a
larger
group
be
able
to
make
commentary
feedback
and
so
on.
B
I
think
increases
the
likelihood
of
that
I
mean
regardless
nobody
can
make
any
guarantees.
I
I
think
there
is
an
interest
very
much
in
continuing
these
efforts,
but
that's
and
but
I
think,
having
putting
them
in
a
place
actually
increases
the
likelihood.
H
Yeah,
so
I
mean
we
have
options
for
funding.
I
again,
I
really
encourage
us
not
not
to
get
not
to
make
that
be
a
barrier
to
deciding
whether
we
want
to
to
move
them
in
so,
and
the
options
for
funding
include
lf
can
continuing
to
fund
at
the
current
rate.
B
I
would
suggest
this
working
group
not
worry
about
the
funding,
because
that's
not
really
the
job
I
think
of
the
working
group
is
making
it
technically
good
and
bio.
If
there's
funding
needs
helping
to
work
out
how
the
funds
would
be
used
and
making
those
proposals,
but,
but
I
I
think
right
now,
the
goal
is
just
to
have
basically
provide
a
home
for
places
for
for
these
projects,
so
that
there's
interaction
where
there
hasn't
been
before.
I
David,
I
would
say,
like
you're,
completely
accurate
in
that,
like
the
working
groups,
we
should
just
figure
out
technically
what
we
want
to
do,
determine
what
funds
are
necessary.
So
we've
been
there
a
couple
other
working
groups
that
are
having
this
exact
same
funding,
question
right
and
what
we've
been
telling
people.
Oh,
I
see
a.
E
I
Document
what
the
funding
requirements
are
bring
those
to
the
attack
and
then
we'll
coordinate
with
the
governing
board
and
figure
out
how
funding
is
going
to
work
right.
So
we
have
to
solve
funding
no
matter
what,
but
right
now
like
kay
and
david
everybody's
saying,
let's
just
decide
if
this
is
the
right
thing
and
then
and
then
go
from
there.
C
Cool
yeah,
I
think
from
you
know,
in
terms
of
technical
and
the
work,
that's
being
done,
absolutely,
let's
make
a
lot
of
sense
in
this
working
group.
I'd
love
to
see
how
you
know
this
group
could
help
too
with
the
work
you
know.
I
don't
know
if
you
know
opens
up
some
new
doors,
for
you
know
making
some
of
the
work
easier,
better
or
whatever,
so
that
could
be
a
good
discussion
once
we
do
figure
out
the
funding
side
of
it
at
least.
B
Yeah,
well,
I
don't
think
we
have
to
wait
for
that
to
at
least
start
getting
something
harvard's
already
given
a
presentation.
I
know
they're
busting
their
butts,
trying
to
get
the
census
data
analyzed
and
I,
I
suspect,
they'll
soon
have
some
interesting
results
about
the
developers
that
I'm
hoping
will
help
us
better
approach.
The
idea
of
how
do
we
invest
resources
effectively
to
improve
security
of
open
source
software.
C
B
B
Well
and
to
be
fair
yeah,
it
lists
every
option
like
every
country
of
the
world
is
there's
page
after
page
of
countries.
It
wasn't
designed
for
a
short
list
of
pages
uh-oh
yeah
yeah,
but
maybe
he
figured
out
how.
C
To
present
now
we
should
be
okay,
yeah,
I
think,
maybe
in
one
of
either
the
next
meeting
or
folly
meeting
it
would
be
great
to
maybe
deep
dive
on
the
survey
a
little
bit.
If,
if
you,
if
you
don't
mind
and
then
we
can
sort
of
learn
a
bit
more
like
that,
just
like
we
did
with
the
senses,
I
don't
think
the
census.
2
presentation
went
deep
into
like
the
survey
and
the
developer
survey.
J
Yeah
we'd
be
happy
to
you
know
we
can
we're
still
we're
still
analyzing
a
lot
of
the
data
and
going
through,
but
we
can
give
you
some
of
the
the
higher
level
insights
that
we've
been
able
to
find.
Like
david
said.
We're
still,
you
know
we're
trying
to
bring
it
together,
make
it
look
pretty,
and
but
we
can
look
to
have
that
ready
to
present
for
the
next
and
that's
in
two
weeks
time
correct.
B
So
so
I
mean
kim,
I
don't
know
what
the
process
is
here,
but
I
I
would
propose
a
vote
either
now
or
a
schedule
or
something
like
that
on.
You
know
whether
not
this
yes
or
no.
A
In
general,
I
prefer
offline
votes,
so
like
a
poll
or
something
we
could
collect,
rather
than
making
people
go
through
this
and
say
things
in
person,
but
yeah,
I
think
we
could
start
it
today.
B
A
B
Yes,
yeah.
I
think
this
is
just
a
yes,
no,
but
you're
right
for
right
choice.
Doodle,
I
don't
think
can
do
that.
B
C
All
right,
very
cool
anything
else
on
that
topic,
or
should
we.
G
Jump
back,
I
just
want
to
make
a
quick
point
too.
I
I
like
where
we're
headed
in
that
when
we
were
looking
at
you
know
what
menu
of
services
could
we
provide
and
looking
at
potential
candidate
projects.
I
think
this
will
definitely
help.
You
know
at
least
point
us
in
the
right
direction
or
help
with
that
so
very
excited
to
see
what
comes
up.
C
Awesome
yeah
same
here,
I
think
you
know
we
can't
boil
the
ocean
and
fix
everything
but
having
you
know
having
this,
this
research
from
from
harvard
and
stuff
that
actually
gives
us
real
data
on.
C
Of
these
projects
will
help
us
sort
of
align
them
with
the
menu
of
services
that
we
hope
to
offer
short
plug
on
that
that
dock
is
listed
in
the
I
can
find
it
and
pull
it
up
and
pull
it
back
to
the
top,
but
there's
a
lot
of
good
ideas
in
there.
So
if
you
have
time
and
are
interested
the
dot,
that
doc
is
just
to
put
in
all
sorts
of
ideas
for
how
we
could
actually
help
open
source
projects
and
improve
their
security
posture.
C
D
D
Okay,
so
my
name
is
dmitry
bukov,
I'm
going
to
present
about
linux
kernel
security,
and
this
is
based
on
my
personal
observations
over
the
past
five
years,
working
in
the
area
of
linux
security.
It's
not
that
I
did
any
kind
of
special
research.
It's
just
things
I
observed
working
on
other
things,
my
background,
so
I
work
in
dynamic
tools,
team
at
google
for
about
10
years
now,
and
we
work
on
sanitizers
in
particular.
Address
sanitizer
threat,
synergize
memory,
synthesizer
and
hopefully
you
know
those
tools.
D
Maybe
those
tools
find
bugs
like
use
of
the
free
out
of
bounds,
access
data,
races,
use
the
financialized
memory
and
also
do
some
hardening
tools
and
bug,
detection
tools
for
production
and
some
fuzzing
tools,
in
particular
lip
fuzzer
and
to
assess
fuss
and
in
the
last
five
years,
I'm
involved
in
a
similar
work
for
linux
kernel.
We
do
bug
detection
tools
like
kernel,
address
sanitizer,
and
we
also
do
some
hardening
tools
and
some
fuzzing
tools,
in
particular,
cisco
and
sysbot,
which
is
kernel,
fuzzer
and
continuous
fuzzing
system.
D
Linux
kernel,
so
I
like
this
quote
a
lot
civilization
runs
on
linux.
If
you
look
around
it's
everything
is:
is
linux
right?
We
have
android
with
more
than
2
billion
users.
Today
we
have
cloud
hpc
servers
that
all
powered
by
linux.
We
have
chromebooks
notebooks,
iot
cars,
even
plants
and
space
stations,
and
last
but
not
least,
our
coffee
machines.
D
I
can
even
go
as
far
as
claiming
that
linux
kernel
is
the
most
security
critical
infrastructure
project
in
the
world.
Today
there
are
some
that
are
more
kind
of
security
important,
but
at
the
same
time
have
much
much
smaller
scope
and
if
you
think
about
security,
probably
the
first
thing
is:
do
you
think
about?
Are
those
loud
bugs
with
logos,
but
that's
really
only
tip
of
the
iceberg,
and
the
next
thing
here
think
about
is
probably
cds
and
there's
some
number
for
the
kernel.
D
Somehow
in
2017
there
were
way
more
and
then
past
two
years
there
were
three
times
less.
The
numbers
are
kind
of
reasonable
for
the
project
of
such
size.
D
D
D
If
you
look
at
the
rate
of
bug
reporting
it's,
it
varies,
but
and
it's
also
somewhat
outdated
information.
But
what
I
wanted
to
show
is
that
it's
not
that
it
somehow
goes
down
or
like
getting
close
to
zero.
It's
it's
really
most
random,
consistent
number
of
bucks
and
we
have
graphs
for
the
total
number
of
bugs.
We
reported-
and
we
have
so
this
here-
that
the
horizontal
line
is
three
years.
D
We
run
the
system
and
this
red
line
is
number
of
unfixed
or
open
box
and
red
and
sorry
black
and
green
lines
are
the
total
number
of
boxes
reported
and
total
number
of
feast
bugs.
D
D
So
I
need
I
need
to
know
that
not
all
of
bugs
we
find
have
security
implications,
we're
finding
just
box
and
really
different
mix
of
different
types
of
bugs,
but
due
to
the
nature
of
the
kernel,
lots
of
bugs
in
the
kernel
actually
have
some
security
implications,
even
say:
printing,
something
on
the
console.
Maybe
a
denial
of
service
in
some
contexts,
and
sometimes
even
innocent
bug
types
can
result
in
critical
security
issues,
and
I
will
show
examples
on
the
next
slide.
D
So
some
of
the
bad
things
you
find
is
some
related
to
net
remote
networking
attacks,
some
involved
even
override
of
the
memory
caused
by
incoming
network
packets,
some
cows
just
denied
of
service
and
the
last
two.
They
manifested
in
reasonably
innocent
way
like
some
hanks
or
same
silent
machine
collapse,
which
frequently
also
caused
by
say,
testing,
infrastructure
issues,
and
usually
those
are
even
not
looked
at.
E
D
Yes
and
the
next,
the
next
pilot
box
is
virtual
machine
escapes,
so
we've
seen
cases
where
hosts
can
write
a
guest
can
write
a
host
memory,
we've
seen
cases
where
information
leaks
from
the
host
to
guest,
which
is
particularly
bad
for
for
cloud
deployments
and
again
some
types
of
bugs
they
manifested
pretty
in
a
pretty
innocent
way.
For
example,
one
was
just
memory
leak.
It
wasn't
even
detected
as
a
memory
leak.
D
It
was
detected
just
episodic
out
of
memory
conditions
after
running
for
some
time,
but
in
the
end
it
turned
out
to
be
full
guess
the
host
escape,
because
this
was
caused
by
a
page
reference
leak
on
the
host
and
another
one
was
just
a
warning
which
is
usually
also
pretty
low
on.
D
One
example
is
usb
subsystem,
so
we
started
testing
usb
subsystem
by
injecting
network
sorry
packets
that
normally
came
from
the
usb
cable,
so
pretending
were
some
usb
device
and
by
now
found
more
within
300
bucks
triggerable
by
any
cable.
So
the
the
specific
thing
about
usb
is
that
any
cable
you
connect
to
the
machine.
You
can
talk
to
any
driver
and
pretend
to
be
any
hardware,
so
it
can
be
even
charger.
D
Cable
and
the
box
includes
also
memory
overwrites
information
leak
into
the
cable
and
other
types
of
bad
things,
and
we
still
have
limit
quite
limited
coverage
for
lots
of
drivers
who
just
reached
handshake
procedure.
So
it's
not
that
we
have
like
near
complete
coverage.
Usb
is
not
really
a
special
subsystem.
We
pretty
much
find
in
lots
of
bad
bucks
in
every
kernel
system
and
this
boat
is
not
is
not
a
complete
solution.
D
So,
for
example,
if
security
module
permits,
arbitrary
access
or
file
access
system
is
broken,
it's
perfectly
fine
with
this
bot
because
it
doesn't
lead
to
any
crashes.
So
another
view
on
on
the
box
is
via
stable
releases.
So
stable
releases
is
what
end
users
actually
use,
and
I
looked
at
the
number
of
backboards
into
stable
releases
and
for
the
last
releases
it's
above
15
000
and
for
the
4.14
it's
even
above
18
000.
Now
I
looked
at
the
sample
of
those
backboards,
most
of
them
more
than
say,
95
percent
actually
fixes.
D
So
it's
not
that,
like
new
functionalities
have
been
reported.
It's
actually
like
patches
that
fix
something
and
you
you
can
see
that.
Maybe
the
number
goes
down,
but
it's
not
true,
because
newer
releases,
they
are
have
shorter
lifetime
for
now.
So
if
we
look
at
the
number
of
backboards
per
month,
then
the
numbers
actually
go
down
go
up
and
for
the
latest
5.4
release,
it's
above
800
now
800
something
so
it
makes
it
something
like
28
per
day
each
day
for
the
past
10
months,.
D
Correct
yes,
but
it's
also
not
all
not
all
security
fixes
are
backported,
so
it's
true
both
ways.
We
also
have
some
fixes
that
are
not
backported
and
like.
We
know
that
there
are
lots
of
hundreds
of
them.
We
don't
know
about
all
of
them,
because
if
we
would
know
about
them,
we
would
report
them.
D
We
also
have
some
hundreds
of
boxes
and
just
not
fixed
upstream
and
obviously
have
some
bugs
that
are
not
found
yet
or
not
detectable
right,
because
if
we
have
lots
of
bugs
in
those
parts
of
the
kernel,
it's
reasonable
to
assume
that
other
parts
of
the
kernel
also
have
lots
of
bugs
so
based
on
this
again
conclude
that
every
release
contains
more
than
20
000
bucks
and
it's
not
getting
better
over
time.
D
At
least
I
don't
see
this
from
the
numbers,
and
it
also
means
that
the
bugs
are
being
introduced
at
at
roughly
the
same
rate,
at
least
at
the
same
rate
right
because
it
would
be
fixing
them
faster
than
they
introduced
to
get
to
zero
and
those
are
not
short-lived,
bugs
that
are
being
fixed
within
the
release,
say
it's
it's
normal
to
have
box
right,
that's
all
developed
by
humans.
So
if
something
is
introduced,
not
notice
quickly
and
then
fixed
quickly
doesn't
leave
the
release.
D
D
D
So
there
are
also,
I
think,
tens
of
thousands
of
those
forks
and
when
you
fork
a
kernel,
you
also
fork
all
of
the
box
that
are
in
that
kernel,
release
and
effectively.
Each
patch
backfork
becomes
a
new
bug
for
most
practical
purposes,
because
different
teams
work
on
those
forks
and
it
may
be
fixed
in
one
kernel,
but
not
in
another,
or
it
may
lead
to
different
conflicts
and
it
needs
to
be
tested
separately.
D
E
D
D
Despite
kernel,
patches
are
mailed
to
mailing
lists,
and
I
observed
a
number
of
fixes
and
particular
fixes
for
important
security
bugs
being
lost,
and
I
have
some
hypotheses
that
there
may
be
bias
towards
actually
losing
bug
fixes,
because
when
a
person
works
on
some
functionality,
they
usually
have
assignment
at
their
company
to
upstream
something
it's
on
their
to-do
list.
So
they
there
are
no
chances
that
they
will
forgot
about
this.
But
fix
is
frequently
done
as
kind
of
a
side
activity.
D
D
D
So
some
more
things
on
bug,
tracking,
there's,
no
general
process
for
triage
security
assessment
of
bugs
it
may
be
somewhat
different
than
the
subsystem,
because
kernel
rules
for
each
subsystem
are
really
different
and
they
may
work
differently.
Some
systems
are
better,
some
are
worse,
but
generally
there
is
no
assessment
from
what
I
see,
and
then
there
are
some
unmaintained
subsystems
in
particular
frame
buffer
is
an
interesting
one.
D
D
And
yes,
nobody
blocks
it
being
reported
on
the
mailing
list,
but
nobody
actually
really
reads
them
directly,
because
there's
too
much
traffic
and
there's
actually
a
bug.
Tracker
called
box
zela
but
usually
box,
for
example,
not
closed
in
the
in
this
bug.
Tracker
and
the
main
thing
you
want
from
a
bug
tracker
is
to
get
the
list
of
open
box.
So
if
you
don't
close
the
box,
it's
not
really
dance.
The
question
can
answer.
D
D
D
And
if
we
do
this,
we
we
can
claim
that
we
know
that
we
don't
have
critical
bugs,
at
least
for
for
the
level
of
testing
we
do,
but
it's
not
exactly
a
reality
for
linux
kernel
very
few
new
features
added
with
tests
and
bug
fixes
generally
go
without
test
this
for
the
thousands
of
bucks.
We
report
that
they've
seen
very
very
few
tests.
Regression
has
been
added
kernel
developers
generally,
don't
do
fuzzers
again.
D
Rules
are
different,
but
I've
seen
only
one
subsystem,
which
is
wireguard
that
was
fast
before
it
was
added
to
the
journal,
and
we
constantly
see
cases
where
even
exercising
some
functionality
in
very
basic
way
in
the
most
basic
way,
with
some
bug,
detection
tools
enabled
exposes
box,
which
means
that
it
wasn't
tested
with
this
tool
at
all,
and
this
harms
fuzzing,
because
the
fuzzer
starts
hitting
this
bug
all
the
time,
because
it's
like
you
really
don't
need
to
do
anything
special
to
hit
this
bug
and
I've
seen
the
interesting
case
where
I
just
executed,
cut
on
a
file
in
csfs
and
it
literally
smashed
kernel
stack
with
that
90s
style
bug
where
there
is
a
fixed
size
buffer
located
on
the
stack
and
a
sprint,
is
done
without
the
size
check
and
that
buffer
just
happened
to
be
like
smaller
than
that
data
that
is
actually
written
to.
D
D
D
Okay,
stable
releases,
so
stable
is
what
users
are
using,
or
at
least
should
be
using
and
there's
no
consistent
process
to
identify
backboards.
There
are
some
processes
developers
may
mark
patches
as
they
need
to
go
into
stable,
but
that's
optin,
and
then
there
are
some
machine
learning
systems,
but
there's
no
explicit
decision
for
for
each
patch
if
it
needs
to
go
or
not.
D
Some
whole
subsystems
don't
participate
in
this
stable
process,
and
one
thing
is
that
patches
are
being
applied
in
the
best
effort
manner.
If
there's
merge
conflicts
trying
to
apply
them,
they're
generally,
just
choked
so
there's
a
notification
that
this
patch
wasn't
applied,
and
then
anybody
may
act
on
this
or
not.
D
In
most
cases,
it's
not
being
acted
on
and
again
so
I
I
did
a
special
search
just
for
those
for
those
notification
and
included
case,
and-
and
this
gave
me
like
a
hundred-
I
think-
of
public
zero
days,
because
first,
one
that
I
saw
is
fig's
use
of
the
free
in
in
something
blah
blah
blah
and
it
was
being
dropped.
D
And
stable
backwards
introduce
also
box
and,
in
particular
I've
seen
case
where
it
introduced.
The
use
of
the
freon
network
receive
path
which
is
pretty
interesting
type
of
bug
and
we've
seen
cases
where
whole
subsystems
break
on
some
stable
backboards
or
when
boot
breaks,
and
it's
not
surprising
because
number
of
bucks
is
high.
Testing
is
not
very
efficient,
so
bug
fixes
also
introduced
bugs.
D
I
think
the
only
mandatory
testing
for
stable
is
build
testing,
which
is
really
nothing
and
then
the
rest
is
kind
of
optional.
If
a
person
is
not
on
a
vacation,
they
may
do
some
additional
testing,
and
usually
they
do,
but
also
we
have
those
tens
of
thousands
of
bugs
that
were
not
detected
on
the
release,
which
raises
questions
to
the
quality
of
the
testing.
D
Yes-
and
you
might
think
that
say,
broken
system
or
boot
is
not
really
a
security
issue,
but
this
leads
us
to
the
next
problem,
which
is
upstream
distrust
gap.
So
distrust
lots
of
distress
tend
to
look
at
the
cvs
and
that's
what
they
track
and
that's
what
they
try
to
fix
in
their
kernels,
but
kernel
really
don't
work
on
the
cve
level.
D
Kernel
works
on
the
buck
level,
so
distrust
say
that
we
fixed
all
cvs
we're
good
and
they
assume
that
somebody's
upstream
actually
filed
cvs
for
critical
security
issues,
but
upstream
explicitly
says
we
don't
do.
Cv
is
use
stable,
so
upstream
is
also
happy
because
they
provide
good,
stable
tree
for
end
users
and
black
hat's.
Obviously
super
happy
with
this
situation.
D
D
Yes,
this
last
shot
part
is
about
action
plan,
which
I
don't
have
so
this
this.
The
problem
is
not
is
not
small
and
not
local,
not
something
that
can
be
just
fixed
here
and
we're
like
we're
good,
and
this
is
actually
where
I
I
want
foundation
involvement,
and
I
know
ideas,
support
lots
of
the
known
solutions
that
work
in
corporate
environments
that
just
don't
work
in
the
open
source
world.
D
D
D
We
need
test
and
fuzz
and
synthesizers
coverage
to
be
adapted
as
part
of
the
upstream
development
process,
so
that
you
actually
can
make
any
any
statements
about
state
of
security
and
tragedy
and
track
and
bug
reports
seems
to
be
mandatory
for
for
securing
end
users
and
for
the
how
I
think
there
are
two
mostly
independent
parts
of
the
solution,
but
they're
also
complementary.
D
One
is
something
that
can
be
done
by
special,
say
task
force
and
can
be
actually
funded
and
these
things
like
testing
infrastructure
or
static
analysis
infrastructure
or
test
and
fuzz
and
frameworks
or
say
back
tracking
system
itself
and
there's
a
second
part
which
I
think
can
only
be
done
in
collective
way.
If
it's
adapted
in
the
upstream
development
process,
which
is
actually
adding
tests
and
agent
fathers
and
keeping
those
tests
and
fuzzers
working,
resulting
static
analysis
warnings
and
fashion
box,
and
so
on.
D
D
So
those
special
cases,
maybe
they
can
care
about
this
special
test
for
force.
So
linux
is
a
model
of
technology
and
innovation.
I
think
it's
just
a
very
positively
notable
project
in
lots
of
other
ways,
and
I
think
it
fully
deserves
to
also
be
model
of
open
source
security
and
with
this
thank
you
and
I'm
ready
to
do
questions
or
discussions.
F
F
Was
this
is
really
good?
I've
got
a
comment
about
the
a
couple
comments
and
I
know
we
don't
have
a
lot
of
time
here.
So
I'll
be
brief,
one
of
the
things
about
cves
that
I
think,
maybe
you
know
I
I
I
know
you
can't
go
backwards
in
your
in
your
presentation,
but
you
know
that
whole
thing
about.
Oh
well,
we've
got
all
these
security
fixes
upstream.
You
should
just
use
the
latest
stable
or
something
like
that.
F
We
don't
we
don't
respect
cds,
part
of
the
other
problem
with
with
if
a
security
fix
is
not
tagged
with
the
cbe
most
of
the
os
vendors,
like
red
hat,
etc,
do
not
they
don't
feel
a
forcing
function
to
actually
include
security
fixes
unless
there's
a
cve
tagged
with
it.
So,
according
to
me,
another
idea
might
be
just
go
through
and
create
cbes
for
all
the
security
issues.
F
I
mean
that
sounds
really
dramatic
and
you
know
kind
of
counterproductive,
but
I
think
one
of
the
things
the
foundation
could
do
is
confront
greg
and
thomas
and
say:
look.
Why
are
you
you
know?
F
Please
change
your
attitude
about
cbds
and-
and
I
I
think
oh
look,
you
went
back
well
done
and
you
know
I
I
I
don't.
I
don't
know
that
we
necessarily
have
a
lot
of
ability
to
convince
greg
and
thomas
about
the
subject.
But
you
know
I've
certainly
heard
greg
talk
about
it.
Saying.
Oh,
you
know,
cvs
are
not
important.
People
are
only
filing
cves
to
burnish
their
careers.
F
You
know
things
like
that
and
it's
like
well,
okay,
but
look
a
lot
of
people,
don't
necessarily
get
you
know,
use
the
stable
version
so
anyway.
That
was
one
comment
I
had.
F
I
have
another
comment
about
an
area
all
these
sounds
by
the
way
really
good
at
dimitri.
I
think
they're,
excellent.
I've
heard
you
your
talks
before
linux
security,
colonel
yeah,
linux
security
summit,
and
I
I
think
you
worked
really
great
but
another
area.
I
think
that
would
be
useful
to
encourage
somehow
are
architecting
anti-exploitation
features.
You
know,
there's
whole
you
know
use
after
free,
there's
there's
you
know,
stack
or
stack
overflows.
F
Various
other
attack
scenarios
that
seem
like
they're,
relatively
easy
for
a
developer
to
put
in
the
kernel,
and
it
seems
like
there's
a
there
would
be
an
interesting
thought
process.
I
think
I
know
there
are
plenty
of
smart
people
thinking
about
this,
but
a
thing
about
well.
Are
there
ways
to
re-engineer
how
memory
is
allocated
stacks
allocated
et
cetera
to
to
basically
prevent
whole
classes
of
security
issues
right
through
the
architecture
of
the
kernel?
So
anyway,
just
a
couple
thoughts
from
your
presentation.
Thanks
again,
it
was
really.
B
Yeah,
if
I
can
in-
and
I
suspect,
some
other
folks-
I
mean
keith
cook's-
been
specifically
working
on
the
kernel
hardening
project
specifically
to
identify
and
counter
whole
classes.
As
far
as
you
know,
some
of
those
memory
allocation
ones,
though
I
mean
those-
are
fundamentally
baked
into
c.
Your
solution
is
and
stop
using
c
for
some
of
these
classes.
B
F
Yeah
we
can
discuss
rust
or
those
sorts
of
approaches
which
I
think
are
yeah.
There
are
language,
specific
things
and
see
yeah
that
I
know
make
it
make
it
tough,
but
then
there
are
also
memory
out
common
memory,
allocators
slab,
allocators,
etc
in
the
linux
kernel
that
people
are
encouraged
to
use
right
and
I
think
some
of
the
pushback
for
you
know
adding
what
I
what
I
call
anti-exploitation
features
has
been
performance
right.
F
We
don't
want
to
slow
down
the
kernel,
so
we
don't
want
to
you
know,
add
these
things
or
we'll
add
them
as
as
as
config
options
that
nobody
uses
right.
So
I
I
I
I
I
think,
they're
probably
and
yeah
case
is
doing
great
work
at
google.
I
think
he's
phenomenal
and
I
I
I
absolutely
agree
he's
he
is
a
very
strong
voice
in
this
area,
so
kudos
to
him.
D
Thank
you
so
for
cvs,
I
get
an
impression
that
greg
is
actually
want
to
go
in
in
the
other
direction,
which
is
convincing
distrust
to
use
all
of
the
backboards.
But
I
don't
know
both
ways
can
work.
One
potential
option
is
there's
thing
called
issuing
authority
for
cve.
So
if
there
is
a
problem
of
low
quality
of
cvs,
then
I
don't
know
linux
foundation.
Something
can
become
issue
authority
for
cvs
and
actually
guard
the
the
quality
and
solve
this
problem.
That.
F
B
D
F
D
B
D
D
I
think,
though,
those
are
still
made,
and
also
so
initialize
memory
we
mostly
solved
by
just
initializing
all
memory.
It
kills
all
of
the
information
leaks,
but
this
is
opt-in
because
it
has
some
performance
impact,
so
it's
up
to
distrust
to
enable
it
or
not
and
for
the
use
of
the
free
and
out
of
bounds.
Our
biggest
hope
on
the
memory
tagging
technologies
like
rmmt,
which,
with
the
help
of
of
cpu,
can
make
actually
protection
from
use
of
the
freezing
out
of
bounds
have
reasonable
cost.
C
I
think
we're
about
out
of
time.
We
probably
didn't
leave
you
enough
time
for
discussion,
dimitri,
but
thank
you
so
much.
I
think
we'll
be
continuing.
These
conversations
like
I
would
love
to
know
from
you
know
people
here
today,
like
maybe
who
your
organization
is
sort
of
working
on
linux
stuff
and
how
we
can
sort
of
come
together
collectively
to
help
with
some
of
this
stuff
either
through
you
know,
funding
once
we
figure
out
how
this
foundation
is
going
to
be
funded
or
other
efforts.
C
So
yeah
I
mean
this
is
going
to
be
recorded
or
it
is
recorded.
So
if
you,
if
you
want.
C
Presentation
and
sort
of
come
back.
I
think
linux
itself
almost
could
be
a
whole.
You
know
almost
its
own
working
group,
but
we're
not
even
going
to
talk
about
that.
I
think
this
is
a
good
place
where
we
can
make.
You
know
some
big
impact
and
google
is
very
much
interested,
so
we'd
love
to
hear
from
from
others,
and
maybe
we
can
have.
We
can
open
up
the
discussion
again
in
a
future
meeting,
since
we
kind
of
ran
out
of
time
today,
so
awesome,
okay,
thank
you
again,
dimitri.