 Hello everyone, my name is Adam Zabrodski and together with Alex Matrosov we would like to give you a talk about glitching Krispy Chips, empty-back corruption for hard-dining ISA. However, this is the end goal what we end up doing and before we end up doing that we also needed to go through various different research areas we would like to cover in this topic today. To send us about ourselves, we don't want to focus too much here. Both of us did this research during our work at NVIDIA and here we can find some private contact information to me and Alex and we just want to mention that we did some security research for a couple of years already. So what is this talk about exactly? So let's speak first about execution environment. So to be able to speak about execution environment we need to have some kind of hardware and when we speak about the hardware we especially also mean about the CPU architecture. There might be various different CPU architecture like RISC-V, like X86, like ARM, etc. And when we write a software, software especially targets the CPU architecture. So any software which you write in the end are kind of designed for run on specific CPU architecture hardware. Even if you write in the high-level language in the end you still the interpreter runs on and targeting specific CPU architecture. And in this kind of scenario if you would like to break such kind of execution environment we can focus on the various type of attack. We can focus on the pure software attacks or pure hardware attacks. Example of the pure software attack could be any kind of the memory safely like overflow, use after fee, etc. Injection which is very popular in the high-level languages, like command injection, SQL injection, cross-excripting or logical issues where you essentially trying to target a specific software which is very badly designed and which might have security implication. There is also much more other attacks. About the pure hardware attacks we usually think about the glitching type of the attacks or any kind of the site channel attack or physical probing of the hardware also there is many more. So from the high-level perspective if you think about the pure software attack they are targeting specific implementation. Example could be specific programming language which allows you to have some kind of undefined behavior which you try to hunt or you can also target specific compiler, specific software, like firmware, etc. And there is no different than pure hardware attacks. In the pure hardware attacks you also focus on targeting specific implementation. Example could be specific CPU family or specific implementation of the architecture ISO etc. And there is also recently a very nice research about what about mixing these two types of the attack pure hardware and pure software and example of such kind of mix attack could be for example meltdown or spectra attacks. They essentially mix hardware and software. However if you think about that a bit more what about if you found the bug in the reference code of the hardware ISO itself not in the implementation of the ISO but like in the kind of ISO itself like a reference code for the ISO. This is pretty interesting implication from that because then the problem will affect all of the implementation of the silicon not just a specific implementation or specific family because everything which is realized on the reference code like ISO will be affected. And this is also interesting because in such case software cannot trust hardware at all what they do. So this is exactly what we'll try to speak about today this type of the problem which we discovered during our research. So at first how did we find it and how did we even focus on such kind of problem. So essentially we wanted to analyze a specific boot software like bootrom where specific microcode runs. However the problem is that it was running on the specific risk v chip which we essentially had zero experience with the architecture of risk v and moreover it was not just a simple risk v chip implementing base. I saw however they carry custom extension and custom functionalities on this specific environment which we want to analyze and even more the boot software was written in the ADACOR Spark language Spark language which we additionally also had zero experience with at that time during the research and we're starting to focus on that a bit more quickly. Is there any kind of public offensive research publication about that language even did anyone even hear about that language before because we did not and at that time we also needed to be able to analyze the binary especially the binary compiled from Spark language targeting this custom risk v chip and there was no even any tools who natively supported even simple risk v including IDAPRO and GITRA. This was around 2019 and none of this tool natively supported risk v and this is exactly what we try to speak about today. So during this talk we'll try to describe our journey through all of the problems which we met and during this research which resulted in the end in the discovering ambiguity of the risk v specification and also one additional problem. However first thing first let's speak about risk v in a nutshell. So risk v is essentially an open standard instruction set architecture known as ISA based on the risk principles and unlike any other most of the ISAs risk v essentially is provided under open source that do not require any fee it's open source and free essentially and but there is some kind of side effect of that because it's open source and it's free essentially the same risk v chip might have tons of the different implementation even ISA is the same so you think you have exactly the same chip but implementation could be completely different and variant and also risk v has a small standard base ISA which essentially have multiple standard extension however this gives you a potential huge fragmentation of the silicon because one base ISA with the custom extension another base ISA with the different extension and all of them still are risk v and everybody can easily add their own extension which is very cool because it's open source so nothing stops you to do that so you just take the ISA add your own extension and build our silicon which essentially as a side effect gives you even much bigger fragmentation because it's not only risk v based with the different extension but also they could be custom extension on the top of that and what is worth to mention that today there is more than 500 plus members of the risk v foundation who support this initial initiative of risk v including a big pliers like nvidia or google so most people now are familiar with the x86 and this is just prepared as very short and simple table who compares this to architecture so main difference is exactly license because x86 charge you the fee for ISA and architecture while risk v it's free so there's no fee for ISA neither for micro architecture risk v its instruction set based on risk obviously and x86 originally was a sysk but it's not really true anymore because since pentium pro x86 instruction essentially are turned into something called micro ops which is kind of like risk nowadays and x86 is very old architecture so essentially we have various variants of ISA they have 16 32 and 64 bits of ISA however risk v is much more modern so we have 32 64 and there is even 128 bits of variants of ISA which is not locked yet but essentially there is one and risk v operates on the memory model called slow store architecture where x86 is a register memory architecture and risk v has 32 general propose register registers but there is one special register it's called zero register which always keeps zero and what is interesting from security perspective risk v natively support execute on memory known as zone you can set up this as this is supported in the page table entries however x86 normally doesn't support zone unless you have hypervisor extension then you can divine zone like attributes in the slot table which is second level other translation and another big difference is software ecosystem which supports specific architecture so x86 essentially runs everywhere it's very old and very well designed and very well researched architecture so you have linux ecosystem windows macintosh and many more while risk v from the practicality perspective you essentially have only one ecosystem which is linux essentially but again from the security perspective you would like to focus more on the privilege mode and levels which architecture carries so this is very nice picture taken from the blog post link here on the below of the slides which essentially gives you the traditional rings which x86 carries so originally x86 only had four rings which is ring 0 1 2 and 3 while ring 1 and 2 was not really used however when the virtualization hardware in virtualization of architecture x86 not fully designed yet people trying to implement para virtualization of x86 using ring 1 but it's not doesn't need to be done anymore because now we have full hardware virtualization of x86 so traditionally in the ring 3 there is a list privilege code running which is like user application and in the ring 0 you have kernel code not so the time however over the time people demand more privilege levels so that's why we have something which we in officially called ring minus 1 where the hypervisor works software in the ring minus 2 there is some something which we call smm which is more privileged than ring minus 1 and there is also something what not many people know management engine on the x86 which you can call this as kind of ring minus 3 because it's the most privileged mode if you compare that to the risk v we have only free mode which is m s and u so traditionally uh it's an open source architecture so you have also various combination of this mode so you can have m mode without another mode so you can have m and u mode without s mode or m s and u mode which all of the mode essentially so what are these modes so u mode stands from user mode it's kind of equivalence to the ring 3 on the x86 this is where the application runs user application runs list privilege mode in the supervisor mode which is s mode essentially this is where what is equivalent to ring 0 this is where the kernel runs and m mode is kind of interesting because m mode called is called machine mode what's the isa defines this is the software which is the closest to the hardware runs kind of like a firmware however if you want to compare this mode to the x86 it should be something around ring minus 2 and ring minus 3 this is what you should think about as m mode is the most privileged mode essentially it's most powerful mode however risk v also works on the hypervisor extension so you have few extra modes so s mode became hs mode this is where the hypervisor extended supervisor works and we have two new modes which is v s mode and v u mode which is virtually supervisor and virtual user this is where the vm will run but also it doesn't cancel u mode normal u mode so you have also all of these modes together and again because it's open source you have one additional combination of supported risk v chips which which is also m vs and v u mode and again you don't need to implement all of the modes you can choose which mode you support your hardware and we as an attacker we are very interested and we would like to focus on dead mode which is m mode which you can kind of call it god mode because this is the most privileged and most powerful mode runs so if you are there is the most ideal situation so how to be there so essentially we know more or less what is risk v we learn about risk v a bit very quickly but we at least know what we are talking about and then we knew that the software which was targeting this specific hardware risk v which custom risk v essentially was written in spark and then we started to think about like what the hell is park we never heard about that language like did anyone even hear this language before so what is like the core spark a decor spark is essentially programming language together with the set of analyzing tools so spark in fact is a type of like ada language ada language but it's subset of ada language it's much more restricted and doesn't have full ada features because spark essentially the wants to be formally verified language and the formal verification is being carried by the exactly set of analyzing tools and this is where the strength of the language is it's exactly analyzing tools and this tool is these tools includes gnat proof gnat stack gnat test and gnat emulator essentially what this tool gives you as attributes for the spark language itself it's can statically prove various different things it can prove that these dynamic checks can never fail for example or they also can warranty you there is absence of runtime errors essentially everything is in the known and correct states because of that you don't have errors or runtime errors at least and also all of that it's formally verified which is very interesting and cool because there gives you a formal verified proofs that all of these attributes are being intact so what you should think about that from the attacker's perspective it's essentially a memory safe language it's a memory safe language which is formally proved so it's a kind of like a rust rust is not formally proved but it's a memory safe language and it's much stronger typing system than rust because it has very strong typing system and because it's much stronger than rust they also there is lack of problems like arithmetic overflows integer overflows underflows etc which is very interesting and because of that it's a very secure language it's traditionally have been it was used traditionally in the industries which are critical like avionics railways or defense system and so we should think about any language from the developer's perspective that you would like to model a correct states of the machine of the software and the hardware and language allows you to do it more easy or more hard to do that like in the scene language there is a lot of undefined behaviors so modeling all of the machine states it's very difficult and that's why you have various undefined states other language it's slightly more accurate in that case and allows you to give you more accurate modeling of the of the states and that's why there is less unambiguously and less unknown states there however because Spark it's much more strict than Ada essentially it's the most closest way how you can get to the correct states however because it's the strength it's in the analyzing tools essentially this is what the tools can gives you as an attribute however there is some kind of valves in the Spark language imagine you want to call the libraries which is implemented in the different language like in the C essentially Spark analyzer will not be able to prove that the code written in C which you call from Spark it's also correct in unknown states so that's why there is a valve from that and how does it look in the practice so if you write a program and you make a mistakes the prover will not only tell you where the bug is in the which line in which file but also that gives you proof of concept essentially so what are the values necessary to generate the bug or error at this example on the top you can see that probably tells you that there is a problem divided by zero which may failed when the variable B has value 42 so it's not only gives you the problem and also not only tells you the problem but also gives you the necessary condition how to execute the problem which is very interesting another example could be medium array index checkmate fail when the my index have value 36 so it's very interesting and then we're starting to think about that a bit more and so we wanted to analyze like what are the problems which specific tools can catch or cannot catch and we found one of the interesting scenario where I was able still to generate a program which prover says this doesn't have any problems which is you see on the top on this slide mark on the green the prover said there is no problems there however when we run that we were able to execute stock exhousion vulnerability and generate the exception because of lack of the memory however as we said before the spark supposed to give you one until there is absence of error or some time error so how is it even possible and then we started to run other tools like not stuck and we realized that even gnat prove didn't find the bug that problem gnat stuck did and on the bottom on the red you can see that they said that the gnat stuck analyzed all of the different cases and analyze there could be a problem with the stock exhousion so what did we learn from that kind of approach essentially we learned that you can compile still a buggy code but the programs are detected by the tools and the developers might not run them at all so it's very interesting attribute because it depends on the developing scenarios and the process of developing the software on the company and also tools are orthogonal to themselves because they detect completely different classes of the problem and to be fully protected you must run all of the provided tools and again it depends what's the process of software development is to be able to find out if all of these tools are run and another problem is there is no clear definition what are the classes of the problems which can or cannot be detected it's very limited and for public information what can be detected what is not and again we didn't find anything from the security researcher's perspective so what did we do we end up trying to do more research and find out because if nobody did it before us we must do it by ourselves so this is what we end up doing we're starting to evaluate it's kind of strong word but let's say analyzing the a decor spark language from the offensive security perspective and we divided the language we divided to the all of the security problems software problems so the general buckets of the problem and one of the most popular one is exactly general memory corruption back and compare with the other languages as essentially spark as we mentioned is a memory safe language so none of this kind of problem exists there is some kind of caveats which i don't want to focus now however you can think about that it's it's a memory safe language so memory corruption doesn't exist there and then we move to the general pointer security and it's interesting because spark doesn't have pointers at all so if it doesn't have pointers the pointer security doesn't apply there however there is still kind of corner case like imagine we are able to generate the stacks exhousion so that's why uncontrolled memory allocation kind of semi exists if you don't run that stack but it can be of course sketched by the tool set if you run them correctly and also there could be some kind of double factories imagine your dma twice the same region of the memory it's kind of possible to have like that and then we move to the arithmetic security and as i mentioned the spark gives you ability to have very precise type type language essentially you can define own type in the language and also define own boundaries and then the prover will tell you if anyone cross these boundaries which should be defined so essentially because of that you don't even need to use the general types like integers you just define own one every time when you model in your program with the hardware essentially that's why none of this problem exists like integer overflow on underflow or arithmetic overflow doesn't exist in the in the spark and then we also have other types of the problems like missing default case in switch statement or assigning instead of comparing and these problems doesn't exist in spark because tools easy catch them and then we starting to find out something more interesting like a parallel execution essentially what about the problems like race condition or deadlocks essentially it's possible to have them but a decor working on the extension to spark or Srebenskara which supposed to close that gap but from our perspective it was not very interesting because the boot software was not running essentially parallel it was single execution so it was not very interesting for us but it's worth to mention and then in the end we move to the logical box so essentially in the logical box the prover and nadir gnats stack none of the tools where can catch if you barely design the software because you try to model the hardware and you try to generate any kind of software which runs on the specific states which you model and then in the end if you barely do that of course park won't be able to catch that you're something but the design or barely model because this is intention of your software so this kind of problem still exists if you accurately modeling the hardware or if you accurately handling the dma or barely design the software so this is exactly the part which park cannot help you much so what did you learn from this evaluation so essentially as we mentioned before you can still compile the buggy code and because the problem are detected by the tools and the developers just might not run them and again the tools are orthogonal so they detect different classes of the problem so again to be fully protected you must run all of the tools not just one of them and from the analysis of the implementation bugs we realize that there still might be security issue when you in the design problems or also some kind of logical errors but there is no kind of memory safety for example so it's not worth to focus on that and again there is an additional class of the problem that could be introduced by the compiler because the bugs can be introduced by the compiler itself even if it's not in the software neither in the hardware however to be able to catch these three types of the problems we need to analyze the binary yes so because we need to analyze the binary we need to have an tools who can target the risk v and that was the problem that during this research neither either pro nor githra natively supported risk v there was some kind of plugins but there were no essentially native support of the risk v so we decided to focus on the githra and add own custom plugin to the githra to be able to analyze the binary which was running there but was generated from spark language and this is what we end up doing and how did we do it so githra 9.0 at the time this was the newest one didn't support natively risk v moreover we were dealing with the custom risk v chips not the standard risk v chip so even if we had them it will not work for us so again risk v is huge and implementation of entire risk v base what takes us a tons of time and additionally we needed to add the custom feature there custom extension not just risk v base so what we end up doing we found in the in on the github a few risk v base plugins for githra which had different implementation of risk v and we decided to integrate one of the plugin which we thought it's a good one on the top of tree of githra itself and few months after which is what is interesting githra 9.2 brought the natively risk v support they use exactly the same plugin which we use in our research and where to start so essentially we successfully integrate risk v plugin first but of course we need to modify it because we have custom extensions so githra is using slate language to describe the cpu and what is slate language and slate language is a processor specification language developed just for githra and it heritage from the sled and what is not cool that there was at that time at least very little documentation about that so if you want to implement some kind of a simple cpu you can use as a source of knowledge already implemented cpus in the source code and based on that you can just implement own one but if you want to do something more complex this could be a very painful and it was very painful at least for me so additionally we found in fact only one interesting source of knowledge it was a presentation made by juliami valadon which will link here on the slide so what do you need to do to implement cpu in the githra essentially you need to create a couple of files which are listed here and then we also define the model manifest how to tie them together and compile however we already had this file because we have from the plugin risk vbase plugin but we needed to modify them especially slaspec to be able to add custom extension and this is exactly the file where you define the register definition the tokens the aliases the instruction etc and githra what is interesting and it's worth to keep in mind allows you to compile the bad model slaspec as soon as the syntax is correct as long as the syntax is correct which essentially you will not even know if you make any mistakes then you run the githra you think everything works then you meet the instruction which you badly implement on runtime and then you see tons of java exception and maybe the program will crash so we use essentially check and strike and calm down techniques to be able to achieve what we wanted however let's briefly talk about how to do this kind of custom extension or tokens or githra plugins cpu implementation so essentially at first you define the token and the token of the instruction here defines how many bits instruction are there and you can define them the range of the bits which you are focused with the from the various aliases of the name here on the bottom you have for example the name csr0 which will be representing the bits from 20 to 27 as a token and then you also can define the register and at least we for example have status registers like u status from the user month status which you define the register the offs and the size and the name and then you can glue them together so you can attach the variables to the csr0 you can attach the the names of the register which you defined before and this is exactly what you do we just exactly also what we did we just defined the custom extension the custom tokens the custom register the custom variables and then we're starting to define the custom instruction and how to define the instruction so this is example of the compressed ad instruction you essentially define what are the operands there's two operands here d and csr crs2 and then you define what are the values of the tokens which you define as previously and as which bits they are mapping and then you define what they must be necessary values for them to be able to decode this specific instruction so example the cop 0001 token with the value 2 and the bits between 13 to 15 interpreted as a token cop 13 15 must have value 4 etc etc you define all of the bits and then the gitra will know that this is exactly the instruction which you're looking for and then you define the pseudo code if it matches you go to the pseudo code in the compressed ad instruction you essentially add two operands so that's what we did and then there is another example of the compressed branch equal zero it's exactly the same you define the tokens you define the values of the tokens which are necessary to encode the instruction you define the operands and then if in the pseudo code we check if the operands is zero then you just jump and that's all and in the end when we starting to add that and we add the custom extension the top of the risk v base isa on this plugin which we had we end up having this which is very cool so essentially what this screenshot from the gitra that shows you that essentially it correctly decompile the program and you have forfeited the compiler on the right side if you see on the left so you have the assembly and on the right side we starting to have forfeited the compiler and as you can see this is a binary which is generated from the spark this is a symbol language they found like adrv from risk v etc however that's the idea that we also got for free not only this assembly but also an analyzer we also had the custom extension was automatically reflected in the the compiler which of course obviously make our life much easier so gluing everything together we already know what to look for because we analyze the spark we know what the limits for the language and what we can hunt from from the offensive perspective obviously not memory safety issues however we also know that we were running on the risk v and it was not normal risk v but the custom risk v chip so we focus on the design on how hardware is focused so we focus on what is the design on the of the spark software spark how is it designed and how to implement the custom hardware how is it modeled because this we know what is there and it's not standard so what we saw we saw under and during analyzing the binary because that's why we needed to have this githra plugin that very first very very first instruction of this boot software was configuring the hardware also custom hardware and not only but addition also custom hardware as soon as the first instruction run is starting to configure the hardware and later we see that instructions of setting up the empty veg value and then we're starting through it what is empty veg value and officially this v documentation says that empty veg is defined as register read only and or read right which holds the base address of the trap handler and by default risk v always handles all of the traps in the most privileged mode which is m mode thought it can delegate this trap to the least the other modes modes if it's needed too and when the essentially trap happens the risk v switches to the machine mode and set the instruction pointer counter um the to that to the value defined in the register empty veg and empty veg can be defined in the two modes there is a mode which essentially keeps the direct pointer which is just jumped there and is defined by the two least significant bits so bit zero and one if it's zero then we have direct mode you just jump to the pointer or if it's non zero then it's being treated the value there as a vector vector rights like id t table x86 for example so then we're starting to think that empty veg is essentially configured after we configure the hardware so what will happen if any interrupt arrives before the empty veg is internalized because it can happen during utilization of the hardware and this is exactly what we discovered that essentially there is a problem because risk v empty veg register specification does not define the initial value of empty veg at all so it's undefined however when we're starting to analyze a few different implementation of risk v we found out that most of the test and implementation set it to zero anyway but in many implementation zero is not a valid address or if it's valid it's not mapped and then the reference to it to empty veg pointer which is null will generate an exception and this is kind of interesting because if there is any exception generated before initialized empty veg register risk v ends up in the very stable infinitive exception because it's starting to reference a null pointer which is not valid and generate another exception we generate another exception and so on so on and what was interesting that during this experiment risk v did not halt it was not halted it's continuous spinning in the infinitive exception loop and such state is in fact ideal situation for default injection attack like glitching attack because risk v at first is running in the highest privilege mode which is m mode and constantly referencing the glitchable register and this is the first bug essentially which we found that isa does not define the initial value of empty veg register and the second bug is that isa allows you to have infinitive exception loop without halting the core there is lack of double or triple fault like exception which is kind of interesting and however how to exploit these kind of issues which we found and this is where i would like to hand over to alex matrosov which physically glitched the risk v and he can take you over from there thanks thanks adam hello devcon my name is alex matrosov and i will be walking you over our exploitation technique for empty veg and it's actually two important points just adam mentioned it on the previous slide we have empty veg undefined behavioral and the core of risk v also doesn't halt it and it is actually uh looped after um such of the in exception happening with uh undefined behavioral of empty veg instruction but let's talk about the attack scenario and it is important points which you need to know before we basically get an actual scenario we need to pre-fill the imam of risk 5 core um and we can use like external uh recover usb boot flow functionality or access over uart so and second thing we need inability to generate an early exception during core execution basically it is a physical hardware damage can cause that and let's go to the scenario let's say we pre-filled imam with our as a shell code but it is some interesting techniques we used to make it uh the attack more stable because when uh after successful empty veg exceptions exception uh when we jumping into imam it can be some random address right and we need to make sure our code will be executed uh with the actual payload so we need to pre-fill imam with the knobs and knob sled will be basically creating some sort of insurance will be get into the random place but it will be led our shell code execution and on top of our knob sled we put actual shell code with the payload and it will be basically uh the realistic attack scenario in our case so attacker boot risk 5 core and then enforce the necessary condition to generate an early exception during the boot uh software boot and uh execute uh before actually empty veg get initialized right so a risk 5 core will be jumped into the null page and enters to the state of the infinite loop exception very stable and predictable state by the way and it's actually one of the conditions of our success in uh this attack scenario attacker uh glitches uh the empty veg register uh csr and after the value get uh glitched because it's just a boolean uh value uh even one bit change will be change the condition of this register right and the loop at core will be point somewhere into imam uh and the special payload which will be discussed before will be executed uh with our shell code so it's very interesting and stable attack scenario we tested in many uh different ways and i will be explain how we actually uh created the fault injection attack in the next slide but before we move there uh to one um thing you need to remember because empty veg register has a null page it's very likely that the change of one bit will be end up and generating undress pointing in the middle of the knob slot in imam and it's exactly why we need the fault injection attack and we experimented with a different type of fault injection attacks clock glitching uh um voltage glitching and uh actually we try to chip shooter and with an op sweat it's actually possible um but uh most stable and in our case because we experiment with uh UFO boards and chip whisper and it is UFO board with the risk 5 silicon cpu on it so uh we actually able uh uh to reach very stable point with the clock glitching attack so on this uh oscilloscope diagram you exactly see the glitch happens uh with the clock technique but also because uh we measure uh these values um with the clock glitching even with this small guy chip whisper nano we can manage after we await all the parameters and we have the offsets of the time frames uh we can create successful attack uh and actually uh with much cheaper hardware so of course uh we tried this complex scenario in many different environments and first of all thanks for nvidia hardware team which is actually uh help us a lot to uh play with the simulation environment with internal hardware and actually first of all we realize about this attack uh when we've been playing with some internal tools uh on this slide you can see uh the simulation environment where we have a uh following scenario uh on the first on step first we pull the trigger to corrupt empty back register csr uh the value of csr and uh looping the core and on the wave uh diagram it's very feasible when that happens and the step two actually uh leading the value change and then equal triggers an exception handler with the corrupted empty back register value and that's lit exactly uh pointing um to im m uh and executing our knob slide and lead the shellcode execution but let's talk also about how uh we report this bug and how we fix this uh bug with an industry effort from the risk five foundation community actually it was a very tough scenario uh because think about you find the bug not an actual implementation not in a single board you find the bug in isa that's mean most of the boards which is currently available in the markets it's affected by this issue and um how to fix it right so first of all like of course when we just realize this a big issue we contact the risk five foundation and until the time it was no official security response group and it's been actually we work with uh risk five foundation over our p-sort and also now it is official security response group exists which is good right and i think they can address uh security bugs and issues with isa and not only the isa tied to the risk five foundation uh as an industry call much more efficient also we contact sci-fi and working with them on analyzing this issue and actually we allocated the cv number uh 2021 1104 and uh nvidia p-sort and nvidia risk five hardware team uh confirmed this issue and fixed this issue internally and sync with all involved parties for responsible disclosure it's been uh kind of tough and timeline been also uh very limited because we want to deliver this talk and do deaf con conference but all the parties need to be secure first of all right and um how actually we can uh propose the fix for these problems right so first of all what we need to do with initialize that mtvac all tested chips uh have mtvac programmable and the most common mode vulnerable to describe it problem and um actually we also realized some of the newer chip been released recently this uh spring also actually affected by this problem because of course nobody thinks before about mtvac undefined behavioral but of course without uh looped core uh on the exception handler this attack will be not exploitable and if uh mtvac value uh will be not described but an instill undefined behavioral exist but let's say it will be some double or triple fault like exception or like just in the help this will be prevent the code execution which we described on the previous slide so but how we can fix this issue and what kind of mitigations it's can be first of all it's can be uh combination of uh hardware mitigations and software mitigations but let's talk uh about uh dcls and dcls and tcls it's actually very interesting techniques when we uh taken uh the shadow core uh dcls with a double core or tcls with a triple core in consideration of additional um execution uh following the instruction flow right so the shadow core adjust uh having the same flow the same instruction at and sync with the original core and if instruction flow it's not equal it will be panic or halted or whatever happens as defined in the silicon right same thing happening with the uh tcls and tcls just introduce uh two cores and it's will be much uh more difficult to um to glitch and in case of the two cores uh the possibility of the glitch still possible potentially but of course it's raising and increasing the bar dcls created much even much harder uh the attack scenario and uh i would say realistically it's need first of all to be uh involved in multiple glitch attacks in simultaneously so you need to glitch simultaneously multiple cores and with the corruption of the instruction let's say you need to corrupt uh the value and if these values are different so it can be cause some additional exceptions which you can't predict right so i would say uh it's raising the bar of course the attacks still possible but much more complicated and but let's talk about the software mitigations and uh Jeremy Boone uh from ncc group recently uh created a block series about the software mitigations and thank you for that it was a great uh uh series of explanation from the industry standards about software mitigations but of course all these mitigations known for a while and um also it's broadly used software mitigations doesn't prevent such of the attacks but it's raising the bar in many cases it's much make much more difficult um the attack scenario or like uh uh for uh an experienced attacker it's make it even impossible but uh all this uh hamming distance clear memory random delays and redundant checks it's actually can be introduced on the compiler level and created automatically because uh first of all uh the developer can forget to install this this mitigations or like uh copy paste something incorrectly or forget to change before uh copying this uh sort of mitigations in different places also some of them just can be utilized by compiler during the compilation flows because redundant checks as example without special definitions or compiler extensions it will be optimized uh during the compilation phases and you clearly can see this in disassembly flow also uh we propose some decisions uh uh we propose some design decisions to address for empty vac weaknesses and basically as we said before uh start cpu need to signal uh when the signal will be arrives initialize empty vac to point to the halt instruction basically if something happens it will be initiated the halt and uh change the isa uh needed because we need to warn about the potential undefined behavior if the empty back will be uh not initialized right and we need to basically introduce this kind of comment into the isa documentation also uh introduction of double triple fault like exception will be complementary to the halt of the core and actually instead of infinite loop it will be make this uh attack vector unexploitable it will be cause the denial of service but the not code execution we described previously and of course like it's much more uh can be explained in terms of uh risk five hardening and i think uh the mitigations against software attacks can be explained in different ways but also it is brilliant research being done of introducing uh pointer masking and uh uh adam will be takeover from that place thanks alex let's briefly talk about the pointer masking extension for risk v which can significantly increase the security state of entire risk v ecosystem in the software especially in the software but also in the hardware at can also reduce the impact or at least increase the the bar of exploitability of this empty vac issue which we're speaking about here today so this extension is driven uh as a collaboration between nvidia a google risk v t extension and the j extension task group so this is a huge collaboration and from the security perspective it allows to implement various technologies including hardware asa including pointer authentication code knows as pack hardware memories and boxing and it also can serve as a foundation for other extension including hardware memory tagging which cannot exist in the risk v without the pointer masking and also it can significantly improve the security of the other extension which is protected it can protect the control flow integrity attributes and shadow stack which is an extension driven by the team task group and the work is in progress however these kind of technologies are mostly known excluding the one which is hardware memory sandboxing this is kind of innovative and we haven't seen in other architectures so what is hardware memory sandboxing essentially it allows you to lock down the specific execution context on the sub region of the memory so even you can make an extra boundary between the threats even if they run on the same process context so the threat execution executing threat might not even be able physically to see or reference any memory outside of the preconfigured one and this is being enforced in the hardware level but this is more than that because essentially what you can think about that that essentially you can lock down what is specific ranges of the memory which are visible for each specific execution context so even if you have the vulnerability in such kind of software which runs on specific execution context such vulnerability will not allow you to jump over the predefined memory region so even if some kind of secrets it's leaving it's living in the other pages which normally this specific software doesn't need to have access to the vulnerability in the classic way will allows you to steal these secrets or override these secrets but because pointer masking can lock down what do you physically see which physical pages and also virtual pages and then you can protect that such kind of vulnerability will not be able to allow attacker using the current execution context to reference or corrupt any kind of the secrets outside of their predefined memory regions and this is exactly what the hardware memory sandboxing is doing and is provided by the pointer and masking isolation feature essentially it's slightly even more than that because you can have multiple different execution contexts which are locked down and they never be able never be able to reference memory which does not belong or are not configured for them to be synced and this also allows you to implement features like not only sandboxing but also to for the low cost devices you do not need to do full context switching because essentially the execution context is cannot corrupt their metadata between themselves because they kind of lock down you might not do a full context switch which you can save you performance so this is what essentially does it do and from the mtvac perspective what can what the how the pointer masking can can help essentially can predefined specific boot software can only be able to reference the memory for a very small specific subjection of the memory so then if you want to glitch the mtvac register a random corruption of the random bit will most likely do not allows you to execute your custom code or shell code because you will not even see that it will be locked down in specific execution context which will be very hard to predict what type of bit you need to precisely glitch to be able to end up in the predefined memory sandbox so that's what it is and i would like to hand over to alex thanks adam and i will be finished our representation and actually first of all i want to address some acknowledgments for nvidia team and it's been a lot of people involved from gpu system software and our risk five hardware team i want to thank you also product security and especially our psor team where they've been hardly working on this issue because in the beginning it's been not obvious where this issue need to be reported and actually which parties we need to disclose this issue we need also to thank you sci-fi and risk five foundation because risk five foundation take our concerns very serious and address this issue to whole ecosystem and also security team got created also sci-fi been very pleasant during the disclosure process and help us to understand this issue and side effects more deeply in the summary i want to actually summarize our research and first part we also cover some type safety languages and formal verification um with the idocore and spark of course it is minimize some attack surfaces with the memory corruption issues but it is not a silver bullet and some issues can be still exist and especially it's hard to mitigate some um undefined behavior or uh race condition attacks and of course uh in the end the code compiles to the native code right and to machine code by the compiler and formal verification happens on early stage before this transition to intermediate representation happens and all the compiler optimization applies it's still some room for undefined behavior and a lot of other interesting things can happen um there are cpu isa bugs exist right so and we found two uh interesting side effects in uh risk five isa and this actually real world attack scenarios can combine with the physical uh attack such as the fault injection and in combination with software exploitation uh techniques it can lead to very uh realistic and impactful attack scenarios and of course disclosing the isa bugs and stuff and we need to basically uh pay more attention on our open isa and basically how these bugs can be addressed and what kind of way and path to reporting it will be exist for the researcher right thank you very much for your attention and uh we will be happy to answer the questions