►
From YouTube: Attacking & Defending Kubernetes TEE Enclaves in Critical Infrastructure - Robert Ficcaglia
Description
Don’t miss out! Join us at our upcoming hybrid event: KubeCon + CloudNativeCon North America 2022 from October 24-28 in Detroit (and online!). Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Attacking & Defending Kubernetes TEE Enclaves in Critical Infrastructure - Robert Ficcaglia, SunStone Secure, LLC
Trusted Execution Environments (TEE)s are a feature of Intel, AMD, ARM and other chip platforms, widely available on public clouds for high security infrastructure. Kubernetes can be deployed with TEE enclaves to create a Trusted Computing Base (TCB) which can cryptographically protect the compute and memory environment for the Kubernetes control plane, data flows, and CI/CD pipelines on-chip. This greatly reduces the attack "surface area" and reduces 3rd party supply chain risks. The session will examine detailed Kubernetes threat models for critical infrastructure and demonstrate how to attack and defend Kubernetes workloads in the context of TEEs. Attendees will learn how to use enclaves to protect the integrity of container images used for workloads, deploy TEE-based Pods,.examine development and operational challenges with TEE usage, and explore compliance benefits including specific policy and control mappings for GDPR, CCPA, PCI, HIPAA and NIST 800-53.
A
Okay,
good
morning,
everyone
welcome
to
the
session
attacking
and
defending
kubernetes
te
enclaves
and
critical
infrastructure.
My
name
is
robert
ficalia,
I'm
the
co-chair
of
the
kubernetes
policy
work
group
and
a
member
of
the
cncf
security
tag
have
led
some
security
assessments
in
that
group
and
I'm
also
assisting
with
kubernetes
third
party
audit
in
my
day
job.
I
work
with
high
security,
critical
systems,
things
in
payments,
banking,
health
care
and
government
and,
of
course,
I've
I'm
enjoying
the
spanish
hospitality,
as
I
hope
you
all
have
as
well.
A
So
what
is
a
te
when
they
assigned
me
the
auditorium?
I
assumed
that
lots
of
people
were
coming
for
a
free
t-shirt,
but
we're
not
talking
about
teas.
In
that
sense
talking
about
trusted
execution
environments.
These
are
hardware-enabled
enclaves
that
allow
you
to
protect
your
code
and
data
while
in
use.
So
many
of
you
are
probably
familiar
with
the
concept
of
protecting
data
at
rest
on
disk
storage
in
data
stores
and
transit
tls,
your
tcpip
sockets,
protected
by
encryption
integrity.
A
Oh
and
I
have
lost
money,
so
those
of
you
who
may
have
done
attack
modeling
threat,
modeling
or
even
trust
modeling
will
at
some
point
start
making
assumptions
documenting
those
assumptions
and
if
you're
operating
in
userland,
usually
you're
making
assumptions
like,
I
can
trust
my
hardware
provider.
I
can
trust
my
chip
manufacturer.
I
can
trust
my
cloud
provider.
I
can
trust
my
sis
admin,
my
root
users,
who
are
employed
and
background
checked,
but
what,
if
you
can't?
A
A
If
there's
a
large
financial
opportunity,
then
you
may
be
storing
value
in
the
billions
of
dollars,
and
so
it
becomes
a
high
value
target.
So
that's
the
audience
we're
really
addressing
today.
Those
are
the
attackers
that
we're
interested
in
and
those
of
us
who
are
defending
those
are
the
environments
that
we're
defending.
A
I
mentioned
some
of
the
use
cases,
but
I
think
where
tes
and
enclaves
really
got
their
their
start
was
enabling
a
more
scalable
version
of
what
had
already
been
used
for
a
decade,
plus
things
that
were
hardware
based
and
rooted
a
a
trust
chain,
so
that
you
as
a
developer,
could
deploy
code
in
a
secure
way.
But
that
was
very
hardware
specific.
A
But
in
general
you
can
also
use
this
to
increase
your
compliance
posture
and
we'll
talk
about
a
little
about
that
at
the
end
and
if
you're
dealing
in
a
regulated
environment.
Gdpr,
of
course,
is
a
common
topic
for
us
today
operating
in
the
eu.
Then
you
might
want
to
have
a
way
to
prove
that
you
are
protecting
that
user
data
from
the
cloud
provider
itself
and
then
again
as
we
get
into
blockchain
and
smart
contracts.
A
If
you
want
to
protect
intellectual
property
during
machine
learning,
and
you
want
to
be
able
to
use
data,
that's
not
yours
and
you
do
or
and
or
you
don't
want
to
disclose
your
algorithms.
These
are
all
use
cases
for
hardware
based
encryption
hardware
based
isolation,
and
so
that's
a
quote
from
the
confidential
computing
folks,
you're,
basically
trying
to
remove
as
much
of
the
attack
surface
as
possible
down
to
the
as
close
to
the
hardware
as
you
can
get.
A
So
if
we
take
a
quick,
deeper
dive
into
what
exactly
this
means
at
hardware
level,
it's
really
a
special
set
of
registers
and
opcodes
at
the
cpu
level.
That's
interacting
with
usually
a
memory,
protection,
co-processor
or
unit
on
the
cpu,
and
it's
enabling
the
the
separation
of
a
trusted
area
in
memory
usually
enabled
at
the
bios
level
and
then
in
a
small
amount
of
micro
code,
and
that
allows
you
to
marshal
calls
between
a
trusted
region
of
memory
and
encrypted
region
of
memory
and
then
outside
of
that
enclave.
You
can
pass
secrets
in.
A
You
can
get
secret
data
out
encrypted
and
it's
unique
to
that
processor
right.
So
you
know
you're
operating
in
a
particular
environment
and
that
you
can.
You
can
verify
that.
We'll
talk
a
little
bit
more
about
that.
So
it's
authenticated.
As
the
data
is
passed
in.
It
is
now
confidential
and
even
at
the
code
level,
you
can
be
assured
that
the
code
itself
has
been
checked
for
integrity,
that
no
one
has
tampered
with
it.
It's
exactly
the
code
that
you
expect.
A
A
I
am
not
affiliated
with
intel
or
any
chip
manufacturer.
I'm
not
affiliated
with
any
enclave
or
te
software
provider.
I
have
no
horse
in
this
race.
I
am
essentially
an
operator,
probably
like
many
of
you
looking
for
a
way
to
solve
a
particular
problem
and
and
sgx
is
one
implementation.
That's
widely
available
arm
and
others
are,
are
making
progress.
A
But
if
you
look
at
how
that
memory,
encryption
works,
you've,
you've
got
some
reserved
memory
and
you've
got
pages
of
memory
in
a
lookup
protected
in
the
microcode,
a
lookup
table,
and
then
anytime
you
deploy
an
enclave
and
any
of
that
reserved
memory.
Space
for
your
enclave
is
managed
in
a
in
a
cached
array
so
that
you
have
a
mapping
between
what
pages
are
being
used
and
how
they
are
assigned
to
each
enclave.
A
A
There's
a
on
the
chip.
There's
a
component.
We
talked
a
little
bit
about
provisioning
enclave
to
kind
of
bootstrap.
All
this
there's
usually
something
a
quoting
enclave
that
manages
that
verification
to
to
the
global
registry,
so
data
you
need
to
have
data
that
you've
operated
on
in
the
enclave.
You
need
to
somehow
persist
that
outside
the
enclave
and
that's
where
sgx
and
others
arm
have
a
scheme
for
sealing
the
data
and
then
that
way
you
can
call
special
routines.
A
That
will
allow
you
to
encrypt
it
with
a
key
that
you
know
came
from
the
enclave
persist
it
outside
of
the
enclave
and
then
be
able
to
restore
it
back
into
the
enclave
and
use
it
for
later.
Otherwise,
if
you,
if
you're,
only
operating
on
very
small
amounts
of
data,
you
might
not
need
this,
but
any
any
practical
application
for
dealing
with
machine
learning,
block
chains,
et
cetera,
you're,
probably
going
to
need
to
seal
data
and
persist
it
outside
of
the
enclave
securely.
A
A
Let's
see
so
how
how
do
practically?
How
do
we
make
use
of
this?
You
have
a
few
options.
You
can
kind
of
hand
craft
your
code,
re-architect
your
application
to
use
only
those
specific
o
calls
and
e-calls
these
trusted
entry
ways
into
the
enclave
between
untrusted
and
trusted.
You
can
try
to
wrap
it.
A
You
can
there's
some
code
that
we'll
talk
about
that
will
allow
you
to
convert
your
existing
code
into
enclave,
ready
code
and
then
kind
of
a
newer
option
is
to
use
things
like
wasm
to
create
byte
code
and
that
that
can
be
used
across
t
architecture.
So
you
get
a
little
bit
more
portability
and
the
idea
is
that
you're
getting
the
application
you
have
today
you're
just
cross-compiling
that
so
those
of
you
who
might
be
fans
of
casa
de
papel,
I
like
to
put
myself
in
the
mentality
of
what
would
the
professor
do.
A
So
probably
he
wouldn't
go
for
direct
assault
through
the
front
door,
so
you
wouldn't
attack
the
boundary
directly.
Although
you
might
use
that
as
a
form
of
misdirection,
you
would
probably
try
to
attack
every
part
of
the
supply
chain.
You'd
probably
attack
the
personnel
involved,
the
cloud
provider
you'd,
probably
attack
the
provider.
Hardware
systems
integration,
so
interesting
reports
in
the
last
couple
of
months
from
some
startups
doing,
work
on
looking
at
components
on
a
board
found
that
a
vast
majority
of
them
have
fakes,
so
you're
getting
a
bill
of
materials.
A
It
says
it's
from
this
manufacturer
that
manufacturer
and
you
realize
nope
it's
it's
been
tampered
with
or
it's.
You
know
something
off
of
a
different
market
and
it's
been
repackaged
to
look
like
the
chip
you're
expecting
so
you're
highly
motivated
attacker
for
a
high
value
target
is
going
to
make
no
assumptions
right,
they're,
going
to
assume
that
all
parts
of
this
system
are
attackable
and
they're
going
to
spend
the
time
and
the
resources
to
do
that.
A
On
top
of
that,
you've
got
to
have
you
know,
firmware
you've
got
micro
code,
you're,
going
to
have
kernels
and
operating
systems
and
drivers,
and
then
inside
of
your
application
that
you've
now
somehow
enabled
for
enclave.
You've
got
this
whole
set
of
code,
all
of
which
would
be
part
of
the
trusted
computing
base
or
attack
surface.
If
you
look
at
it
from
the
perspective
of
an
attacker,
so
a
big
part
of
some
of
the
shortcomings
of
enclaves
is
that
they
are
susceptible
to
side
channel
attacks.
So
you
can
measure
the
the
timing.
A
You
can
measure
the
rhythm,
the
cadence
of
operations
and
then
you
can
baseline
good
versus
bad.
You
can
tease
out
bits
of
a
secret
key
just
by
measuring
the
kind
of
thermodynamics
of
what's
happening
over
time,
and
so
we'll
talk
a
bit
about
some
of
the
defenses
at
the
end,
but
that
is
an
ongoing
concern
and
the
chip
manufacturers
continue
to
layer
on
every
generation,
defense
techniques
for
side
channels.
A
So
I
just
I'm
not
going
to
go
into
the
detail
of
what
what
this
attack
tree
looks
like,
but
just
to
put
out
there
the
idea
that
every
one
of
those
cpu
caches
the
bus
caches
the
bios.
All
of
these
have
attacks
that
are
documented,
either
academically
or
in
some
open
source
literature.
So
it's
it's
not
a
given
that
just
because
it's
in
hardware,
it's
secure,
I
think,
if
you
take
away
one
thing
today
that
you
know
trust
is,
is
very
difficult
in
these
types
of
systems.
A
A
Is
that
trustworthy?
Maybe
it's
like
risk
and
you
put
out
all
the
designs
for
the
hardware
for
all
the
and
open
source,
all
the
code.
Is
that
enough
to
be
trusted
or
are
enough
reasonably
educated
folks?
Looking
at
that
code
in
a
meaningful
way,
or
do
you
just
rely
on
standards,
bodies
and
talks
like
this
to
make
your
own
decision?
A
What
I,
what
I
think
I
would
have
you
come
away
with
today.
Is
it's
not
a
silver
bullet,
so
I've
heard
some
high
level
hand
waving
that
if
you
put
everything
in
the
te,
then
you
don't
have
to
worry
about
xyz
that
somehow
it's
bestowed
this
magic
that,
because
it's
in
a
te,
no
other
controls
are
required
and
it's
perfectly
secure.
A
Obviously
we're
all
interested
in
how
kubernetes
can
use
this
technology,
so
the
the
most
obvious
way
to
think
about
this
is
at
the
container
level
at
the
pod
level.
We
want
to
deploy
our
workloads
somewhat
easily
into
kubernetes.
We
in
talking
about
that
attack
surface.
You
probably
don't
want
to
bring
the
entire
kubernetes
control
plane
into
that
trusted
computing
base.
Because
again,
any
any
flaw
in
that
trusted
computing
base
is
exploitable
as
attackable.
So
you
really
want
to
constrain
down
to
the
most
useful
unit
and
for
all
of
us
in
the
kubernetes
environment.
A
That
would
ideally
be
the
pod.
So
that's,
I
think,
we're
going
to
focus
most
of
our
attention
now.
If
you're
trying
to
operate
this,
you
already
have
a
tough
job
operating
kubernetes
as
it
is
now.
As
a
devops
person,
you
may
be
required
to
restructure
your
application,
re-architect,
maybe
cross-compile
things
you
have
to
worry
about.
How
t's
are
communicating?
Do
you
put?
Are
you
assigning
workloads
to
the
right
nodes?
Are
you
putting
the
right
hardware?
Do
you
have
a
mix
of
cpu
nodes?
A
A
Some
I've
I've
used
some.
I
haven't
so
open
enclave,
so
I
look
at
this
as
your
first
step.
So
if
you're,
you
know
right
above
just
taking
the
sdks
from
the
chip
manufacturer
and
using
their
utilities,
open
enclave
adds
a
layer
of
abstraction
right,
so
they're
trying
to
get
multi-te
support,
cross
os
support
when
you're
developing
four
enclaves
from
just
the
sdks.
You
have
a
lot
of
responsibility.
The
crypto
libraries
that
they
distribute
are
usually
marked
as
not
for
production.
A
They
may
not.
Have
you
know
past
fips,
you
don't
get
any
operating
system,
so
you
have
to
produce
libraries
of
your
own
or
use
existing
libraries
that
have
been
tested
on
these
enclaves.
So
open
enclaves
gives
you
a
lot
of
that
functionality
at
a
kind
of
an
sdk
abstraction
and
makes
it
possible
to
do
more
powerful
things.
In
fact,
most
of
what
we'll
talk
next
in
some
way
or
another,
either
uses
open
enclave
directly
or
has
learned
a
lot
from
open
enclave
and
mirrored
some
of
their
approaches.
A
So
the
next
level
of
abstraction
is,
you
can
kind
of
wrap
your
application
into
a
unikernel
lib
os,
basically
you're,
creating
a
process
so
instead
of
having
a
modular
os
with
kernels
drivers,
separated
you're
kind
of
taking
the
exact
opposite
route,
you're
compiling
everything
into
a
static
executable
and
that's
what
you're
going
to
deploy
in
your
pod.
So
there
are
a
couple
of
open
source
projects
that
you
should
definitely
take
a
look
at
aklam
and
forgive
the
project.
A
A
So
another
way
to
do
it
is
kind
of
create
a
shim.
So
in
clavare
is
an
approach
where
you
kind
of
create
a
shim,
they
call
it
run
e
or
roon,
and
they
allow
you
to
use
your
your
containers
if
they're
oci
compliant
pretty
much
out
of
the
box
right.
So
you
can
now
just
run
rune,
run
e
against
your
container
and
create
an
enclave
compatible.
A
Container-
and
they
also
like,
say
they
piggyback
on
aklam
and
grameen
and
the
wasm
so
yeah.
I
think
this
one
is
a
pretty
easy
way
to
get.
If
you
have
a
pod
application,
you
don't
want
to
or
can't
do
much
refactoring
and
you're,
not
that
much
interested
in
the
details
of
how
the
different
sdks
and
attestation
plug-ins
work.
A
A
No
code
changes
required
no
special,
tooling
required
and
they
can
deploy
grameen
and
aklum
apps.
As
well
so
it's
kind
of
a
nice
stack,
I
think
again
the
the
biggest
concern
I
would
have
with
this
is
that
now
you've
added
even
more
convenience
and
functionality
and
even
more
to
your
tcb.
So
it
requires
you
to
really
think
through
what
are
the
trade-offs
of
you
know.
B
A
A
I'd
say
the
last
one
I
would
take
a
look
at
is
an
arcs,
so
in
this
case
they're
have
taking
your
code.
You
don't
have
to
make
much
code
modification
at
all
if
any
and
you're
cross-compiling
that
to
wasm,
so
they
manage
all
of
the
functions
for
the
o
calls
and
the
e-calls
they're
doing
all
the
remote
asset
station
they've
implemented
pretty
much
everything
you
need
to
deploy
your
your
wise
map.
A
The
the
problem
here,
of
course,
is
if
you're
not
familiar
with
wasm,
if
your
application
is
not
organized
so
that
you
can
quickly
partition
it
into
cross-compilable
components,
this
might
not
be
an
option
for
you.
I'd
say
you
know
for
fairly
modular
small
applications.
This
is
a
great
idea
and
I
think,
there's
project
the
project
is
making
a
lot
of
fast
progress.
I
think
they're
not
quite
up
to
production
standards.
A
I
think
they
themselves
would
would
note
that
in
the
documentation,
but
I
think
it's
it's
a
way
forward
in
the
next
couple
of
years,
so
I've
given
kind
of
an
overview.
This
is
my
take
on.
If
I
lay
out
what
are
the,
what
are
the
attributes
we're
looking
for
in
in
a
platform
and
then
we
kind
of
overlay
those
approaches
you
know
kind
of
on
the
left,
the
sdk,
the
plugins,
you
can
use
kind
of
off
the
shelf.
A
You
know
you
have
to
do
everything
yourself
and
you
know,
while
there's
you
know
very
small
trusted
computing
base,
you
really
have
to
do
a
lot
of
work
right,
so
you're
kind
of
trying
I'm
trying
to
find
as
someone
who's
deploying
these
systems,
I'm
trying
to
find
the
balance
between
make
it
easy
enough
for
me
to
run
real-world
applications,
but
do
it
enough
of
the
leg
work
to
make
sure
that
I'm
confident
and
kind
of
test
that
I
have
a
trust,
a
trust
computer
base
that
I
can.
I
can
myself
audit
and
verify.
A
So
I
think,
if
I
kind
of
my
my
choice-
and
I
think
we
talk
about
that
a
little
bit-
oh
I'll,
come
back
to
that
sorry.
So
if
you're
thinking
about
this
from
a
defense
perspective,
talk
about
that,
you
know
minimizing
the
trusted
computing
base
you
do.
I
would
recommend
that
intel
and
others
have
done
some
formal
verification.
A
I
would
say
for
those
open
enclave,
even
the
oclum
grameen.
I
think
if
they
could
benefit
greatly
from
using
that
formal
verification
approach-
and
you
know
it's-
it's
not
a
silver
bullet
either.
You
still
have
to
continue
to
do
that.
Every
change!
It's
not
going
to
find
concrete
bugs
in
you
know,
code
check-ins.
It's
going
to
really
model
the
system
and
find
fundamental
design
flaws,
but
I
think
it
gives
you
a
level
of.
A
Integrity
to
the
to
the
design
that
you
can
be
more
comfortable
using
a
particular
solution.
So,
on
the
hardware
side
you
know
the
chip
providers
themselves
are
adding
more
control
over
the
memory
layout
and
memory
access.
You
know
for,
for
those
return-oriented
programming
jump,
pointed
programming
attacks.
A
Yeah
so
there's
intel
has
tdx
it's
their
newer
capability
and
that's
adding
you
know
different
king
to
the
memory
encryption
and
it's
you
know,
adding
more
granularity
to
the
memory
page
encryption
and
it
does
have
support
on
aks.
I
will
note
that
the
a
if
you're
running
kubernetes
on
azure,
they
have
a
lot
of
support
for
all
the
tools
that
I've
shown
again
not
affiliated
with
azure,
but
you
you
will
find
it
easier
to
do
some
of
your
prototyping
on
azure,
using
their
confidential
aks
support.
A
There's
another
set
of
even
more
granular
controls,
which,
if,
if
you're
contracting
with
government
agencies,
they
can
layer
on
specific
controls,
it
may
not
be
in
a
particular
baseline.
So
here
again
the
formal
formal
model
for
your
verification
is
helpful,
you're
getting
non-modifiable
executables.
So
it's
a
lot
of
these
boxes,
get
checked
by
using
enclaves.
A
A
A
So
we
kind
of
fell
into
that
middle
ground
and
and
are
using
testing
both
combination
of
the
oculum
grameen.
And
then
you
know
we
are
looking
at
in
clavari.
I
think
our
our
current
inclination
is
to
not
using
kovari
just
given
that
extra
level
of
code
that
it
adds
with.
I
think,
not
not
that
much
convenience
not
to
say
that
it's
not
a
good
project.
It's
just
for
us.
A
A
Yeah,
so
the
question:
did
everyone
hear
the
question?
The
question
is
about
you're
protecting
the
key,
but
what
about
the
supply
chain
code
that
you're
pulling
in
so
as
as
you're
pulling
in
libraries
and
open
source
into
your
application?
That
is
part
of
the
the
trusted
computing
base
that
you're
now
relying
on.
So
the
there's,
no
real
magic
to
how
the
enclave
is
going
to
protect
the
supply
chain.
A
It
will
provide
code
integrity
so
that
you
know
that
the
the
code
that
you've
compiled
into
your
application
or
that
you've
cross-compiled
the
wasm
is
the
same
code
that
you
compiled,
but
it's
not
going
to
and
and
then
you
know,
when
you
load
it
into
the
enclave,
it
will
verify
cryptographically
hash
that
it
is
that
code.
So
you
know
that
it
hasn't
been
modified
from
the
time
you
compiled
it
and
into
the
time
it's
running
in
the
enclave.
But
up
until
the
point
where
you
are
compiling
in
that
code.
A
Probably
represents
the
largest
and
most
fruitful
attack
surface.
If
I
think
of
it
as
an
attacker,
you
know
I
can
somewhat
dismiss
a
lot
of
the
the
hardware
you
know
without
I
I
would
say
for
a
high
critical
system.
I'm
absolutely
going
to
put
that
on
my
list,
but
the
low
hanging
fruit
is
to
go
after
the
supply
chain
right.
So
I'm
going
to
try
to
introduce
very
subtle
timing
changes
in
open
source
libraries
that
nobody
really
looks
at
too
closely.
A
So
I
might
go
attack
their
github
repos.
I
might
attack
their
their
javascript
packages,
I'm
going
to
try
to
exploit
those
return,
oriented
programming,
jump,
pointed
programming,
tricks
and
extract
data
out
of
the
enclave
using
those
open
source
bugs
or
malware
hacks
that
I
put
into
that
open
source
library.
B
A
Yeah,
so
the
question
is:
if
the
orchestra,
orchestrator
and
control
plane
should
essentially
be
in
the
enclave
as
well
right.
So
a
couple
of
answers
there,
one
you
know
just
at
a
very
high
level.
There
is
a
performance
hit
when
you,
when
you
work
with
these
enclaves
right
so
you're,
losing
a
lot
of
the
memory
optimizations
different
levels
of
caching,
your
different
you.
B
A
Hardware,
performance
optimizations:
you
may
be
losing
a
lot
of
operating
system,
caching
and
performance
tuning,
so
you
have
to
consider
what
is
the
performance
hit
in
in
using
this,
and
if
I
just
stick
the
whole
database
or
whole,
you
know
application
stack
and
control,
plane
and
kubernetes
into
the
enclave
itself.
You
know
the
performance
hit
is
going
to
be
significant,
not
to
say
it's
impossible
and
and
certainly
with
those
newer
processors
giving
you
more
memory.
A
A
A
The
only
thing
I
trust
is
that
intel
or
arm
chip,
so
everything
else
is
about
convenience
really
and
you
know,
developer
productivity.
So
I
think
it's
just
a
trade-off.
You
you
want
to
minimize
the
amount
of
code
that
you
have
to
either
formally
verify,
or
you
know,
quasi-formally
verify
and
scrutinize,
and
do
code
audits
and
code
reviews
and
lab
tests,
whatever
mechanism
you're
going
to
choose.
A
But
as
you
expand
that
into
kubernetes,
I
mean,
as
I
mentioned
at
the
beginning,
I'm
helping
the
the
sig
security
group.
Do
the
third
party
kubernetes
security
audit
and
that
hasn't
been
done
since
2019
right.
So
I'm
you
know,
don't
know,
what's
going
to
shake
out
of
that,
but
I'm
sure
they're
going
to
be
a
few
things.
A
The
attackers,
of
course,
are
going
to
be
looking
for
every
opportunity
in
every
layer
of
care.
We
need
to
use
the
implant
code
that
will
enable
those
memory
layout
memory,
timing,
attacks,
and
so
it
just
gives
them
a
huge
surface
area.
So
I'd
say
for
I:
if
you
find
something
kind
of
a
moderate
level
of
risk,
it's
it's
definitely
something
I'd
consider.