Okay, hello and welcome to this talk on how secure are commercial risk 5 CPUs.
So we will answer this question today in this talk, but let's first introduce ourselves.
So this is Lucas, I'm Fabian.
We are both PhD students from CISP and Germany.
We are basically a big research institution.
We do cyber security research and publish that at academic conferences.
And yeah, with that we can already hop into basically CPU vulnerabilities.
So what do we have there in that space?
And you might know these two meltdown inspector, they were discovered in 2017 and then disclosed
in 2018 to the public.
And after that, a lot of other CPU vulnerabilities came to light mostly on X86.
But then at some point people also discovered vulnerabilities on ARM as well.
And this is still trying to field where we do our research with vulnerabilities, even
a stackwork.
We also publish that one, this one, few might have seen that as well.
Now the question given that X86 and ARM CPUs have these vulnerabilities, the question
is, with first-clive CPU, which is a new standard, with new CPUs, can we learn from the mistakes
that were done on ARM and X86?
So can we design a secure architecture from the start or will we repeat the same mistakes
both in the architecture, so the design and also in the micro architecture.
So what is actually implemented?
And we want to structure that talk basically in three different areas.
So we'll first talk about side channels, on-risk-5 CPUs, then we will talk about actual
CPU bugs, and then in the end we will also conclude with transit execution attacks.
And with that I pass it over to Lucas, who will talk about side channels.
Then let's start with a real side-channel classic, which is RSA, square and multi-plight,
to get to know what a side-channel is.
Maybe you can raise your hand if you know what a side-channel is and how it works.
There are nice already, many, many, where the first people here.
So square and multi-plight is really classic example of a software side-channel, where in RSA
you need to do explanation and because explanation is expensive, you do that bit by bit,
with a nice modification that is called square and multi-plight, where your explanation
basically gets shifted each time and you do a different operation depending on whether
that's one or zero.
And this is very bad because you do a branch in this operation and this branch can then
be observed by an attacker.
And by observing the attacker, the branch, the attacker can directly determine whether you
exponent is zero or one and if you know RSA, you know that is very bad because that allows
the attacker to basically then decrypt arbitrary messages.
And how would you leak this?
Another side-channel classic, a flush and reload, which does this by a shared memory.
So if you assume you have descriptive library, it's somewhere in shared memory, right?
So this branch that you attack lies somewhere in shared memory that both you and your
victim can access and when the victim accesses this branch, it enters the cache, right?
So they are both accessing shared libraries, the attacker and the victim and when they
access it, it enters the cache.
So what you basically do is you get rid of that code first by flushing it.
There's usually instructions that do that, very convenient for side-channel attackers.
And then the victim runs and depending on what the secret is, that either caches to
line that you want to cache, or caches to code that you want to cache, or it doesn't cache
to code that you want to cache.
And now you have a controlled cache state.
And afterwards what you need to do is you would need to exit right this cache state and
you would do that by accessing the shared library.
And if it's fast, then you know it's cached.
And if it's slow, then you know it's uncaged and the victim didn't access.
And so let's basically think about what were the basic requirements for this attack.
So you need to share library, you obviously have that with your crypto library, you need
to flush.
So you need some way to get stuff out of the cache.
And we will see whether that exists on a scribe and you need a timer.
And this timer is exist on a scribe and there's even quite a lot of them.
So the isom end-aids that there needs to be like three timers that are available, there's
like are the time which is a little bit interesting to us because it's really slow when
the fast timer.
So there's are the cycle which causes fast as the hardware cycles go, which is nice.
And then there's even something that counts retired instructions, which we will see is even
nice because you can do even nicer text with that.
And they are all high resolution and they all should be accessible from user space.
So for a attacker that's really nice baseline, right?
And in case maintenance, it looks a little bit dire on risk files.
So there's like no flush instruction in the base ISR, there's only fences.
But there's cool two cool tricks in risk files.
So first of all, there's these tiered cores and they thought like, hmm, so this is the
core that you basically saw before and the Kubernetes talks and they were like, ah, how
about we implement this for core, how about we make it unprivileged.
So you again have this flash clear full control over the cache, which is nice for an attacker.
I don't know who has used a set in user space, but where it's there now.
And then there's also the fence eye instruction, which doesn't say anything about the cache.
It's there to synchronize the instructions to them.
But a very easy way to synchronize the instructions to them is just to flush the cache.
So all of the vendors do that.
And yeah, with that you also gain a very nice cache files, even though the ISR does not
say anything about maintaining the cache.
And with this, then you can build a lot of attacks.
Another classic one is the AST table attack, and a nice feature about the IST table attack
is that you see very easily if it works, the only thing that you need to know is if this
diagonals very clearly visible, then you attack worked.
And you see here one example in x86, then you see another example in risk files.
And all those of make need to better because the risk files cause a very nice free and
have less optimizations right now.
So you don't get so much noise in between.
And yeah, for other sites, you can even have like new stuff there.
I said before, there's this ID cycle and this instruction retired calendar.
And what you can now look at is basically the data between those two, because there's instructions
that take more than one cycle, right?
So for example, if you have a division, a division can be like very belatency and a division
is also longer than one cycle.
So you get more information and just looking at a cycle calendar.
By doing this, you can basically identify via the data parts in the code where heavy instructions
are run and the turned out that, for example, during interrupts, more heavy instructions
are run.
And so you see these peaks here where the data changes.
And so that allowed us, for example, to monitor interrupts also in the kernel.
And the count has also worked across all modes.
You can monitor interrupts in the kernel.
You can also monitor the instruction code stream in machine mode, that's your thing.
And this allows you to, for example, finger print interrupts, which is an interesting
attack, because, for example, when you press a keyboard, this also sends an interrupt.
And between your keystroke timings, there's basically a different latency.
And so in a take I can from the keystroke timings, then reconstruct your key presses.
And there's a lot of attacks on this, like there's a lot of fancy interesting attacks.
This is not new to risk five, but it's an interesting attacks scenario.
And so to summarize, on risk five, we have like accurate timings, we have even more than accurate
timings.
We also have this, like, look at the retired instructions, get it.
But luckily Linux reacted the way back.
And these timers are now kind of disabled in user space.
You can still reenavid them.
There's the ways around it.
But most of the day limited to the perf interface, which in our opinion is where these timers
should, like, be accessible.
And cache maintenance is unprivileged on some processors.
There's this fence, I instruction, which flashes the entire instruction cache, which is,
like, implementation detail, that is there now.
There's also these custom instructions.
Yeah, so there's also a lot of cache maintenance stuff there.
And even if you wouldn't have that, there's ways around all the stuff.
So the baseline stuff is quite similar between X86 and RISC.
So all the attacks you could mount before you can also mount now.
Okay, yeah, thanks Lucas.
So this was basically side channels.
And if you ask me, side channels will always be in our systems.
You can mitigate them to some degree by writing constant time crypto, for example.
But they will always be there.
So now let's talk about actual CPU bugs, where the CPU basically implement something
differently than the ISO dictates, or has some other kind of bug.
And until now this research was mostly manual.
So you basically read the ISA, you read the hardware manual, you do some manual experiments.
But we wanted to see if we cannot medically find such CPU bugs.
And there's a nice tool for that in software world that is fuzzy.
But turns out you can also apply that to CPUs, even to silicon CPUs.
So how does that work?
We basically buy RISC5 CPUs, so for example, the tiered cores, then also the space
with cores or the SIFE cores.
And we connect them here the network.
And then we basically ship programs to all of these CPUs and see how they react to that.
So that means we send a program and instruction sequence.
We send register content and also memory content.
And then we observe what happens when we execute this program.
We collect that, we compare that, this is called differential, fuzzy or differential testing.
And we do that with a lot of inputs like you would do in the software world.
And then at some point you might spot a difference.
For example, this variable I is now different, this could be, now a difference in a register
or a difference in memory.
So with that, we uncovered a lot of nice bugs on these RISC5 silicon chips.
I first want to talk about denial of service.
Here you might remember this Intel FOOF bug, which is basically a bug instruction on
Intel CPUs that just that lock the CPU, so that means you have to unplug the power cable,
plug it back in, and the CPU comes online again.
But obviously this is bad for a cloud setting where you have multiple tenants that could
just crash the machine for the cloud provider, or at least for basically the other guests
that are running on this system.
And we found something very similar here on one of the tier costs, the CNO6.
So you can basically run this instruction sequence with this weird tiered L-bip instruction
on your CNO6, and it will just hang.
So as I said, you have to unplug power to bring it back online.
Now the question is, why does that lock up the CPU?
We also asked us this question, because it just came out of our fuzz and campaign basically.
And then we always don't know what happened there, because we didn't write this assembly
code, right?
So we looked at this instruction here, this tiered L-bip, and it's not too special, basically,
that's a normal load with an index load, and afterwards it also increments the address,
it loaded from, and there's one interesting detail here that you might have spotted
the tiered bottom, it says the encoding of this instruction with equal Rd and R1 is reserved.
And if you read something like that, a security researchers will definitely try this,
because I mean you should not use it, they tell you that, but from a security domain, this
is exciting stuff, you always want to try that.
And yeah, turns out, if you do that, if you use one, it can be any register, we just use
T0 here in this case, if you use the same register there for us, one, and Rd in this instruction
encoding, and afterwards do one register, CSR read on this register, and one other instruction
that modifies this register, then you basically lock up the CPU here.
And now this is nice on hardware, but we wanted to know as this, now fuzz expark, or as
this synthesis spark, and for that we looked at the RTL source code.
For the CNO6, we have the Open CNO6 repository with the RTL code from tiered, so we can
actually look into the source code of the CPU, and we tried it there as well, and as you
can see, basically, our simulator, which in this case was very later, tells us that
the simulation failed at finish, because there were no retired instructions in a few seconds
of simulation basically.
Now the question is, okay, the CNO6 is buggy, what about the other cores?
Well, on the CNO8, we also found an instruction that just hangs the CPU, it's even easier,
it's just this encoding here, which is basically an illegally encoded vector instruction,
we don't really know what it is, it just falls into the vector extension basically, and
also on the space mid-X60, if this instruction here, which also just hangs the CPU
basically.
Now, the question is always, in security research, what do we do now, what are our mitigation
options, so how can we prevent this?
And for the CNO8 and X60, the story is kind of nice, that we can just disable the vector
extension in the kernel, that prevents the denial of service, because then if someone just
runs this instruction, it's a guild, so it can't hang up the CPU anymore.
Obviously, that gives a performance loss if you use the vector extension in your workload,
it completely breaks vector dependence softwares.
For example, this is nice of a epic version with a handwritten assembly code, basically,
vector assembly code, just doesn't work, you have to recompile that and use another software
there.
On the CNO6, it's not as nice, because this T-advino extension can just not be disabled.
The documentation there again tells you this bit, which basically tells you the extension
is there, it is enabled, should not be cleared,
so should not be unset.
And the behavior of clearing this bit is also undefined.
Again, undefined is interesting,
so we try it, but if you try to unclear this bit,
if you try to clear this bit,
basically nothing happens.
It's always on this extension.
So that means we have no non-medication
for the scene, 906.
And yes, this is already nice.
So we can basically crash machines here,
but what about other bugs?
Can we maybe modify memory to some degree?
And that's where we found Gostrad,
which is also on the C910.
I just hope before in the live demo,
one of the most performed tiered course.
And to understand what Gostrad is and what it does,
we quickly again have to look at vector instructions.
So I guess most of you have a basic at least
understanding of what they do.
Just a quick introduction, if you don't know,
this is basically a vector store operation.
And what it does, it just moves more data at a time,
two memory.
So instead of moving forward or eight by let's say,
it moves 16 or 32.
So this is what this instruction should do.
So it should move data from the registers
to the virtual memory.
Now the question is, what happens
if you execute this instruction on the C910?
We did that, other did that basically.
And what we found out that it's sometimes
or somehow changes physical memory.
And sometimes also crashes to machines somehow.
And we looked into this and apparently this instruction
here, at least this illegal encode vector instruction,
basically, skips virtual memory and just
rides to physical memory directly.
But it only changes one by it in physical memory,
even though it's vector operation.
And basically, what we think happens here
is that basically in the instruction moves
values from registers into memory.
But every time it only rides one by it.
So if you see what this would look like here,
it would basically just ride the first bite of each of the vector
registers and then only the last vector register
would be in physical memory.
So we can now ride one by it at a time
into physical memory.
And why is this security issue?
Well, look at this.
This is normal rides, so normal storage instruction.
You typically start to virtual address.
That virtual address is then translated
by the hardware to a physical address.
And in that flow, the permissions are checked.
So it is checked that the application is not writing
from process A to process B or maybe even from one
we have to another.
And then only we can ride to physical memory
or the hardware to does that for you.
With cost ride, this looks like this.
So we just ride from user mode process
from process A to physical memory of the kernel or process B.
What when we now do with that?
We have multiple exploits there in the paper.
You can read up on the details there.
But what we can do is basically
we can change our own page tables.
That means we can read arbitrary physical memory
with this instruction.
We can override the kernel.
So we can just change the way the kernel functions
at runtime.
We can even change M mode firmware here.
So we're talking about something like OpenSBI, for example.
So all these protectors also gone.
And that also means we basically
can't do trusted execution on this chip anymore, which
is kind of sad.
Now the question is again, why is this now a big security issue?
Well, we first have the demo, sorry.
So you can see we are now on the C910 here.
And we are an unfrivileged user.
We run our exploit.
And it's very quick.
And afterwards, we are basically the root user
and can run arbitrary commands here.
So this is now just patching the kernel,
to get your Adysus code in that case.
But you can do arbitrary other text here.
And yes, you can basically also do that in the cloud.
So you've seen that before.
That's where basically, month or two before we
discover all stride, they basically
launch their battle risk five instances.
So you even have to see view back now in the cloud,
which is, again, sad.
But yeah, this is basically a demonstration of this little
ghost trial to reproduce here.
We also have to get up real quick for that, which
shows that it works here on the scanwork out on this C910 chip.
Now the question is again, and also as the cloud provider,
what can we do about that?
What are our mitigation options again?
Yes, ghost thread is again, a vector instruction.
We can just disable vector extension in the kernel.
That blocks ghost thread because then it
signals because then an illegal instruction.
That obviously is again, perform, gives it performance
loss for a vector in a task.
And also, again, breaks software that
relies on this vector extension.
And in this case, you also require trust to kernel.
You as a VM, for example, on such a machine,
you would require that the hypervisor makes sure
that this vector extension is never enabled for any other person
on the system because then the person
could use ghost thread again.
And this mitigation is in fact also deployed
in the Linux kernel.
So if you have a kind of recent risk-5 kernel,
but also in x86 kernel, you can just run LSEB
on your laptop, and it will show up there as ghost thread.
In this case, this is from the C910.
So we need to mitigation.
It is affected by ghost thread.
And that's why this XT-head vector extension is disabled.
But the only real fix for this issue
is actually replacing the CPUs.
So we basically need to fix the bug in a new revision
of the CPU that then fully fixes ghost thread.
But that is obviously expensive and slow to deploy.
And it also requires a hardware replacement.
So you also basically need to buy new chips.
But it has that it's the only real fix.
So it's always basically the struggle in security research
that you have the straight off between short-term software
and a mitigation kernel patch versus the long-term fix
where you would actually have to buy these new CPUs
with the new CPU revision.
And with that, we can wrap up the CPU bugs part
by then going over what are the patterns from our findings.
What can we improve upon in the risk-5 silicon space?
So first of all, I would say,
when I should improve their DV-screen security,
because hardware is not software.
You can't just deploy a software patch.
When hardware is in the field, it can't be patched anymore,
at least not in this case.
And that's why this very fabrication is critical.
And we have shown in our research
that differential testing across Windows can be a good tool there.
So hardware Windows should try that and should put it
into their testing technique, basically.
Then we have seen that one problem with risk-5 silicon right now
is that there's just high diversity.
What we mean there, basically, that Windows
they either have their own vendor extensions,
or they implement some old standard of the vector extensions.
For example, T hat has this XT vector extension,
which is kind of vendor.
But it's then also kind of similar to the 0.7.1 vector extension.
And then there are also fights around that.
So we don't like that as security researchers.
You should only implement the ratified extensions,
because that also makes it easier to test those.
And if you use vendor extension, if you need that,
you should use it carefully.
So also in the design.
What we have seen with this R1 and RD,
which should not be the same with this XT hat,
and that might be X extension.
And you should always mandate a specific behavior
in the risk-5 ISO, so there shouldn't be basically instances
where one chip does one thing or one the other,
because that also makes different testing.
Much harder, which we can also discuss after the talk.
And then another pattern we have seen here
is that a lot of this hardware is inconfigurable,
and this shouldn't be the case.
If you have features like this,
vendor extension from T hat,
these features should have kills, which is.
So if you find a bug in those, that you can just disable them,
like we did for the vector extension.
And we argue that there should be some instruction-hooking mechanism,
but that we basically mean that the instruction can be hooked.
So if the instruction is executed,
it either goes into the kernel, so the kernel can do something about it.
For example, say, okay, this instruction is illegal,
we should not execute it, or, and that is the second point,
there should be some update path around it.
So for example, Arm and X86, they both have microcode,
which is basically firmer that runs in your CPU,
and you can just deploy fixes to that.
So for example, for the stack war vulnerability,
that we had on the first slide, AMD could just deploy
a new firmware update, and by that fix the vulnerability.
And we argue that microcode is good thing here,
that it increases security, even if it adds complexity to your core.
So I know risk-fi should be simpler, and risk,
but still, I think lay awake, we can basically push updates
to the hardware, would be a good thing.
And with that, I give it back to Lucas.
Yeah, thanks. So we talked about side changes,
we talked about CPU bugs, and now we come basically
to the last class of the abilities we talk about,
and this is going to be trends in execution.
And we're going to focus not on the back class of trends in execution,
which is meltdown, but more on the side channel class,
of trends in execution with the specter,
in a sense that it's like a feature of the CPU more than it is a bug.
So if you have an out-of-order CPU, you probably
are going to have specter.
And so yeah, we also thought about what happens with these other CPUs,
and the expert is already running.
I'm going to explain you what you're going to see here,
because it's over so fast.
So we also did some research on specter,
and we managed to build an exploit,
and the gadget that specter basically gives you is,
you get, in the classic sense,
from user space and arbitrary read in the corner,
and we managed to build that in a very stable way
by using basically some, yeah, unfixed path in BPF,
that only exists on risk five.
So what you can basically do is you inject arbitrary BPF code into the corner,
that, or like, especially BPF code into the corner,
that then reads where it shouldn't read speculatively,
and codes that into the cache.
And if you combine that, then you get an exploit like this,
which this is running.
So this is the real-time recording.
And in this time, can basically leak your entire ETC shadow fire,
which is not very nice, and can also leak arbitrary other fires,
which is also not very nice for security read.
So the insight is that risk five,
cause they're now out of order.
They're also vulnerable to specter, of course,
and the kernel acts a lot of mitigations
that you would have on x86 and arm.
And part of this is due to kernel oversight,
but part of this is also because risk five does not have mitigation,
that other architectures have.
So after specter was first discovered,
x86 and arm were kind of quick to standardize this speculation barrier,
which is basically an instruction that tells your processor,
hey, here you cannot, like, front run use instructions anymore,
you need to stop your speculation,
and risk five has nothing there,
which is kind of understandable,
because they are like, we're in order, of course, right?
But it's kind of required now in this standard,
and they are coming along, and there's the will, I think,
to standardize this speculation barrier,
but I think it's quite important that risk five pushes for this now,
because the kernel is already relying on it.
For example, the bpfj, it is relying on it,
and there's this really nowhere around it,
like you lose out on security if you don't have this.
And luckily, there's right now work around,
because if you read a CSR on risk five,
that's also serializing another course very tested,
so you can basically read this time register to, for example, 0,
and then that just serializes the pipeline,
but this is a really, really bad heck, right?
Like, in the future, some CPU vendors could say,
oh, well, if I read this register to the 0 register,
then I'm obviously not intending on keeping the reside,
that's okay, it can just drop the instruction
and up on reading it, all right?
So you could come out with a ton of things,
where these like undocumented stop-gaps solutions here don't work,
so the risk five needs to speculation ends,
and the risk five also needs kernel patches.
And so there's a few paths in the kernel,
where it just doesn't work now with respect to security.
So, for example, when dispatching a Cisco,
and I take a quick redirect to speculative control flow
to some arbitrary point in the kernel,
where they want to redirect the control flow,
and that's not nice, because you can place some get it there,
and then basically it will exploit Rob style,
but in speculation, yeah, the user memory access
has something that is called point-on-asking,
which basically ensures that non-user point is fault,
which doesn't exist on risk five,
then the BPR thing that I talked about,
and then there's also the few takes operations,
which also needs some form of point-on-masking and so on,
but luckily we submitted patches for this,
and there in the process of getting upstream,
but there also want to nail down the point
that it's quite complicated to use on risk five,
because in a difference to x86,
where you have major manufacturers that implement the course,
you now have a much more diverse landscape of processors,
and Linux kernel is not super well equipped,
that is current point, basically, handle this.
So, you would need very, very fine-grained mitigation things,
where you say, ah, if this processor
implements this specific predictor, I need to mitigate here,
and then I can maybe save some mitigation data to gain some performance,
which I think in the future is the way to go,
but currently, this is just work and progress,
and I think the community should really push for this.
And so I think what we need to mitigate this is first of all,
the standardized serializing fence,
then we need these fine-grained mitigations that I talked about,
and then there's also on the compiler side,
a lot of mitigations that come from the compiler,
or some mitigations that come from the compiler,
and those also need some equivalents on risk five,
which is actually really hard, because the calling conventions
under the code layout just works differently
in these mitigations that just don't part over very easily.
And I think the last thing that should happen
is that vendors would collaborate together
with all the other parts of the software ecosystem,
and with researchers so that we can get like a very precise idea
of what each core actually does in speculation,
and what each core actually implements and doesn't implement.
This way, you can even like get more performance out of it,
and everybody benefits, because in the end,
you can only do target mitigations where they actually need it,
instead of having to over mitigate it.
Yes, and with that, we can already wrap it up for this talk.
So I want to split this into three sections.
So first, what goes wrong?
So we've seen our unprivileged timers and cache maintenance,
so we have side channels.
Then we have seen a lot of diversity with vendor extensions,
and monratified extensions, which are implemented,
and by that we saw CPU bugs.
So go-striot is arbitrary, physically right,
and also denial of service bugs.
For these, we didn't have kill switches,
and also no update paths, so we have these mitigations in the kernel,
but we can't really mitigate go-striot, for example,
and then in the end, Lucas told you about transit execution,
which is also present on risk5.
So I guess you can see we basically have all the issues
we had on X86 and arm nodes on risk5.
So the question is, what can we do about that?
What are the short things we should do?
So first, as we argued before,
we should have privileged cache maintenance,
if we add such an extension,
even if we do that as a vendor,
then we should have course user space timers.
Decisions won't go away, but it would be much harder to exploit them.
Then you should only implement ratified extensions in your course.
If you use a vendor extension, do that very carefully,
you should have kill switches for all the features,
and there should be some instruction,
hooking, or update mechanism.
So we can have firm and we can ship updates to the CPUs,
even if that complicates the design.
And then in the end, for transit execution,
we really need to standardize serializing fence,
so we can build good mitigations.
And in the end, we basically have wishlist
for us as security researchers,
so what would make our lives easier
so that the entire world becomes the safer place?
Documentation is always great.
It's already kind of decent, but in a lot of places,
it's lacking, and we need documentation,
and we can do our research much faster.
So what's called is really great.
We like that tier designs are open-source,
but pushing on that even more would be very cool.
Unified perf and the face has been worked on,
but we would like that as well,
so having access to our cycle, for example,
we are that, because then you can also make that privileged.
Then one thing reproducible builds,
and also kernel headers.
It's compiling kernel headers on risk-five,
and patching the kernel, patching the bootloader.
It's not hard, but it's just involved to do that.
It would be nicer if we could have, basically,
nicer ways to do that on the system directly,
and not having to cross compile on another machine.
And then one thing for the differential fuzzing,
and also for basically kernel mitigations,
would be nice if there would be some standardized DB
for MWNID, and then arch IDs.
So you can nicely spot which is what CPU you are currently running on.
And with that, you can check out these two repositories
for our papers.
There will also find contact information also,
a website for Gauss-Player, the Fuzzer,
and also all the materials for our site channel research,
and with that, we are open to questions and discussions.
Thank you.
APPLAUSE
Yeah?
So, I think Joey, this is a good question for you.
I mean, you're always not responding.
This is not the first question.
Okay?
The regulation barriers, we're discussing them.
We have proposals for them.
We have make an instructions.
We have, particularly Monday,
the CPU is part of our vehicle.
And you can make them privileged by disabling them,
and not even, we're also answers to your microphone search,
usually what most expectations do have these issues.
And what we do is we regulate them.
And if someone tries basically,
we'll talk on their modes and we decide
we will do these people who won't be able to allow this to be
executed as well.
From the perspective to the point,
in the already-print list, you have no money
but things like that allow you for most of these.
And also, the thing is, for example,
in hyperphysers, you can just place
a blind light with the timer to start.
And for the signalization thing,
then you can start to get a done in the thanks to the extension,
who were talking about the crisis,
and the crisis of action,
but who actually have everything like a soft language,
you know, too much.
So if you like.
And another explanation,
if you like a barit.
But if you like the barit's dog control problem,
it likes
The question was whether we are engaging in the right and the security topic.
So with the speculation barriers we were engaging when we posted that there was quite a lot of
interest in that and we also willing to push that further forward.
I think the fancy thing we know that that exists but I think that aims to solve a very different
problem than what we want to have. I think we just want a very simplistic solution that does
one thing that is required and of course this is only a patch for one thing but it's already
like a requirement for certain patches to implement them.
Sorry, I'm very sorry to wrap up but we have to take all these discussions offline because
all the times up. Sorry for that but still thank you for your attention.