Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/835 Thanks!
These two research assistants.
First published in 2014.
Since then, they have often collaborated
for all vulnerabilities to
improving low level defenses.
Please give a warm 34C three Welcome
to Benjamin on Philip.
Thanks for the intro.
Thanks for coming.
Today, we present our research
on Michael Cote.
This is a joint book with our colleagues
and our supervisors from Whole University
Belgium.
First of all, I want to give a small
disclaimer.
The technical
details in this talk are quite specific
to in the UK.
Tim and his processors,
the newest release processor
that our stuff works with, is from
2013
and also most of
the findings are from reverse
engineering.
So if you want to replicate experiments
at home, please proceed at your own
risk because we may trigger unintended
behavior on the CPU.
So let's get started.
First of all, we want across
the board microscope, which is
a given architecture of a crash
course.
We want to solely explore the
question whether it's hackable.
And in the end, there will be something
more time.
So first of all, let's Michael
code.
If this is your CPU,
you can imagine
microcode to be
a small computer within your
CPU, which does all
sorts of complex things that you cover
in the stock, and we will see how
you can deal with it.
So first of all, I want to
give some previous work.
First of all, there are empty patents
that are publicly available, and
they give us a good general overview
of the architectural details.
So then there's the website to architect,
and there are some rather
detailed article about
the physical placement
of specific components on
the top of the chip.
Then there's the anonymous blog post
from 2004 up to
the next post, and
basically it's revealed for the
first time that microcode
is updatable and the
some Mississippi use even except
microcode if they are modified
and the text is corrected.
So this basically was the initial
idea of our research.
There's a paper security analysis
of x86 processor microcode.
They cover
mostly security
stuff related about microcode updates
from Internet M.D.
processors and
give a general overview.
So then there's the work of
a recall.
He's he probably has some internal
knowledge and is also
doing really cool stuff, only medical
code.
So not
even though. But Michael, coders and not
related work to us.
Let's have a look at what it's actually
used for.
So first of all, it's used
for instruction decoding.
It's used to bucks to fix
bugs and CPUs that are in the field
already, so they are already rolled out
its use for exception handling on the
architectural level.
So, um,
if there is some division
by zero, for example, the CPU
somehow needs to detect it and
test the exception and the information
to the operating system.
And this is handled in local court.
Also, microcode is used
for power management in the CPU
and can be used by the vendors
to implement complex CPU
features like Intel's two x, for example.
Um, so we heard
that Michael Code is used
for instruction decoding.
No one to see why this
is so the
x86 instruction that architecture is
quite complex.
Um, it is some variable
length instructions that, as you can see
here, there's an instruction of a
thunderbolt and an instruction with
several bytes.
And usually the first
byte indicates how long such an
instruction is, which helps
during the recording process.
But of course, there's an exception to
this the instruction
prefixes which delay the decision,
how long instruction is going to be one
for the boys.
And on top of that, several
of those and they can also be applied
combined to form all
kinds of complex
instructions.
Also, the instructions
that extensions.
If you have a victor
floating point, addition and
subtraction, the pectin,
a precision floating point units.
And this instruction has several
operations and is quite complex to
decode and
also quite complex to execute or to
be executed, the fantasy view you.
And due to this
complexity in it
and small computer
in our CPU to actually
decode this
now, we are going to have a quick look at
how this decoding looks like.
We have an 86 instruction
on the left pop up the referenced,
and this
instruction gets decoded to several
microcode instructions or microbes
on the right. You can see those
at first. We read
the top of the stick and
lotus value in the temporal
register after what's the statistic?
It's stored in the location
indicated by X and
afterwards to take point that gets
incremented.
So we also
just heard that microcode is used
to update
type use that are around us
and that are older than the field.
And this behavior probably is
motivated by the infamous into Pentium
F2F stuck in 1994.
We have certain Intel Pentium processors
would produce
slightly off results for
certain floating point operations.
This was quite a mess, and
Inter had to pay a ton to replace
processors in the field.
So both Intel and
D-Von to to avoid this in the future
and at update ability.
So one example this year
there was this Intel Kaby
Lake bug, where
certain Hyper-Threading behavior
of certain Hyper-Threading conditions
would lead to a instead of existing
behavior. And this bug was
fixed with Michael Code update.
So then we had to
this side also some
bugs. There was an AMD phenom bug
in 2008
that Andreas could not be
coaxed reliably, and this bug was
also fixed of mobile code.
So again,
quite recently this year, there was an
empty Hoosen bug,
which also got fixed by a local code.
So let's now have a look at the
inner workings of the microarchitecture
and how Michael
code is embedded within that.
So, um, and instruction
gets executed on the CPU,
and first
it gets from the main memory to the
caches, and at some point
it gets to the decode engine
and gets the code to microbes.
Then the
microbes are then scheduled, possibly
reordered to the pipeline,
and the pipeline then leverages the
numerous functional units
like an automatic logic unit or at
first generation units
in parallel to actually execute the
multicore instructions.
We now zoom into the decoder and have a
closer look. The.
You have to instruct some buffer that
stores the crew, stream of pilots
and several other
kinds of decoders.
We have short decoders that can
each translate one simple
5:52 instruction to one microchip
and pick them together
and put this pick to get
us into the scheduler.
Then we have the long decoder,
which is able to
translate complex or
more complex physics instructions
to several microchips.
Now we get to the most interesting
decoder, which is the Victoria code on
the right.
This because the contents Typekit code
engine and an
86 instruction that gets decoded
by the vector decoder actually triggers
a small microcode program
to be run in the spool.
And this program may generate
an arbitrary number of microbes
that then gets get used
to the pipeline and executed.
So we just heard
that the NAACP, you and
Michael pogroms are
run. So they need to be stored somewhere,
and there are some onto from
the Michael coat, from the stores to
Michael Coat and basically
all of the Michael Michael programs.
So then we have Michael courtroom
during runtime, the clip.
You can get the microcode updates and
the Michael could update gets taught in
the courtroom that you can see there.
Then there's all kinds of Cocodrie around
to make the whole thing working
for somebody a different unit
that increments the program, control for
the microcode engine and
most importantly, for us,
the match with justice.
They basically provide us with
break points in the Michael courtroom,
and those break points
can be set at certain local court
addresses.
And once
such an address gets executed,
the control is directed to make a court
room.
Michael could update is thought.
This is a very important mechanism for
microcode updates to actually
get control
of things happening happening
in the CPU and
changing behavior like sanitizing,
sanitizing inputs for instructions, for
example.
So how do we actually
update the market code for a CPU core?
Well, we need to be in kernel mode.
We need to load.
The market could update into the RAM.
We need to write the vote for areas of
the updates into the given mission,
specifically just
as the microcode update gets us
gets loaded into the local court room.
Those updates are not persistent.
And once your boot or set, the CPU
is in its initial state again.
So the microcode updates from what
you can see here, it contains
an Hedera of several fields, such
as state patch I.D.
and a checksum.
And this is followed by
the metal sisters, which contain
the contents for the break
points.
And afterwards, the microcode
follows the medical
code as followed.
It's organized and so-called
triads, and one triad
contains three microchips
and one sequence about the microchips
are actually microcode instructions
that execute code, and the
sequence route is
for control flow direction.
So now we want to answer the question
whether this is hackable.
So
we learned it's updatable,
you have opted updated drivers
in different biases and
also the Linux kernel.
So we know the procedure how to update.
We have a glitch in the microcode
updates by the vendors.
They are distributed through bios
updates, but also
has quite a huge collection of them,
you know, to update file format.
And there are hints that there is
no strong cryptography protecting
the integrity of the code updates.
So this is a
hex dump of one of Timoko code updates.
Just want to have a quick glance?
You can see here
a repeating value over and over.
They too often and
a feature color more the use
that the same values, you can
basically see patterns emerging.
So meaning we have no
strong group to apply them,
and we've learned that the CPU
accepts modified updates
if the checks on those corrected.
So yes,
it's a heck of a
um.
At this point, we we knew that
we had to generate
a lot of microcode updates in an
automatic manner
to be able to
trigger behavior
change and from that behavior
change, learn of the inner workings.
So if you build a framework
and the framework
contains a lot of nodes,
the nodes run our own
custom written x86
operating system.
That's very low, nice environment.
So we control all the instructions
that get executed
and the operating system runs on
computers powered by
the processors, so
the nodes are connected to a Raspberry
Pi. We are still together
for data communication and
the use of chip by open source
connected to the CPU set and power
switches on the main boards to
automatically power up and down and
reset nodes.
Because then the nodes
execute random microcode, they often hang
and are not recoverable.
So the whole setup a suitable from the
internet to have remote access and
just as a convenience feature.
So this is what looked like in the very
beginning at our home.
This is what it looked like later at
university.
And now we have
the tools for automotive testing
and we used it for
generating heat maps so
that the name is a little bit misleading.
Let me just explain what we refer
as to them.
Um, basically, it's a mapping
from microcode quote addresses
to the corresponding x86
instruction.
Um, so and
x86 instruction is implemented
in local court and the
microcode is located at
certain home addresses
and the map. Basically, this
fits home address implements what
x86 instruction
generated the heat maps by
iteratively hooking all microcode
combat courses with the break point of
justice and then executing all
x86 instruction.
Um, you
know, so
um, once you have the heat maps,
we can reliably execute our
own bits as microcode
by just setting
the breakpoint just to a
known location and executing
the corresponding
physics instruction.
Then and the controller
gets redirected to
our own microcode updates.
And you can just put random bits and the
CPU into this random puts
a smoker code and executed.
So because there's no documentation
on the microphone
instructions that we basically
had to conduct an unknown instructions,
that analysis this
a black box model because there's no
publicly available assembler, this
assembler compiler or any documentation.
But luckily we had an oracle, the CPU
itself.
We can just fitted inputs and observe
the outputs, and from the differences
in behavior, we can infer
structure encoding and meaning.
So we now have a quick look
at how the CBO overall looks like.
First, we fitted an 86 instruction
and defeated an initial state
which basically contains out of their use
in x86 criticism
and defeated the microcode updates that
we've generated on our own.
The metric system is
a corresponding metric, a good start to
the 86 instruction that we execute
so that the call
ups that are also contained could
update that these random
inputs get executed by the CPU.
Afterwards, we get
an output state
that basically
mirrors the states the
CPI was in after they executed
our random bits, as Michael called.
Very often vendors view
executes random bits of smoke or caught
the CPU for just Chris.
And sometimes we would see no difference
in the inputs and outputs it
after some weeks of
forcing.
Pretty much.
We finally got to end
the string that would not crush
the CPU, and it would yield
a difference in input and output
state.
And this basically was our
early attempt and initial step
for further analysis.
Now, of course, you want to know what
this puts things actually doing.
So what operation is it executing?
And to get that if you start
to to, uh, toggle
bonded by one bit in the string
that we found randomly
and here we change bits on the very
right.
And we saw that the output changed
again.
And after changing
to bits on very right several times
and looking at the outputs and
inputs, we finally concluded
that this between three percent and
X at immediate instruction
on microcode level.
So we then use that knowledge
to build a small
database of opcode operations
and fields.
And here you can see that we determine
the length of the immediate opcode field
and put it there.
So if you change other
bits, like some bits more to
the left,
we get other outputs
and we already know on the Berkeley riots
the immediate field.
If you changed, it mediates
the output changes
again, but it changes differently.
And if you look at the binary
representation of the inputs and outputs
it can, after several attempts
can infer that we found an off.
So after some more testing,
we found that the operation
field has a certain lengths that the
can be seen on the slides.
And this was
basically a starting point.
And we leveraged the framework to conduct
a lot of automated testing
to be
sometimes more randomly, sometimes
less randomly talk of bits
and selected bits.
And the further the outputs
to be interesting so that we only
had to look at a few
set of outputs and interesting
outputs of the CPU.
And Chris, there are changes in behavior.
You also had to manually filter out some
random noise that's sometimes occurring
and then, uh,
after a lot of work.
Don't worry if you can't read it,
we got to this.
So we have quite an exhaustive list
of, uh,
operation fields
that are sometimes immediate, sometimes
called just us or size fields,
and if flicks get propagated
or not and so on.
So, uh, one other thing that
we wanted to conduct is
to infer the logic of Michael quote
from triads, so
triads that are stored in the local court
from the concrete them because they
are in local quota areas
on the tire itself.
So we wanted to indirectly infer
the behavior of some of those.
We first used to break point records
still at the known address
to get initial control.
We would then execute the corresponding
x86 instruction to get
control in our first local court column
stage, and we would
then fry its microcode in our opted
to jump back to my home
to exactly it.
This from a trust that you want to
analyze
it, then add one to this
address and
put this address into another metro just
to jump back to my quote from that room.
So our second ago called REM states,
and this would then output the
um the the
um so that you can compare input
and output state again.
But this time we didn't execute our own
random or less random, but string,
but we executed and local court
prior that stored on the wrong.
This approach has several topics.
For one, um,
the microcode control.
It might just modify some internship,
you stated. We don't know.
So we can't really observe it or
CrossFit.
And uh, another disadvantage
is that the microcode one
triad may not execute
the triad.
It was, uh,
further, but it may just jump some
of its local court room.
In this case, we would lose the control,
but we designed all my courtroom
rom stage to not notice this.
And so people just try
not to control it in this case.
So quite late in a
protect the
decided to give it a try
and agreed to make a quote from
from the disrepute itself.
So it kept
the tip until I got a tip
and took it out.
So it looks like this.
Maybe you can see an increase in
the medical code from areas,
so they take quite a bit of the
sippy you surface.
If he should do a little bit more of a
scanning electron microscope, you can
start to see bits and patterns.
And if you assume an even more,
you can see why thoughts
that are either a little bit more to the
left or to the right.
That means they are either connected to
ground or to the.
And that, in turn, means that this
specific home cell is
representing either one or a zero
reduced optical character recognition.
To get
that, say most of the bits out.
And we could actually, after some
rearranging because the physical layout
is a little bit strange to our software
guys. At least you could
actually find some vocal court's
instructions in there.
It's a challenge, though, to us
to get the exact mapping from
the physical layout to the motor control
mattresses.
So let's pick up our first instant
results will click, so we generated
those heat maps
we found in total 29
local ups.
So these are logic arithmetic
operations, memory load and stores.
We can write to 86 program
counter and we have a medical code
conditional branch.
So we also reverse engineer
the features of the sequence vote,
for example, that can be used to just
execute the next try it,
it can be used to signal
the sequence complete, which means
that the decoding of the current x86
instruction is completed
and that the next x86 instruction
will be executed.
The sequence it can also be used to
prance in local code unconditionally.
Then we also found the substitution
engine and the substitution engine can
be used to automatically
put on
operations that are in the exact physics
instruction to the microcode
instruction so that an
X in physics
instruction would automatically
be X and then the
A code instruction as well.
This heavily simplifies
the implementation of x86 instructions
and local code.
So we also want to document
x 86 instructions.
Until now, we can just, uh,
replace the logic of the
x86 instruction by
setting a breakpoint Colchester to the
entry point and I
on Michael code.
But we also wanted to extend existing
logic and preserve the autonomous
romantics, and we can do that by
either jumping back to Rome
to execute the alternate triads
or for simpler physics instructions.
You can also emulate instruction
logic ourselves.
And there are some examples.
So
once you reverse engineered the
x86 microcode
instructions or some of it,
we started to implement our own local
code programs and
the first part of your program that you
wrote isn't simple instrumentation, but
it's just a proof of concept more or
less. It's pretty
much just in local code columns
how often this certain x86 instruction
was executed
and that instrumentation that we
implemented as a small framework
that allows to hook x86
instructions and redirect control
to an arbitrary function
that's implemented and see, for example.
If also implemented some remote microcode
attacks, so given
back towards
the CPU that has the big to implement
at the local court.
If the computer visits
a website,
it may it trigger the
detector and the implemented
sample websites that
can trigger that to microcode vector.
And we have two versions
available.
One is implemented is Morris
and one the state assembly
will also implement some local
programs that contain
cryptographic trojans, so they
are harder to detect
and to make a code.
The cryptographic like Trojans either
introduce the timings I channel in the
constant time the implementation,
or they allow to
inject false to enable
foiled attacks on
a cryptographic primitives.
So now we want to have a quick
look at how that medical program
looks like, um,
the Michael program has given
in our own
focus of control of a language that
we developed to implement
local programs efficiently so that we
don't have to put together
long streams of bits on our
own.
So the first instruction you consider
this is abstraction that's actually used
as a computer.
So the value in T1D,
which is the medical code internal
Rochester, is compared
to the value in X
after what follows a conditional jump.
And if you want to first consider the
jump not to take in Perth,
that's here.
This is just a
bit of instruction that
set up an integer division.
And here we see in the
very last instruction that we jump back
to the macro quote from.
So what's happening in this case
is that we mimic
the setup of an integer division and
then we jump back to the original triads
and run to just continue the normal
integer division process.
Now we consider the jump taking
perf that only gets executed
if the value in
X matches the value in T1D
in this specific case.
Um, we add one
to the polychrome contour and
then we write this
value to the 86 program
counter. So this basically means
this model code spectra, if you will,
would compare it to a certain
metric value.
And if that's what the metric value was
found, then the x86
program count of the incremented by one,
which means that all of the successive
86 instructions to be
executed out of out
of alignment or this aligned.
Um, this is a very useful primitive
that can be used for, um,
JavaScript exploits, for example, without
the presence of a close up look.
So now it's
time, and I'm handing the stage to
Benjamin.
OK, so.
First of all, I have.
If you see this means that this warning
and autumn deceive you.
And it's actually as if we can target
with all my programs.
And at first, I'm going to want to walk
you through with Hawkins that's actually
currently loaded inside to see if you and
I both at your standard Linux on it.
And yes, it's
just some micro protector.
And first, you load the values that you
want to trigger on and then
performs on magic to condense it down to
one bit. If you actually trigger this
value and
the actually the actual
magic happens to you,
you eat out what is written inside
the buffer in memory.
And was this important?
You'll see it in the second.
When I show you the actually payload,
we're going to one.
But essentially, you read out
my movie and place
it inside
a timber register and performs enough
metric on it.
And
then you implement actually as the actual
semantics of shift to a double, which
is an x86 of code.
And you do this because
if you are talking about you didn't
match, you don't want to.
You don't want to cause any trouble
because some sometimes the common
might use this instruction or some other
application on your host system modules.
Use this instruction.
So it is important to preserve the
semantics if you don't want it to go back
to.
So at this point,
we know whether or not to trigger and.
We can do it, we can now
conditionally at some values to adjusters
or otherwise modify them.
And we do exactly that.
And at first we is that
said, six to 11, which happens
to be the execute useless call on
line ups and
send you set some other adjusters
that we need to actually launch system
call. This augments we control.
And you
do this for would be just us.
And in the end,
you conditionally white the program
count to a specific value you give
them, actually, and you have a payload.
So is a JavaScript payload.
You can choose where you want to go.
And so this all happens conditionally.
It only triggers if an
input to the instruction matches or met
a constant.
And how did we achieve it?
This is was somebody module and
a carefully crafted some
calculations that contain this aligned
x86 instructions.
And as you can see, we end
with an interrupt into a corner
so we trigger and execute your system
call.
And the buffer we're reading from is
sure John Hume.
And essentially,
we just say, please pop us a call
and.
This is an animal unmodified Firefox,
and I haven't I haven't added any
new code to it, and it's not running a
vulnerable version, as far as I know.
So I just calculate.
And because of that such a debacle, are
you going to break you in the second?
Need to wait a bit, because OPEC is
actually really slow, especially if you
are directing Firefox.
And so we go and I'm just gonna
step some instructions that are part of.
So who can you to to sit in order
to get that trust I want to go to?
And now we're inside insights of possibly
module, I showed you earlier this all
code that is emitted by Firefox during
one time, so an attacker is free to
choose what should be emitted by
providing the appropriate WebAssembly
module and.
As you can see, this execution
of our shift, right, dear opcode,
and we actually back towards this one.
And
what I had took special care of is
placing
our constant inside an argument we could.
So actually object of a trigger.
And because she
is going to lose control in the second.
I'm going to cheat a bit.
And I know that we're going to jump
six points more so just at six.
And press continue.
And we had this client inside
instructions.
And as you can see, you perform
all the things we actually coded into.
Make records to prepare the documents
with justice.
And if you
if you compare, it was the episode the
output.
I said, please, Mrs. OPCODE,
followed by a jump five and pre-summit.
Lastly, these two up coats and
squeezes of coats we have, so
let's just continue and hope it works
this time.
And of course, it didn't.
Let me just quickly you on it also the
opportunity to be.
And so you're going to get stuck.
And as well research, we can
also implement some cryptographic
backdoors and because we need to reboot
for the story. I'm going to show you the
notes. We're getting codes first.
So we have here and we
have a standard signature verification
and it just a political job because
everything is fine.
But now we're going to
quickly apply the picture.
And request a custom kill them
because we need to somehow mobilize
update.
And why is this actually reboots?
I'm going to show you a different e-mail.
I have
this console is actually going to push
as Group two of us blue Pine Country
sitting in the binary assembly in the
studio. And this is
connected, we assume, to an AMD
note, and
this is going to undermine a quote we
tell you to run.
And first, I'm going to show you
what happens if I just say, don't hook
anything into microcode,
so you'll just go ahead and say one word
and.
So just as you should pay attention
to is
currently it's over, because I didn't
I didn't change anything.
And now I'm going to
say, OK, that's good.
And suddenly something changed.
And what changed is
this is a microcode approach to the CPU,
and all it does is
push the next x86
instruction and will be executed
and stored on the
stick and then just jump to
a location I predefined.
And this location ends
up all the way over here.
So we actually get control in x86
without having to hide any like
program rewriting stuff.
It just works.
So there's also something we
can do. We can introduce like micro
code hooks and actually
he finished booting. So let me quickly
set up and see again.
Second.
OK, so again, we the APC,
but this time you voted a different
update, for example, is this update one
triggers a back to be placed in Firefox,
but instead you're going to run
the crypto demon yourself before again.
And suddenly it's a similar signature
because we introduced an error into the
calculation that is performed, doing the
ecliptic calculation
and using this,
you can actually perform the
cryptographic attacks
and
just a bit of theory.
I introduced and
cryptographic
witness into an otherwise secure crypto
by introducing an arbitrary error
and using this, you can reconstruct
material, and all of this
is done in microcode alone.
I didn't need to modify the final
result as one thing.
So that brings us.
True security issue, I said actually a
crew of ISS set up
your car and you can push any update as
you saw. I mean, I modified the live
picture to see if you accepted it.
You can picture it as you saw and
you can't really fix it because you would
need to do an hartfield card to introduce
some people on cryptographic checking.
And of course, you can
hack. You fix it.
You just accepted mechanism
or.
But in the end, it isn't that bad because
you only have a really strong attack on
what someone had to actually modify
your bios to apply this on every boot up.
So usually it isn't a problem
for you.
And in the end, yes, my
company like A can be reversed and
you can change it.
And if you want to talk a bit more about
it or even try your hand at modifying
microcode yourself.
Visit us to kill US Europeans
by new security assembly.
And we have a set of results, including
the CPC and an old curtain that
you can push it live at once.
So angry with us.
And also, we pushed out some updates and
we go to him if I was to get up,
including an update wherever we can pitch
your own CPU.
But please be careful.
This can actually break us if you ever
did manage to play ours, but we
eventually set our bios settings at some
point. So please be careful.
And.
So now we have time for questions from
the audience, you see microphones around
the arena with numbers stuck on them on
the internet. We have a signal angel who
was already telling me that we have
questions from the internets.
Before we get to the questions I said in
advance, you may be asked to leave the
hall entirely when going
back. And now I'm asking you that when
you leave, please leave entirely and
reenter the hall through the main
entrance, not the hall, but the whole
message here. So now from the signal
angel in the internets.
Thank you. We had a question that came
up quite early in the talk.
Is it possible to cause physical damage
to a CPU using malicious
Michael Colt has either
of you, you know, ever brake to stop
you?
Yeah, we didn't break any CPUs
apart from the ones we to and
we kept to put into Micron Electron
Microscope, and maybe
it is possible we haven't managed it yet,
but the the design
of at least the AMD we analyze doesn't
look like you can unless there are some
feature inside microcode that
you can trigger. We haven't found it yet.
Maybe it's possible, but most likely
doesn't.
Microphone techs?
Yes.
Is it possible to fix performance
issues with microcode?
So we've thought about
that as well, folks on
before binary instrumentation.
There are several different approaches to
that. You can emulate
the codes like
Vulkan String, for example,
or you can instrument the code
statically.
But they all have like topics
like either they are slow
or they are not complete, like the static
flooding, for example, at least not
complete in general.
So Michael Cole can actually be
quite performant and complete
instrumentation
basis that an instrumentation framework
could be based on the
problems of microcode.
Or is that at the moment, it's quite
limited because for newer
and DCP use and pretty much for all
intensive you microphone is closed.
But maybe the
CPU vendors will open it up a little
bit and then it could be used
to to increase performance
for instrumentation frameworks.
It can also be used to
implement new instructions.
But I doubt that it's going to be
very fast.
And if you just implement x86
instructions
microphone one.
Yes. Have you looked at the
older Intel microcode
updates as well?
Because if you look at them, they are
like encrypted, but it's
clearly not strong crypto.
It's either a constant stream cipher
or
a small
block cipher.
So because also I have
previously succeeded in actually loading
patched microcode updates that
I've been able to control the contents.
But so clearly the verification mechanism
isn't very strong either.
So, OK, if it didn't have a close look
into the into update,
but that's a very good question, and we
should probably have the discussion
offline. So
feel free to visit us at 270 and then we
can have a look together what you call
the microphone to.
How accurate is it to refer to
the microcode as
a risk architecture rather than
SysRq? I mean, are there any instructions
in there you wouldn't typically find
on on a regular risk
architecture?
So the question
was better, veterans use construction
sites like architecture,
so I can agree on that.
Um, the instructions
are mostly quite simple.
One quite interesting feature, actually
is that you can have three
upfront mode that you can give three
registers and you can have one
destination register and to source
suggests it is not possible on
x86. As you all know, probably,
but it's possible that microcode level.
So it's quite interesting.
Hmm.
Back to the signal angel.
Thank you.
How do you know the microcode entry point
for a given instruction?
That's a very good question.
We showed you the heat maps and
we generate them by
basically setting the breakpoint at each
possible code on the address
and then just trying all x86
instructions.
And obviously, sometimes
people have multiple hits for one
eighty-six instruction because
not one at first is enough
to implement the whole x86 instruction.
And what we then can do, we have eight.
That's the good stuff. So we can set
eight break points at once
before just that eight
break points at those different locations
and see which one gets triggered first.
And so if you could actually step by step
debug in which order
code ROM addresses get executed
to implement an x86 instruction.
And so we way you also find the
entry point.
Microphone three.
You said that there was microcode
updates are not persistent across reboots
right across processor is
it doesn't mean that when
vendor issues a microscope update,
it is actually a program
and patch to a bias that should
install the update on every
reboot, even a boot sequence.
Right?
Yeah.
So the CPU vendors, they
don't publish those market updates, but
they put them or they give them to the
main. Both vendors and vendors
usually put them into
bios or if you updates and
those updates don't contain the microcode
updates and do Computicket instead.
Also, there actually is on Linux
into microphone package and this actually
performs.
I would update on every boot.
And I actually hijacked its drive on to
perform our custom update.
So depending on the US, you are wondering
who is going to form your bios or you get
it from your operating system?
Microphone for
I wanted to ask,
you mentioned it might be possible to use
a crafted Microsoft
microcode update to actually
patch out the update mechanism?
Or how do you think it would be to
to implement
to implement that inside, say,
boot and make sure that
the other microcode update mechanism
is patched out very early
on in the boot process?
So this would actually be quite
easy to do.
It's the first, some
obvious engineering work on our site,
but through the heatmaps, we already
have quite a good understanding.
We have to make code. Update mechanism is
probably going to be because
once you set breakpoints down,
you can't apply code updates anymore.
Um, so
it would require some work there, but
then it would be quite easy
to just have a
microcode update mechanism and be
prepared and in the boot
disabled update mechanism.
Thank you very much. Mm-Hmm.
Signal, Angel,
can you use this trick
so that the CPU is revealing any secrets
e.g. keys out of secure
enclaves like TPM,
like entities in the CPU?
Probably not, at least not named.
But we can't really tell you with a
definitive answer to that, because I
suppose we can carry on or don't have an
secure enclave, so we didn't test it.
And what we actually
observed is that the microcode follows
the same permissions that the code that
actually trigger to make a code.
For example, if you have an
IMU and the
microphone actually follows minimum
protection toolset.
So most likely, no.
But maybe you can take it
microphone to.
So you said you have
trained him on microbes.
Do you know how much of
the total space
that supported this?
So do you think or some microcode
instructions you didn't find out also
told us.
So it's very, very likely
that we didn't find many
of those instructions.
There are still
certain regions within the
local court instructions that we don't
understand. And if you talk with them,
it crashes or the behavior.
It's different and we can't
tell what operation it's
doing.
Also, we can't just observe some of the
court justice and you can't observe
all the intel in the workings of the CPU.
So a lot of
instructions that's modified
at Intel instead of TTP, you let's say
it's enabled or disabled certain
features.
What enables and disable certain slow of
hers perf for some
features, be noticed
it and
do it so that we can't,
uh, we don't know what
the instruction is doing, what the
bitstream is doing, testing currently.
So probably there are many instructions
we don't know.
Microphone one.
Have you considered ways to
say my if my
microphone is being backdoored to
detect that?
Can you can
you help me in that situation?
Oh, OK.
So, um, during
our research, we didn't have a look
into this yet,
but we already had some internal
discussions regarding this point.
That's a really good question.
So, um, if
you if you use microcode
to hook an 86
instruction, you introduce a
small timing overhead.
And if you carefully measure that
instruction, you can probably detect
that suddenly it this
x86 instruction is doing more than
it should actually do.
So you can detect most of it.
Um, but it also depends.
Microcode is doing not only decoding,
as you've seen in the talk, but also
other things in the CPU.
So you might be able to hide
trojans there that
are not detectable that easily.
Microphone two Again, OK?
Considering that you can basically
implement instructions, could
you implement a completely different
instruction set?
Yeah.
You could do that.
And I showed you in the collected
work, the
tubas talk from the recall
and, uh, he's actually doing something
like this. So, yes, it's possible.
Um, we are still not
far enough of our knowledge to
do that, but he is feasible.
I think he has some
internal insights.
Microphone to OK
took us to was actually the first is,
have you found any ways to trigger the
co-processor static sex?
X86 has plenty of.
So let's say,
a floating point unit and another
extension extensions, right?
It didn't look into that, but
from the patents, we know
that there must be some way to do it.
Hmm.
OK. And second question this
after decoding the isn't there those shot
operations just showed.
Are they not going to this
up cache and throws make up decoding
and they're directly omitting those
instructions?
So are they safe in my code and cannot
be altered?
So the short decoders
they translate simple x86 instructions
and um
um, we we know
that there's also a way to
hook not Michael coded instructions,
so they are not safe.
We know that this mechanism exists, but
we didn't find it.
It might
be a fun one.
Hey, maybe you said it, but
I missed it. But did you contact
into did
you get any feedback?
So we did not
contact until we
contacted MDA.
Um, this work is
also published on Unix, and
they longer than 90 days before
the symptoms took assaults
and the findings and
asked for feedback.
They didn't communicate much with us,
probably because they already have an up
to date, um, secure,
more or less secure. We don't really know
about Tom Krypto
protection mechanism for making put in
place for the latest CPU architectures.
So we are probably not that interested
in this. Mm hmm.
All right, great. Let's give our speakers
another big round of applause.
The.