 understand and own, regaining control over your AMD CPU. And I must say it's the days where a your homebrew PC would have been like one CPU plus a lot of discrete logic. Those days are long long gone and now every single device, probably even this microphone, is full of microprocessors. It's pretty crazy. Robert Alexander and Christian discovered that the arm sorry that discovered an actual arm processor on an AMD CPU which I find quite mind-boggling and it actually includes its own firmware. And to talk about that I like to welcome them onto the stage and I'm really looking forward to hearing all about this discovery and what it has for consequences for us. So thank you very much. All right thanks. So before we dive into the topic a quick introduction. So this is Christian and this is Alex and I'm Robert and the reason why there is three of us today is I'm a PhD student at the Technische Universität in Berlin and beginning of 2018 I was looking into the secure encrypted virtualization technology from AMD and this technology requires a firmware running on the secure processor of AMD and that's where Christian came into play because he was looking for a master thesis. Now Christian is done with this thesis and Alex here kind of took over his work but today we're going to explain to you what the AMD secure process is doing and what we have on coverage. So with that I'm going to hand over to Christian. So let's dive right into our first part of the presentation which is about reverse engineering a completely unknown subsystem and when we started our research we had to find out what the AMD secure processor formally called platform security processor in this talk PSP actually is and it's a dedicated security subsystem that is integrated into your AMD CPU both on server and desktop CPUs. It's an ARM Cortex A5 inside your x86 CPU and it's there since around 2013. It runs a so-called secure OS and a kernel and it's actually undocumented and proprietary. It has access to some secure off chip storage for the firmware and some data and it mainly provides crypto functionality to the main CPU as well as yeah key generation and key management functionality. It's required for the early boot. In fact it's required for secure boot and it's it acts as a trust anchor in in your system. So the PSP is a security subsystem so it adds security to our system and that's that's good right. You might notice that this has some similarities with the Intel management engine which on this very stage we heard a lot about three hours ago. So let's look into the applications of this yeah of this piece of hardware. For that we need to talk about trust. The one form of trust AMD tackles in what they call secure encrypted virtualization. So you as a cloud customer can be sure that your virtual machine can even run in an untrusted physical location for example in a data center. The PSP that is running inside that server CPU acts as a remote trusted entity for you as a customer and it promises you to protect your memory so your data from the hypervisor and even from physical access for example through an data center administrator. The other form of trust that the PSP tries to to establish is now arriving in the Linux kernel and that's an API to a trusted execution environment. What that actually is is that the PSP acts as a black box inside your system that is trusted by an external entity for example a content provider like Netflix. This would enable for example digital write management on an untrusted system that is your system like Linux. So to sum this all up the PSP runs code that you don't know and that you don't control. And first of all let's talk about the knowing. What you see here is a super micro motherboard a server motherboard from the top and I highlighted three components here which are required or essential for for boot up of course that is the CPU the disk and a so-called SPI flash. The SPI flash is a simple storage that is available during early boot. So if you look at the boot procedure in a simplified manner then the CPU will first load the BIOS from this SPI flash and only at a later stage of booting when the necessary drivers are at hand it will be able to access the hard disk to load the operating system. Now as we saw from from AMD's marketing slides there's there's the PSP now the PSP is actually part of the CPU. It even boots before the CPU boots and will only after successful initialization of the system release the x86 CPU. So the PSP firmware is loaded loaded first and after that the boot is proceeding as we know it with the BIOS and the operating system. So where's this PSP firmware coming from? Well the BIOS is stored on the just just mentioned SPI flash memory and it contains all the data and code that is used of course during boot up and it is arranged according to the UEFI image specification. So it's a standardized format that's that's good. So maybe we should have a look into a super micro UEFI update. You see screenshot from the open source tool UEFI tool which is able to parse the UEFI image specification. You see information for example like the full size this is 16 megabytes that's the traditional that's the size of a traditional SPI flash and you see several volumes which contain BIOS code and data. What you can also spot are two so-called paddings non-empty paddings and these are paddings because or these are called padding by the tool because they are not part of the UEFI standard and we're not able to parse them with the standardized information available. So let's use another tool probably many of you know binwalk a command line tool for extracting firmware from images and forensics in general and let's look at the machine instructions we can find in that UEFI update for the super micro board. So the second block you see are Intel x86 instructions this is what we expect right it's it's a BIOS update for an x86 CPU so that's that's that's not surprising. What is more surprising is are the arm instructions so we might be very close to the PSP firmware and what we found out by staring at bytes and a hex editor a lot is what we call the firmware file system of the platform security processor and the central data structure in it is the directory and directories starts with a magic string in this case dollar PSP and it will have a checksum it will have a number of elements that it will list and a field we don't know and then with each line in the screenshot you will have an entry in this directory and each entry has a type and a size and an address where it is located inside that UEFI image. So the last entry of this directory is a special entry it points to a secondary directory or that's how we call it it's a continuation of this directory and each entry points to something like a file file definitely has a buddy and it might have an header and a signature but I'm gonna go into detail about this in just a second. So now we just need a reliable entry point to pass this whole firmware file system and this is the firmware entry table the firmware entry table begins with a specific byte sequence that's how you can find it and it lists pointers to firmware blobs such as those directories inside the UEFI image earlier versions of the firmware entry table are documented in source code of the corporate project and open source bios implementation and that was very helpful in the beginning of our research. So to make use of all that knowledge and all that staring at bytes here we develop PSP tool a command line utility that is able to pass any AMD firmware from UEFI updates such as the super micro update and in the output you will see something like a directory header here you will find entries like something called PSP firmware bootloader you will see that it has a version and PSP tool will even try to find out whether it's compressed signed will try to verify the signature and so on and just as a recap here you can see that the last entry of this directory actually points to another directory which PSP tool parses for you as well so in order to enable you to look into the code that is running on your AMD CPU right now PSP tool is available on GitHub and you can check it out today so the PSP runs code we don't know well now it's a matter of binary analysis to actually find out what it does let's talk about the control are we able to alter the firmware to run our own code for that we had to play around with hardware and more specifically we used an SPI programmer to flash any arbitrary UEFA image onto the SPI flash after for example taking the original UEFA image and tinkering around with one byte or one bit we would then try to boot the system and in most cases cases it just wouldn't boot this was this was insufficient because we only had binary and binary output from these experiments so we also used the logic analyzer that you can see on the top of this of this picture a logic analyzer is just an electronic instrument that can capture the data that runs through the logic lines in this case between the SPI flash and the super micro boards so looking into a recording of one of our boot procedures we would now be able to make sense of these of these data so for example we can see that the chip set here issues a read command that's defined by the byte three it would try to read the address e two zero zero zero zero and then the SPI flash would gladly respond with data at that location now you might argue the data is not that interesting because that's what we control that's what we can program that's what we can look into with PSP tool so what we were more curious about is the order and timing of the actual accesses and to make that a bit more visual we wrote PSP trace so PSP trace takes such a SPI capture and correlates it to the output from PSP tool and we will get a yeah enumeration of of the specific components of the PSP during boot and I'll get into detail about this also in just a second PSP traces available as part of the PSP tool repository if you're more interested about our hardware in our hardware setup you can check out our talk from the CC camp earlier this year where we actually had a Ryzen pro a CPU at hand and just use the Lenovo ThinkPad so that might be more suitable for your homework so I want to share two more insights that we gained through our experiments in the beginning first of all cryptographic protections on files files are projected by a signature and a field in the header and determines the according public key that can be used to verify that signature and and that's what the PSP does so there are several keys actually inside the firmware file system and then all these keys are signed by the AMD root public key which does not have a trailing signature but as we found out it after loading after after it is loaded from flash it will be compared to a hash and read only memory of the PSP so we were not able to alter it like that the second insight is how the early boot procedure of the PSP works we have an on chip bootloader that is burned into the chip into the PSP we have an off chip boot loader that is loaded from flash and then we have several applications that are loaded subsequently so now let's look a bit more closely at the output of PSP trace the first few read accesses are to the firmware entry table the global data structure and then the the on chip bootloader will load the PSP directory it will load the AMD public key and verify it as I just told you by comparing it to a to a hash in and read only memory it will load the PSP firmware bootloader that's what we call the off chip bootloader and this one will be verified with the AMD public key then in the boot trace of PSP trace we see a delay that's due to some initialization work the PSP does and then it will load more directories and will load and verify some applications eventually and with this rough overview of the boot procedure I'm gonna hand you over to Alex okay so now that we uncovered the basic modules of the firmware we obviously wanted to gain deeper knowledge about what these individual modules do how the firmware functions how the PSP is constructed what hardware it provides and how we can interface it so in order to do that we need to do a quick recap about how AMD structures its CPU itself so what you see here is a little x86 core being able to execute two threads using simultaneous multi-threading and AMD groups four of those cores into what they call a core complex it contains up to four cores based on your exact model and two of those complexes are put onto a CCD or core complex die that is what AMD also calls a chip led so it's a single silicon chip on your CPU and you have multiple of those chips on your on your CPU among the two CCX's it contains to the memory controller for the DDR for memory PCI express lanes communication links for to communicate with other CPUs in a system and much more so in our setup you saw earlier already we had the two socket system with two CPUs and each of these CPUs had four CCD's and now we have just not just one PSP in this whole system but up to eight so each of these CPUs or if each of these little PSP's is actually executing code even before the x86 cores have executed anything so AMD calls the one on CCD zero the master PSP and all the others are referred to as slaves the master coordinates the initial bring up of the platform so for the whole initial initialization for the memory controllers and so on and the slaves will respond to requests made by the master PSP so each of these PSP's is identical in the system because they are 32 bit ARM cores they have a 32 bit address space layout the first 256 K of this layout are backed by actual on chip SRAM those the first the on chip bootloader below the off chip bootloader so the PSP WF we bootloader and place it into memory where it will be executed among the actual firmware bootloader you will also have the page tables for the MMU yes the PSP also has a MMU and virtual memory enabled and the code is separated into a supervisor or kernel mode and a user mode part so the last page you see here is those so-called boot ROM service page it contains information about the PSP the code is currently executing on like number of sockets in the system the current CCD ID where it's executed it contains some some other things like a number of sockets and so on and it will become important later on then the off chip bootloader will call the applications in they are executed in user mode they contain the code and data to bring up the actual system and they also contain the stack memory and this is done on during the initial booter process by a using a fixed order and later on when the host OS runs it will be loaded the application for example for the SEV functionality will be loaded on demand so the rest of the space there we have to fill is taken up by MMIO so this PSP has its own cryptographic code processor which is not shared with the x86 you have the hardware resistance to access is x86 memory to access the system management network what this is we will come to in a bit and much more we don't know about now right now so the boot process and details so Christian already to have gave you a rough overview how the boot process is done and now we will take a deeper look into this so first of course you have the on chip bootloader it loads the off chip bootloader from flash and executes it the off chip bootloader will execute and initialize the PSP to a bare minimum and then call the apps the first one we have here debug unlock and security gasket we have no idea what they're actually for but we named them after some strings we found in the binaries itself so the big chunks you see here is the actual bootstrapping phase AMD calls it a Giza bootloader and it's not just a single binary but it hosts a binary which loads binaries from the flash further more and then executes it in a specific order so you see ABL 2 1 2 3 4 and 6 ABL 5 is used for something like a warm resume from suspense around for example so later on if the SEV app is for example loaded if the week or as request a specific SEV functionality and not before that because we have the separation between supervisor and user mode we obviously need a way that the app can communicate with the option of chip bootloader and that is done using the arm instructions supervisor call or as we see so we identified 76 this calls in total we have mostly reverse engineer 30 by now we can access the x86 memory we can communicate with other PSPs in a system we can load entries from flash and so on 28 a partly reverse engineer there's a mostly CCP operations for airs up public key verification AES encryption and so on and there are also more elaborate functions to communicate with other PSPs which are required during the a Giza bootloader stage and then we have 18 left and these we don't know about yet because they are not called at all or they have exactly one call site and a non-trivial to reverse engineer so system management network I already saw on the slide already that there was access SMN if you Google for system management network or SMN you will don't you won't find much information about it by AMD or otherwise the only reference you may find is a code in the Linux corner to read out the thermal sensors on the CPU so the system management network actually is a hidden control network inside your CPU each and every hardware block which is in there is connected to it and is used for the PSP to control and initialize the hardware blocks during the boot up phase so it is a dedicated address space so the PSP can't directly access it using MMIO instructions and we have the PSP there we have identified the memory controller the system management unit for which there was a talk about I think two years ago on this very converse the 86 course are there as well and a lot of other things we didn't reverse engineer so far one of the thing okay so to access the system management network the PSP has to map a certain region of the system management network address space into its own address space and then can access the register write read and so on and has to unmap it again and one of the functions we identified is what we call memory protection slots so the PSP has the possibility to configure the memory controller to revoke access to certain regions of the DDR4 memory from the x86 course this is done by using three registers we have a start register with a physical start address an end register to denote the physical end address of the region you want to protect and the control register where we only know yet so far the enable bit to flip it on or off and what it does is if the protection is flipped on the x86 will only read all but that when it tries to access this particular region and writes will have no effect with part through this region as well and this is one example used for the system management mode you if I code and for certain functionality for the secure encrypted virtualization feature of AMD so the next thing we did was running strings over all modules obviously and what we found there were a lot of interesting debug strings and even a lot of format strings and we wanted to know what the values were during the run time so when we disassembled the firmware and analyzed it we saw that most of these strings were referenced right before a special call called SVC six so this must be some sort of debug are debug print for the PSP the problem is SVC six is not implemented in the release firmware so we had to find another way to gain access to these debug strings and this is what I will talk about now so the problem here is first we need to know where we want to store this X this debug strings and we have we don't have any 86 memory available at this time in the process so we need to find another device or buffer where we can store it for later use but the only device we didn't know about at this time was the X the SPI flash luckily for us writing to this SPI flash area from the PSP generated the necessary bus cycles on the SPI bus without altering the flash then we need a code execution on the PSP to inject our own SVC handler and how we gained X code execution will Robert will talk about in the third part of this talk but for now we assume that we have code execution on the PSP already can inject our own SVC six handler and then leave let it run so the app will call SVC six it will be forwarded onto the SPI bus where we can collect it with our X already existing setup use a tool to filter the debug strings from the rest of the traffic on the SPI bus we don't want to have what don't want to have in the debug output and then hopefully get a raw PSP log and we had success with that so what you see here is the initial boot up was the very first stage of the boot up state the locks several megabytes long and we didn't have the chance to go through all of them so there's a lot of interesting stuff hiding there already so so the next step was to explore what is hidden inside the system management network and we didn't want to always refresh the whole system all the time and write code for a debug it because it is error-prone and tedious so we created our own setup where we could dynamically use the x86 course on the system to write and read from the system management network for that we replaced the SEV app with a stop and the stop provides three primitives that you can read write a system management network address we can execute an arbitrary this call from the off chip bootloader and we can read write general PSP memory and because the PSP is exposed as a separate PCIe device to the x86 we used the existing linux kernel driver and modified it to expose these requests to user land where we created the user space library wrapper and some Python bindings and with that we were able to use a Python shell to dynamically read write registers had a spurious reboot in between if you did the wrong thing and but could start over very quickly so what you see here in the code snippet is what we did to discover what these memory protection slots were about you can see that we call in sv and in this call handler that we write some system management network address and so on and we do it for all the different PSPs in the system so the master PSP can also forward these requests to all of the other PSPs in the whole system next thing you wanted to also analyze the SEV app further and see what the code or how the code is executed and how the data flows in this SEV app but because we already had a PSP stop running there and couldn't share it on the PSP we had to find another method and we created a PSP emulator for that and using our PSP proxy to forward requests onto the PSP so the current state can run the SEV app up to a certain point and we are still actively developing that so that started a few weeks ago and this will continue in the development so what it does is what you see here is the AMD SEV tool to manage the host and configure all the keys and certificates on the system and we modified the linux corner driver to reroute these requests to our own PSP emulator running in user space which is based on the unicorn engine. Any hardware access because we don't know much about the hardware yet is forwarded to the real PSP results are collected and when the SEV app finishes it will return the result back to the AMD SEV tool and with that we are able to execute some of the requests the SEV app implements successfully so far. Yeah what you see here is a small snippet from one of the traces you can see a SUSCORM being made it's a CCP request we don't know exactly how the arguments are used by now that's why there's a lot of unknown stuff but this will aid us in development and furthermore in addition to allowing a tracing code execution of the data flow we later on may be able to provide functionality which is currently only available on the epic server platform from AMD like secure encrypted virtual machine the problem here is we don't know yet if all the hardware is there which is supported and whether it's only a firmware limitation by IMD. If you're interested the code is here on the repository it will be made available in the next few days we have a number of repositories available you already saw PSP tool we have some repository we collect documentation about hardware interfaces this calls and so on we have our PSP emulator there and also the PSP apps repository if you want to dive into writing your own apps for the PSP and with that I will hand over to Robert who will talk about how we gain code execution on the PSP itself. Okay so for everything that Alex talked about we need code execution on the mic better alright so this part of owning the PSP is again split into parts. Now Christian already talked about the firmware and the SPI flash so this is something we can control because we have physical access to the device we can flash everything we want so what can we do with that so on the SPI flash we have these directories which have a header and entries and an entry is actually compromised of an ID an address and the size we've talked about files so an entry could be a reference to a file and we also talked about these secondary directories so an entry could refer to another directory. Now if you look at the files you see that they have a signature usually so we cannot manipulate those files directly if we touch them this will be noticed and they won't be loaded and the system will immediately reboot. Now what we can manipulate is the directories themselves because they are not protected at all so specifically what we can do is we can for example add additional entries these entries might point to the same files that doesn't matter we can add entries what we also can do is we can remove some of those entries or we can change entries so for example this reference to the secondary directory this has a size parameter right and this size refers to the size of that directory and actually what we can do is we can change that size so we can make the directory appear to be smaller without removing any of those entries. Now during boot this p speed directory that Christian already talked about is parsed so this p speed directory contains among other things the reference to the AMD public key which is used to authenticate all the applications which are loaded. Now this directory also has a secondary directory the content is not really relevant here so the onship bootloader that executes first will set up this bootrom service page that Alex talked about and this bootrom service page contains a copy of those directory entries just for the first directory and also the onship bootloader will copy the AMD public key itself to the bootrom service page so it only copies the AMD public key if it's been verified before okay so now this bootrom service page contains this AMD public key and this public key in memory is from then on used to authenticate applications so the off chip bootloader which executes later will use that bootrom service page and will extend it specifically it will copy the entries of the secondary directory to that bootrom service page so I guess you can already see where this is going so what could possibly go wrong here well we have space for 64 entries here and if we write more entries to that page we'll hit the AMD public key so the off chip bootloader should better check that we only copy at most 64 entries there it is there's a check let's say this is the function that appends entries and it says okay if the number of entries exceeds 64 we return an error code and do not copy sounds good the thing is that number refers to the number of entries in the secondary directory so this has a maximum size of 64 but there is already space there entries there on this bootrom service page so actually what we enforce with this check is whatever we append can have at most 64 entries and within that 64 entries well there's the AMD public key super convenient so what we do now we place our own public key inside the directory structures of the firmware file system the off chip bootloader copies the entries and copies the AMD public key so what does it mean for us now all this parsing happens before the first application is loaded so that means we control the very first application and can replace the content and from there on we control the userland part of the secure processor so now coming to the next part so the natural next target is of course i mean we have userland code execution we want to have the rest kernel mode so how we can we take over the kernel mode now let's have a look at how this distinction between kernel and user mode happens so if we look at the virtual memory layout we'll see that there's a user mode part and a fixed split with the kernel mode where our off chip bootloader resides so our application which we already control can try to access that memory of course but that won't work right the MMU will prevent any access to privileged memory okay so let's see how this works at runtime so this bootloader component if we specify the privileged memory a little bit more we have code and data there and at runtime another type of directory is parsed and this is called the BIOS directory i mean it's a similar structure as the directory before we have entries in the reference to a secondary directory the entries here are again of no relevance so during boot the off chip bootloader will copy those entries into its data section okay so for the copy operation we need some some information so let's say this is the copy operation it kind of looks like mem copy what we need is destination where to copy uh we need source this is the secondary directory this is the thing we want to copy which is already under our control so convenient we control whatever is whatever data is copied and we need the size value so where do we get that size oh yeah this this entry here has a size value super it's ours also right we control the directory structures we can manipulate the size so to sum up we have a copy operation into privileged memory with attacker controlled data and attacker controlled size this is a very old meme and i think it's appropriate because this this bug is so uh easy to prevent actually but for us it's good because now we control everything in red here okay so we control that control that part the thing is as you can see code is not part of what we control so what might be here what is of interest for us to overwrite thing is it's the page tables right the page tables are part of that data section within the privileged part of the virtual memory space so again what we do we place our own page tables here the data is copied and replaces the page tables in memory of the secure processor so now if we look at that virtual memory overview again well our page tables will define the virtual memory a bit different we make it everything user writable so we control the application our application now can touch the privileged memory and just overwrite everything there if we want to right for that we need to have to reimplement everything but we can patch now the secure operating system if you want so that means this parsing of the directory also happens before the first application so we control the first application that takes over the boot loader if you want and from there on we have everything um all those issues i presented were fixed were even fixed before we discovered them right so we might not be the first one that discovered them there are some of you remembered that there was some website called amd flaws they did not present too many technical details maybe what they discovered was something i presented here i don't know thing is it does not really matter for us because the secure processor does not implement any rollback prevention so we can always go back and refresh a vulnerable firmware and from that use whatever code we want to place there so what what we did is we used all this on an epic naples based service system and you cannot just use that issue on every amd system because the bootloader we are using was signed with an key specific for the epic naples cpu series however we believe we have not tested it thoroughly yet but we believe the same kind of issues exist in bootloaders which are signed with an rise in first generation key and for the rest we don't know yet so maybe for thread ripper or epic rom there are similar issues maybe not we don't know so the question is is this really an security issue i mean of course it's a security issue but for whom so everything we did requires physical access to the device so if it were my laptop personally i wouldn't be concerned too much however there are some things where this is a real issue for example if you rely on secure boot because the secure processor is the first part that puts up and if that is broken everything later on is also broken so a christian already told you that amd plans to use this secure processor trust execution environment if your application relies on that you better not have any security issues in that secure processor and for the last part the secure encrypted visualization technology from amd is dependent on the integrity of the secure processor if that is broken this technology is also broken so christian and i published a paper of that about that if you're interested you can read it up but for us here this is actually more of an opportunity right because we can gain more insight into this psp with code execution we can do a lot of cool things with that so it allows to do further research on other subsystems which are present in the amd cpus for example the psp is responsible to load the smu firmware the psp allows access to the smm mode so this is a ring minus two mode on the x86 cpus so higher privilege than your kernel and there's proprietary code running in that mode with the psp you have access to that code and could replace this analyze it whatever and the psp is responsible to kick off the x86 calls at all so everything that comes later is in theory now under our control thank you that's it yes thank you very much robert alexander and christian that was fantastic wow i have a lot of questions i guess in my head going on but do we have any questions from the audience and if you have any questions we have microphones lined up here a question is just so that you know what we're talking about with questions is a sentence with a question mark behind it and not your life story and i think i saw number one first so let's start with number one hey is there a reason why the page table is located at the end of the data segment i don't think so i mean just because you have to place it somewhere should be in the why not in the beginning i don't have no idea okay that's what i meant with a lot of weird questions here from the signal angel we had one question um this question goes to the first lecturer uh didn't you have access to an spi flash emulator to attend uh time of use versus time of check attack so um uh we had access to different tools but the talk to attack that you mentioned was not even was not even necessary to to mount the attacks we we talked about and actually so far we don't see any um possibility to mount a talk to attack okay so i think i saw background five next up um is there somebody microphone yes yeah so i was wondering if you considered looking at the boot rom for issues yes of course um the thing is we cannot find its code in the memory anymore after we mounted our attacks so i believe the boot rom code is not there which would make it more not there anymore which would make it much easier to analyze um we tried simple things like increasing directory sizes which are passed by the uh boot rom itself we haven't found any suspicious thing there yet microphone too thanks for your research um you have really nice um big power over the system right now do you have plans to make an psp firmware which is minimal and uh which makes your system work but without um some strange untrusted code um i wouldn't call it plans yet of course there are ideas to do that the thing is some of the functionality which is implemented from amd is really required so this this stages that alex talked about they configure your d or and train your drem so without those stages you don't have access to memory your x86 course wouldn't not work and to reimplement that without having access to any manuals is really really hard work so i'm not too confident that this will be possible in the near future i just refer to a management engine cleaner there is such a project which makes your management engine firmware slim so the amd firmware is already kind of slim the only thing that is not strictly required on the systems we have been looking at would be the sv firmware which is loaded on request and you can like disable that by just flipping a bit inside that file that would the system would still boot but when it when it tries to initialize the sv technology the kernel would say okay this does not work the system will still work after that thanks and last little question does psp work with microcode somehow we didn't find anything related to any microcode there so far thanks so let's move on to microphone three thank you first for the great talk i have one question do you have maybe found something evil or potentially evil in the code that it does no so far we didn't find anything which could be used as a foreign attack for example so what the psp might be able to do is access pce devices we found some code related to that but we are we don't we are not we are not sure yet whether it's actually used because also the psps executed was existing on graphics cards made by amd so that might be also related to that we couldn't find anything there yet but so far the psp looks rather clean compared to the internal management engine thank you so we have a question from the internet is the amd public key an rsa one only 576 bits it's an rsa key yes but it's a 2048 bits for the first generation epic cpus and i think uh 4069 for later generations microphone two um for me it seems like preventing to flash old vulnerable firmware is really important for a scenario like secure encrypted virtualization can you comment on how difficult it is for amd to add this rec retrospectively okay um so technically rollback prevention is there for i guess mobile devices for example you have that uh it should be possible uh for adding this functionality afterwards i don't think that's really possible because the on ship bootloader is the thing that loads the off chip bootloader and verifies it and that software component has to like uh stop loading if the firmware version does not match for example and you have to change that and that functionality is not there and you cannot update the on ship boot room so in that sense i don't think that's that's possible to change and if you look at our paper you will see that the firmware issues are kind of devastating for the sv technology because there are some keys which are now accessible which can be used for attacking sv protected guests thanks uh microphone three please um one question did you analyze the uh api to the x86 core and did you find anything that could be exploited without flashing anything so that you could directly go from x86 to psb exploitation um yeah we try to find the necessary code to interface with the x86 thing we found one uh place where the x86 cores are released after the psb initialized the whole system but obviously we can't do much with it except preventing the x86 boot at all and uh otherwise we couldn't find anything there yet so we focused on on a lot of on a bit of other like the memory controller and didn't have a deeper look at the into the x86 interface so what there is there is uh the bios can interface with a psb using a special mailbox register which is mapped uh um in mmyo space and x86 for requests so if it can for example the way if i when it boots it will say to the psb hey this is my uh system management mode code region please protect that for me and it will execute this request um but apart from that we couldn't find anything so far thank you so microphone four hi uh so is it correct that your work enables a hundred percent open source firmware for uh this uh kind of processes and if so have you already contacted core boot team to make that actually happen uh so well hundred percent open source um as for the psp there is this on chip boot rom which we can't replace right so this will be closed source then there is code of the off chip bootloader until the first exploit which runs which is not open source in theory you could from now on take over the psp write your own code but as i said before you had have to reimplement reimplement a lot of functionality without having any documentation right so technically it's possible i guess to do something like that uh practically i'm not too sure so we're gonna go to the internet for another question is it possible to block psb from within linux or bsd for the system's runtime by using search and boot flags sorry to block what add to block the psb from the linux or bsd so what you can do is like robert mentioned already you can flip the bit in the spi flash and then the psb once it initialize the whole system it will it won't run the sev app for example because the signatures won't match anymore and there's no other um sort of interface where the psp is actually triggered we are we couldn't find it so far microphone three i think he was first oh okay all right right microphone two then um did you try to enable any superpowers from psp like jtag or special tricks with voltage or something else i mean the first application that is loaded has some strings in it like debug unlock sounds interesting but then again um jtech where would you access the jtech of the psp you need to have some some connection to the the lines right until supports usb debugging yeah i know uh with special devices right uh no even wire cable okay so anyhow i have the suspicion that this debug unlock app is responsible to to allow some debug mode which then i assume with special hardware you can do have jtech but we have not touched it yet okay thanks now microphone three so i'm as far from a lawyer as uh lawyer as possible uh but could amd in any way uh file a cease and desist for anything you do probably not i guess but just curious uh i have no idea thank you and as i said before we're not the ones that initially discover probably not the ones that initially discovered these issues and it's not really about these issues i mean for me personally these issues are a nice way to get more insight into the psp and it's not about having the super newest security issue whatever so if amd wants to file something i guess they would have also filed other people that did similar research before maybe they did i don't know so we had uh another question from the internet how long did it take you to reverse engineer and develop all the styles um so i think beginning of 2018 christian was starting with uh his master thesis and we spent a lot of time on figuring out how this firmware file system works and the boot process and writing these psp trace and psp tool to to better understand the components of the firmware and alex joined in a may mayish this year and well we're still working on it right so the emulator once we figured out a lot of information about the about the psp i think the emulator was easy to to develop so in the sense that it didn't take too much time but of course there was a lot of work going into it before that so i do not see oh i do see another question from the internet last question all right and did you try to glitch the psp by manipulating the voltage of the sock uses why i think our approach is easier but no seriously we we did not try so with that i don't see any further questions and i would like you to help me thank robert alexander and christian for this fantastic talk