< Return to Video

36C3 - Uncover, Understand, Own - Regaining Control Over Your AMD CPU

  • 0:00 - 0:07
    36C3 preroll music
  • 0:07 - 0:13
    ominous bubbling, ebbing away
  • 0:20 - 0:27
    Herald: The next talk is called "Uncover,
    Understand and Own - Regaining Control
  • 0:27 - 0:34
    Over Your AMD CPU", and I must say, the
    days where your homebrew PC would have
  • 0:34 - 0:41
    been like one CPU plus a lot of discrete
    logic, those days are long, long gone. Now
  • 0:41 - 0:45
    every single device, probably even this
    microphone, is full of microprocessors.
  • 0:45 - 0:53
    It's pretty crazy. Robert, Alexander and
    Christian discovered an actual ARM
  • 0:53 - 1:01
    processor on an AMD CPU, which I find
    quite mind boggling; and it actually
  • 1:01 - 1:07
    includes its own firmware. To talk about
    that, I'd like to welcome them onto the
  • 1:07 - 1:13
    stage. I'm really looking forward to
    hearing all about this discovery and what
  • 1:13 - 1:16
    it has for consequences for us. So thank
    you very much. Give them a hand!
  • 1:16 - 1:23
    Applause
  • 1:23 - 1:26
    Robert Buhren: All right. Thanks. So,
    before we dive into the topic, a quick
  • 1:26 - 1:32
    introduction. This is Christian and this
    is Alex, I'm Robert. And the reason why
  • 1:32 - 1:37
    there's three of us today is, I'm a Ph.D.
    student at the Technische Universität in
  • 1:37 - 1:43
    Berlin, and beginning of 2018, I was
    looking into the Secure Encrypted
  • 1:43 - 1:47
    Virtualization (SEV) technology from AMD.
    And this technology requires a firmware
  • 1:47 - 1:53
    running on the Secure Processor of AMD.
    And that's where Christian came into play
  • 1:53 - 1:57
    because he was looking for a master's
    thesis. Now Christian is done with this
  • 1:57 - 2:03
    thesis, and Alex here kind of took over his
    work. But today we're going to explain to
  • 2:03 - 2:10
    you what the AMD Secure Processor is doing
    and what we have uncovered. So with that,
  • 2:10 - 2:17
    I'm going to hand over to Christian.
    Christian Werling: So let's dive right
  • 2:17 - 2:22
    into our first part of the presentation,
    which is about reverse engineering a
  • 2:22 - 2:28
    completely unknown subsystem. And when we
    started our research, we had to find out
  • 2:28 - 2:33
    what the AMD Secure Processor, formerly
    called Platform Security Processor, in
  • 2:33 - 2:38
    this talk PSP, actually is. And it's a
    dedicated security subsystem that is
  • 2:38 - 2:47
    integrated into your AMD CPU both on
    server and desktop CPUs. It's an ARM
  • 2:47 - 2:57
    Cortex A5 inside your x86 CPU and it's
    there since around 2013. It runs a so-
  • 2:57 - 3:05
    called secure OS and a kernel. And it's
    actually undocumented and proprietary. It
  • 3:05 - 3:12
    has access to some secure off-chip storage
    for the firmware and some some data, and
  • 3:12 - 3:20
    it mainly provides crypto functionality to
    the main CPU, as well as, yeah, key
  • 3:20 - 3:23
    generation and key management
    functionality.
  • 3:23 - 3:29
    It is required for the early boot. In
    fact, it's required for Secure Boot, and
  • 3:29 - 3:37
    it acts as a trust anchor in in your
    system. So the PSP is a security
  • 3:37 - 3:45
    subsystem, so it adds security to our
    system. And that's good, right? You might
  • 3:45 - 3:50
    notice that this has some similarities
    with the Intel Management Engine, which on
  • 3:50 - 3:56
    this very stage we heard a lot about three
    hours ago. So let's look into the
  • 3:56 - 4:04
    applications of this piece of hardware.
    For that, we need to talk about trust.
  • 4:04 - 4:11
    The one form of trust AMD tackles in what they
    call Secure Encrypted Virtualization (SEV).
  • 4:11 - 4:18
    So you as a cloud customer can be
    sure that your virtual machine can even
  • 4:18 - 4:24
    run in an untrusted physical location, for
    example, in a data center. The PSP that is
  • 4:24 - 4:31
    running inside that server CPU acts as a
    remote, trusted entity for you as a
  • 4:31 - 4:39
    customer. And it promises you to protect
    your memory, your data from the hypervisor
  • 4:39 - 4:44
    and even from physical access. For
    example, through a data center
  • 4:44 - 4:53
    administrator. The other form of trust
    that the PSP tries to establish is now
  • 4:53 - 5:02
    arriving in the Linux kernel, and that's
    an API to a trusted execution environment.
  • 5:02 - 5:08
    What that actually is, is that the PSP
    acts as a black box inside your system
  • 5:08 - 5:14
    that is trusted by an external entity. For
    example, a content provider like Netflix.
  • 5:14 - 5:21
    This would enable, for example, digital
    rights management on an untrusted system
  • 5:21 - 5:29
    that is your system, like Linux. So to sum
    this all up, the PSP runs code that you
  • 5:29 - 5:35
    don't know and that you don't control. And
    first of all, let's talk about the
  • 5:35 - 5:45
    knowing. What you see here is a Supermicro
    motherboard, a server motherboard, from
  • 5:45 - 5:50
    the top, and I highlighted three
    components here which are required or
  • 5:50 - 5:59
    essential for boot up, of course. That is
    the CPU, the disk and so-called SPI flash.
  • 5:59 - 6:04
    The SPI flash is a simple storage that is
    available during early boot. So if you
  • 6:04 - 6:09
    look at the boot procedure in a simplified
    manner, then the CPU will first load the
  • 6:09 - 6:16
    BIOS from this SPI flash. And only at a
    later stage of booting, when the necessary
  • 6:16 - 6:22
    drivers are at hand, it will be able to
    access the hard disk to load the operating
  • 6:22 - 6:30
    system. Now, as we saw from AMD's
    marketing slides, there is the PSP now.
  • 6:30 - 6:39
    The PSP is actually part of the CPU and
    even boots before the CPU boots and will
  • 6:39 - 6:46
    only after successful initialization of
    the system release the x86 CPU. So the PSP
  • 6:46 - 6:52
    firmware is loaded first, and after that,
    the boot is proceeding as we know it with
  • 6:52 - 7:00
    the BIOS and the operating system. So
    where is this PSP firmware coming from?
  • 7:00 - 7:07
    Well, the BIOS is stored on the just-
    mentioned SPI flash memory and it contains
  • 7:07 - 7:13
    all the data and code that is used, of
    course, during boot up. And it is arranged
  • 7:13 - 7:19
    according to the UEFI image specification.
    So it's a standardized format. That's
  • 7:19 - 7:28
    that's good. So maybe we should have a
    look into a Supermicro UEFI update. You
  • 7:28 - 7:35
    see screenshots from the open source tool,
    UEFI tool, which is able to parse the UEFI
  • 7:35 - 7:41
    image specification. You see information,
    for example, like the full size. This is
  • 7:41 - 7:45
    16 megabytes. That's the traditional,
    that's the size of a traditional SPI
  • 7:45 - 7:53
    flash. And you see several volumes which
    contain BIOS code and data. What you can
  • 7:53 - 7:59
    also spot are two so-called paddings, non
    empty paddings. And these are called
  • 7:59 - 8:04
    paddings by the tool because
    they are not part of the UEFI standard.
  • 8:04 - 8:09
    And we're not able to parse
    them with the standardized information
  • 8:09 - 8:17
    available. So let's use another tool.
    Probably many of you know "binwalk", a
  • 8:17 - 8:24
    command line tool for extracting firmware
    from images and forensics in general. And
  • 8:24 - 8:30
    let's look at the machine instructions we
    can find in that UEFI update for the
  • 8:30 - 8:37
    Supermicro board. So the second block you
    see are Intel x86 instructions. This is
  • 8:37 - 8:45
    what we expect, right? It's a BIOS update
    for an x86 CPU. So that's not surprising.
  • 8:45 - 8:52
    What is more surprising are the ARM
    instructions. So we might be very close to
  • 8:52 - 9:03
    the PSP firmware. And what we found out by
    staring at bytes and a hex editor a lot is
  • 9:03 - 9:09
    what we call the firmware file system of
    the Platform Security Processor. And the
  • 9:09 - 9:14
    central data structure in it is the
    directory. A directory starts with a
  • 9:14 - 9:21
    magic string, in this case, dollar PSP,
    and it will have a checksum. It will have
  • 9:21 - 9:28
    a number of elements that it will list and
    a field we don't know. And then with each
  • 9:28 - 9:35
    line in the screenshot, you will have an
    entry in this directory. And each entry
  • 9:35 - 9:42
    has a type and a size and an address where
    it is located inside that UEFI image. So
  • 9:42 - 9:47
    the last entry of this directory is a
    special entry. It points to a secondary
  • 9:47 - 9:57
    directory or that's how we call it. It's a
    continuation of this directory, and each
  • 9:57 - 10:03
    entry points to something like a file. A
    file definitely has a body and it might
  • 10:03 - 10:08
    have a header and a signature. But I'm
    gonna go into detail about this in just a
  • 10:08 - 10:13
    second. So now we just need a reliable
    entry point to parse this whole firmware
  • 10:13 - 10:18
    file system, and this is the Firmware
    Entry Table. The Firmware Entry Table
  • 10:18 - 10:22
    begins with a specific byte sequence,
    that's how you can find it. And, it lists
  • 10:22 - 10:29
    pointers to firmware blobs such as those
    directories inside the UEFI image. Earlier
  • 10:29 - 10:33
    versions of the Firmware Entry Table are
    documented in source code of the Coreboot
  • 10:33 - 10:37
    project, an open source BIOS
    implementation, and that was very helpful
  • 10:37 - 10:45
    in the beginning of our research. So, to
    make use of all that knowledge and all
  • 10:45 - 10:51
    that staring at bytes here, we developed
    "psptool", a command line utility that is
  • 10:51 - 11:02
    able to parse any AMD firmware from UEFI
    updates such as the Supermicro update. And
  • 11:02 - 11:07
    in the output you will see something like
    a directory header here, you will find
  • 11:07 - 11:12
    entries like something called PSP Firmware
    Bootloader. You will see that it has a
  • 11:12 - 11:17
    version, and psptool will even try to
    find out whether it's compressed, signed,
  • 11:17 - 11:25
    will try to verify the signature and so
    on. And, just as a recap here, you can see
  • 11:25 - 11:29
    that the last entry of this directory
    actually points to another directory,
  • 11:29 - 11:36
    which psptool parses for you as well. So
    in order to enable you to look into the
  • 11:36 - 11:41
    code that is running on your AMD CPU right
    now, psptool is available on GitHub and
  • 11:41 - 11:51
    you can check it out today. So the PSP
    runs code we don't know. Well, now it's a
  • 11:51 - 11:56
    matter of binary analysis to actually find
    out what it does. Let's talk about the
  • 11:56 - 12:06
    control. Are we able to alter the firmware
    to run our own code? For that we had to
  • 12:06 - 12:14
    play around with hardware, and more
    specifically we used an SPI programmer to
  • 12:14 - 12:22
    flash any arbitrary UEFI image onto the
    SPI flash. After, for example, taking the
  • 12:22 - 12:28
    original UEFI image and tinkering around
    with one byte or one bit we would then try
  • 12:28 - 12:37
    to boot the system, and in most cases it
    just wouldn't boot. This was insufficient
  • 12:37 - 12:42
    because we only had binary output from
    these experiments. So we also used the
  • 12:42 - 12:49
    logic analyzer that you can see in the top
    of this picture. A logic analyzer is just
  • 12:49 - 12:54
    an electronic instrument that can capture
    the data that runs through the logic
  • 12:54 - 13:06
    lines. In this case, between the SPI flash
    and the Supermicro board. So, looking into
  • 13:06 - 13:16
    a recording of one of our boot procedures
    we would now be able to make sense of this
  • 13:16 - 13:22
    data. So, for example, we can see that the
    chipset here issues a read command that's
  • 13:22 - 13:28
    defined by the byte three, but tried to
    read the address E 2 0 0 0 0 and then the
  • 13:28 - 13:35
    SPI flash would gladly respond with data
    at that location. Now you might argue the
  • 13:35 - 13:39
    data is not that interesting because
    that's what we control, that's what we can
  • 13:39 - 13:44
    program, that's what we can look into with
    psptool. So what we were more curious
  • 13:44 - 13:51
    about is the order and timing of the
    actual accesses. And to make that a bit
  • 13:51 - 14:00
    more visual we wrote "psptrace". So,
    psptrace takes such a SPI capture and
  • 14:00 - 14:09
    correlates it to the output from psptool,
    and we will get a enumeration of the
  • 14:09 - 14:15
    specific components of the PSP during
    boot, and I'll get into detail about this
  • 14:15 - 14:22
    also in just a second. "psptrace" is
    available as part of the psptool
  • 14:22 - 14:29
    repository. If you're more interested
    about our hardware in our hardware setup,
  • 14:29 - 14:36
    you can check out our talk from the CCCamp
    earlier this year where we actually had a
  • 14:36 - 14:43
    Ryzen Pro CPU at hand, and just used the
    Lenovo ThinkPad. So that might be more
  • 14:43 - 14:53
    suitable for your homework. So I want to
    share two more insights that we gained
  • 14:53 - 14:58
    through our experiments in the beginning.
    First of all, cryptographic protections on
  • 14:58 - 15:05
    files. Files are protected by signature
    and a field in the header determines the
  • 15:05 - 15:10
    according public key that can be used to
    verify that signature. And that's what
  • 15:10 - 15:18
    the PSP does. So there are several keys
    actually inside the firmware file system,
  • 15:18 - 15:23
    and then all these keys are signed by the
    AMD root public key which does not have a
  • 15:23 - 15:32
    trailing signature; but as we found out,
    after it is loaded from flash, it will be
  • 15:32 - 15:38
    compared to a hash in Read Only Memory of
    the PSP. So we were not able to alter it
  • 15:38 - 15:47
    like that. The second insight is how the
    early boot procedure of the PSP works.
  • 15:47 - 15:52
    We have an on-chip bootloader that is
    burnt into the chip, into the PSP.
  • 15:52 - 15:55
    We have an off-chip bootloader that is
    loaded from flash,
  • 15:55 - 16:00
    and then we have several applications
    that are loaded subsequently.
  • 16:00 - 16:04
    So now let's look a bit more closely at
    the output of psptrace.
  • 16:04 - 16:09
    The first few read
    accesses are to the firmware entry table,
  • 16:09 - 16:16
    the global data structure, and then the
    on-chip boot loader will load the PSP
  • 16:16 - 16:21
    directory, it will load the AMD public
    key, and verify it as I just told you by
  • 16:21 - 16:29
    comparing it to a hash in Read Only
    Memory, it will load the PSP firmware
  • 16:29 - 16:33
    bootloader. That's what we called the off-
    chip to bootloader. And this one will be
  • 16:33 - 16:41
    verified with the AMD public key. Then in
    the boot trace of psptrace, we see a delay
  • 16:41 - 16:46
    that's due to some initialization work the
    PSP does, and then it will load more
  • 16:46 - 16:55
    directories and will load and verify some
    applications eventually. And with this
  • 16:55 - 17:00
    rough overview of the boot procedure, I'm
    gonna hand you over to Alex.
  • 17:01 - 17:06
    Applause
  • 17:06 - 17:11
    Alexander Eichner: OK. So now that we
    uncovered the basic modules of the
  • 17:11 - 17:14
    firmware, we obviously wanted to gain
    deeper knowledge about what these
  • 17:14 - 17:18
    individual modules do, how the firmware
    functions of the PSP is constructed, what
  • 17:18 - 17:23
    hardware it provides and how we can
    interface it. So in order to do that, we
  • 17:23 - 17:29
    need to do a quick recap about how AMD
    structures the CPU itself. So what you see
  • 17:29 - 17:34
    here is a little x86 core being able to
    execute two threads using simultaneous
  • 17:34 - 17:39
    multi threading and AMD groups four of
    those cores into what they call a Core
  • 17:39 - 17:45
    CompleX (CCX). It contains up to four
    cores based on your exact model, and two
  • 17:45 - 17:50
    of those complexes are put onto a CCD or
    Core Complex Die. That is what AMD also
  • 17:50 - 17:56
    calls a chiplet. So it's a single silicon
    chip on your CPU and you have multiple of
  • 17:56 - 18:03
    those chips on your CPU. Among the two
    CCXs, it contains the memory controller
  • 18:03 - 18:08
    for the DDR4 memory, PCI express lanes,
    communication links to communicate with
  • 18:08 - 18:14
    other CPUs in the system and much more.
    So, in our setup you saw earlier already,
  • 18:14 - 18:22
    we had a two socket system with two CPUs
    and each of these CPUs had four CCDs. And
  • 18:22 - 18:29
    now, we have not just one PSP in this
    whole system, but up to eight. So each of
  • 18:29 - 18:35
    these CPUs or each of these little PSPs is
    actually executing code even before the
  • 18:35 - 18:43
    x86 cores have executed anything. So AMD
    calls the one on CCD 0 the Master PSP, and
  • 18:43 - 18:48
    all the others are referred to as slaves.
    The master coordinates the initial bring
  • 18:48 - 18:52
    up of the platform. So for the whole
    initialization, for the memory controllers
  • 18:52 - 18:59
    and so on and the slaves respond to
    requests made by the master PSP. So each
  • 18:59 - 19:05
    of these PSP is identical in the system.
    Because they are 32 bit ARM cores, they
  • 19:05 - 19:10
    have a 32 bit address space layout. The
    first 256KiB of this layout are backed by
  • 19:10 - 19:16
    actual on-chip SRAM. The first, the on-
    chip bootloader, will load the off-chip
  • 19:16 - 19:22
    bootloader, "PSP_FW_BOOTLOADER", and
    place it into memory where it will be
  • 19:22 - 19:27
    executed. Among [below] the actual
    firmware bootloader, you will also have
  • 19:27 - 19:32
    the page tables for the MMU. Yes, the PSP
    also has a MMU and [is] virtual-memory-
  • 19:32 - 19:37
    enabled. And the code is separated into a
    supervisor, or kernel, mode and the user
  • 19:37 - 19:43
    mode part. So, the last page you see here
    is the so-called boot ROM service page. It
  • 19:43 - 19:47
    contains information about the PSP [that]
    the code is currently executing on, like
  • 19:47 - 19:52
    number of sockets in the system, the
    current CCD ID where it's executed. It
  • 19:52 - 19:59
    contains some other things, like number
    of sockets and so on, and it will become
  • 19:59 - 20:05
    important later on. Then the off-chip
    bootloader will call the applications.
  • 20:05 - 20:08
    They are executed in user mode. They
    contain the code and data to bring up the
  • 20:08 - 20:16
    actual system and they also contain the
    stack memory. And this is done during the
  • 20:16 - 20:22
    initial boot-up process by using a fixed
    order. And later on when the host OS runs,
  • 20:22 - 20:27
    the application, for example, for the SEV
    functionality will be loaded on demand.
  • 20:27 - 20:33
    So, the rest of the space there we have
    to fill is taken up by MMIO.
  • 20:33 - 20:37
    So, this PSP has its own cryptographic code
    processor which is not shared with the
  • 20:37 - 20:43
    x86. You have the hardware registers to
    access x86 memory, to access the system
  • 20:43 - 20:47
    management network (what this is, we will
    come to in a bit), and much more [that] we
  • 20:47 - 20:54
    don't know about now, right now. So the
    boot process in detail. So, Christian
  • 20:54 - 20:58
    already gave you a rough overview how the
    boot process is done and now we will take
  • 20:58 - 21:01
    a deeper look into this. So first, of
    course, you have the on-chip bootloader.
  • 21:01 - 21:05
    It loads the off-chip bootloader from
    flash and executes it. The off-chip
  • 21:05 - 21:10
    bootloader will execute and initialize a
    PSP to a bare minimum and then call the
  • 21:10 - 21:13
    apps. The first one we have here,
    DebugUnlock and Security Gasket. We have
  • 21:13 - 21:17
    no idea what they are actually for, but we
    named them after some strings we found in
  • 21:17 - 21:23
    the binaries itself. So, the big chunk you
    see here is the actual bootstrapping
  • 21:23 - 21:27
    phase. AMD calls it "AGESA BootLoader"
    (ABL) and it's not just a single binary,
  • 21:27 - 21:32
    but it hosts a binary which loads binaries
    from the flash furthermore, and then
  • 21:32 - 21:37
    executes it in a specific order. So, you
    see here ABL one, two, three, four and
  • 21:37 - 21:42
    six. ABL five is used for something like a
    warm resume from suspend to RAM, for
  • 21:42 - 21:48
    example. So, later on, if the SEV app is
    for example loaded, if the OS requests a
  • 21:48 - 21:55
    specific SEV functionality and not before
    that. Because we have the separation
  • 21:55 - 21:59
    between supervisor and user mode, we
    obviously need a way that the app can
  • 21:59 - 22:03
    communicate with the off-chip bootloader
    and that is done using the ARM instruction
  • 22:03 - 22:10
    "Supervisor Call" or "SVC". So we
    identified 76 syscalls in total. We have
  • 22:10 - 22:14
    mostly reverse-engineered 30 by now. We
    can access the x86 memory. We can
  • 22:14 - 22:19
    communicate with other PSPs in a system.
    We can load entries from flash and so on.
  • 22:19 - 22:24
    28 are partly reverse-engineered. Those
    are mostly CCP operations for RSA public
  • 22:24 - 22:28
    key verification, AES encryption and so
    on. And there are also more elaborate
  • 22:28 - 22:32
    functions to communicate with other PSPs
    which are required during the AGESA
  • 22:32 - 22:37
    BootLoader stage. And then, we have 18
    left, and these we don't know about yet
  • 22:37 - 22:42
    because they are not called at all or
    they have exactly one call site and are
  • 22:42 - 22:46
    non-trivial to reverse-engineer.
  • 22:46 - 22:49
    So, "System Management Network".
    I already saw on the
  • 22:49 - 22:53
    slide already that there was access SMN.
    If you Google for "System Management
  • 22:53 - 22:58
    Network" or SMN, you won't find much
    information about it by AMD or otherwise.
  • 22:58 - 23:02
    The only reference you may find is code in
    the Linux kernel to read out the thermal
  • 23:02 - 23:07
    sensors on the CPU. So the System
    Management Network actually is a hidden
  • 23:07 - 23:11
    control network inside your CPU. Each and
    every hardware block which is in there is
  • 23:11 - 23:16
    connected to it and is used for the PSP to
    control and initialize the hardware blocks
  • 23:16 - 23:21
    during the boot up phase. So it is a
    dedicated address space, so the PSP can't
  • 23:21 - 23:27
    directly access it using MMIO
    instructions. And we have the PSP there.
  • 23:27 - 23:31
    We have identified the memory controller,
    the System Management Unit for which there
  • 23:31 - 23:36
    was a talk about I think two years ago on
    this very Congress, the x86 cores are
  • 23:36 - 23:41
    there as well and a lot of other things we
    didn't reverse engineer so far. One other
  • 23:41 - 23:46
    thing. OK. So to access the System
    Management Network, the PSP has to map a
  • 23:46 - 23:50
    certain region of the System Management
    Network address space into its own address
  • 23:50 - 23:54
    space and then can access the register,
    write, read and so on. And it has to unmap
  • 23:54 - 23:58
    it again. And one of the functions we
    identified is what we call memory
  • 23:58 - 24:05
    protection slots. So the PSP has the
    possibility [stutters] to configure the
  • 24:05 - 24:10
    memory controller, to revoke access to
    certain regions of the DDR4 memory from
  • 24:10 - 24:14
    the x86 cores. This is done by using three
    registers. We have a start register with a
  • 24:14 - 24:18
    physical start address, an end register to
    denote the physical end address of the
  • 24:18 - 24:23
    region you want to protect, and a control
    register where we only know yet so far the
  • 24:23 - 24:27
    enable bit to flip it on or off. And what
    it does is, if the protection is flipped
  • 24:27 - 24:31
    on, the x86 will only read "all bits
    set"[?] when it tries to access this
  • 24:31 - 24:36
    particular region and writes will have no
    effect through this region as well. And
  • 24:36 - 24:41
    this is, for example, used for the system
    management mode UEFI code, and for certain
  • 24:41 - 24:45
    functionality for the Secure Encrypted
    Virtualization feature of AMD.
  • 24:47 - 24:50
    So, the next thing we did was running
  • 24:50 - 24:54
    [the] `strings` [command] over all
    modules, obviously. And, what we found
  • 24:54 - 24:58
    there were a lot of interesting debug
    strings and even a lot of format strings.
  • 24:58 - 25:02
    And, we wanted to know what the values
    were during the runtime. So, when we
  • 25:02 - 25:06
    disassembled the firmware and analyzed it,
    we saw that most of these strings were
  • 25:06 - 25:10
    referenced right before a special call
    called SVC 6, so this must be some sort of
  • 25:10 - 25:16
    debug print for the PSP. The problem is,
    SVC 6 is not implemented in the release
  • 25:16 - 25:22
    firmware. So, we had to find another way
    to gain access to these debug strings. And
  • 25:22 - 25:29
    this is what I will talk about now. So,
    the problem here is, first we need to know
  • 25:29 - 25:35
    where we want to store these debug strings,
    and we don't have any x86 memory available
  • 25:35 - 25:39
    at this time in the process. So we need to
    find another device or buffer where you
  • 25:39 - 25:45
    can store it for later use. But, the only
    device we did know about at this time was
  • 25:45 - 25:51
    the SPI flash. Luckily for us, right into
    this SPI flash area from, the PSP
  • 25:51 - 25:58
    generated the necessary bus cycles on the
    SPI bus, without altering the flash. Then
  • 25:58 - 26:02
    we need a code execution on the PSP to
    inject our own SVC handler. And how we
  • 26:02 - 26:06
    gained code execution, Robert will talk
    about in the third part of this talk. But
  • 26:06 - 26:10
    for now, we assume that we have code
    execution on the PSP already, can inject
  • 26:10 - 26:17
    our own SVC 6 handler and then leave, let
    it run. So the app will call SVC 6, it
  • 26:17 - 26:20
    will be forwarded on to the SPI bus where
    we can collect it with our already
  • 26:20 - 26:26
    existing setup. [We] use a tool to filter
    the debug strings from the rest of the
  • 26:26 - 26:31
    traffic on the SPI bus [that] we don't
    want to have [...] in the debug output and
  • 26:31 - 26:39
    then hopefully get a raw PSP log. And we
    had success with that. So what you see
  • 26:39 - 26:44
    here is the initial boot-up or the very
    first stage of the boot-up state. The logs
  • 26:44 - 26:49
    are several megabytes long and we didn't
    have the chance to go through all of them.
  • 26:49 - 26:57
    So, there is a lot of interesting stuff
    hiding there already.
  • 26:57 - 27:05
    applause
    So, the next step was to explore what is
  • 27:05 - 27:10
    hidden inside the System Management
    Network. And we didn't want to always
  • 27:10 - 27:13
    reflash the whole system all the time and
    write code for it, debug, because that is
  • 27:13 - 27:21
    error prone and tedious. So we created our
    own setup where we could dynamically use
  • 27:21 - 27:25
    the x86 calls on the system to write and
    read from the System Management Network.
  • 27:25 - 27:30
    For that, we replaced the SEV app with a
    stub and the stub provides three
  • 27:30 - 27:33
    primitives. We can read-write a System
    Management Network address, we can execute
  • 27:33 - 27:38
    an arbitrary syscall from the off-chip
    bootloader and we can read-write general
  • 27:38 - 27:45
    PSP memory. And because the PSP is exposed
    as a separate PCIe device to the x86, we
  • 27:45 - 27:50
    use the existing Linux kernel driver and
    modified it to expose these requests to
  • 27:50 - 27:54
    user land, where we created a user space
    library wrapper and some Python bindings.
  • 27:54 - 27:59
    And with that we were able to use a Python
    shell to dynamically read, write
  • 27:59 - 28:03
    registers, headers, spurious reboot in
    between if you did the wrong thing, but
  • 28:03 - 28:07
    could start over very quickly. So what you
    see here in the code snippet is, what we
  • 28:07 - 28:12
    did to discover what these memory
    protection slots where about. You can see
  • 28:12 - 28:16
    that we call an syscall handler, that we
    write some System Management Network
  • 28:16 - 28:21
    address and so on. And we do it for all
    the different PSPs in the system, so the
  • 28:21 - 28:26
    master PSP can also forward these requests
    to all of the other PSPs in the whole
  • 28:26 - 28:34
    system. Next thing, we wanted to also
    analyze the SEV app further and see how
  • 28:34 - 28:40
    the code is executed and how the data
    flows in this SEV app. But because we
  • 28:40 - 28:44
    already had a PSP stub running there and
    couldn't share it on the PSP, we had to
  • 28:44 - 28:49
    find another method. And we created a PSP
    emulator for that and using our
  • 28:49 - 28:55
    libpspproxy to forward requests onto the
    PSP. So the current state can run the SEV
  • 28:55 - 29:01
    app to a certain point and we are still
    actively developing that. So, that started
  • 29:01 - 29:09
    a few weeks ago, and this will continue in
    the development. So, what it does is, what
  • 29:09 - 29:13
    you see here is the AMD sev-tool to manage
    the host and configure all the keys and
  • 29:13 - 29:16
    certificates on the system. And we
    modified the Linux kernel driver to
  • 29:16 - 29:21
    reroute these requests out to our own PSP
    emulator running in user space, which is
  • 29:21 - 29:25
    based on the unicorn engine. Any hardware
    access, because we don't know much about
  • 29:25 - 29:29
    the hardware yet, is forwarded to the real
    PSP, results are collected, and when the
  • 29:29 - 29:35
    SEV app finishes, it will return the
    result back to the AMD sev-tool. And with
  • 29:35 - 29:40
    that we are able to execute some of the
    requests the SEV app implements
  • 29:40 - 29:46
    successfully so far. Yeah. What you see
    here is a small snippet from one of the
  • 29:46 - 29:51
    traces. You can see a syscall being made.
    It's a CCP request. We don't know
  • 29:51 - 29:55
    exactly how the arguments are used by now.
    That's why there's a lot of unknown stuff,
  • 29:55 - 30:00
    but this will aid us in development. And
    furthermore, in addition to allowing a
  • 30:00 - 30:04
    tracing code execution and observe the
    data flow, we later on may be able to
  • 30:04 - 30:08
    provide functionality which is currently
    only available on the EPYC server platform
  • 30:08 - 30:13
    from AMD, like Secure Encrypted Virtual
    machine. The problem here is we don't know
  • 30:13 - 30:16
    yet if all the hardware is there which is
    supported, and whether it's only a
  • 30:16 - 30:18
    firmware limitation by AMD.
  • 30:21 - 30:25
    If you're interested, the code is here
    on the repository,
  • 30:25 - 30:28
    it will be made available in
    the next few days. We have a number of
  • 30:28 - 30:33
    repositories available. You already saw
    PSPTool. We have some repository where we
  • 30:33 - 30:37
    collect documentation about hardware
    interfaces, syscalls and so on. We have
  • 30:37 - 30:42
    our PSP emulator there and also the psp-
    apps repository, if you want to dive into
  • 30:42 - 30:47
    writing your own apps for the PSP. And
    with that I will hand over to Robert, who
  • 30:47 - 30:52
    will talk about how we gained code
    execution on the PSP itself.
  • 30:52 - 30:59
    applause
  • 30:59 - 31:02
    Robert: OK, so for everything that Alex
    talked about,
  • 31:02 - 31:15
    we need code execution on the PSP.
    … [inaudible]. Mike? Better? All right.
  • 31:15 - 31:22
    So, this part of owning the PSP is again
    split into two parts. Now, Christian
  • 31:22 - 31:27
    already talked about the firmware and the
    SPI flash. So, this is something we can
  • 31:27 - 31:31
    control because we have physical access to
    the device. We can flash everything we
  • 31:31 - 31:37
    want. So, what can we do with that? So, on
    the SPI flash, we have these directories
  • 31:37 - 31:42
    which have a header and entries and an
    entry is actually compromised (composed)
  • 31:42 - 31:48
    of an ID, an address and a size. We've
    talked about files. So an entry could be a
  • 31:48 - 31:54
    reference to a file. And, we also talked
    about these secondary directories. So, an
  • 31:54 - 31:59
    entry could refer to another directory.
    Now, if you look at the files you see that
  • 31:59 - 32:04
    they have a signature usually. So, we
    cannot manipulate those files directly. If
  • 32:04 - 32:08
    we touch them, this will be noticed and
    they won't be loaded and the system will
  • 32:08 - 32:14
    immediately reboot. Now, what we can
    manipulate is the directories themselves,
  • 32:14 - 32:19
    because they are not protected at all. So,
    specifically, what we can do is, we can,
  • 32:19 - 32:25
    for example, add additional entries. These
    entries might point to the same files.
  • 32:25 - 32:29
    That doesn't matter. We can add entries.
    What we also can do is, we can remove some
  • 32:29 - 32:36
    of those entries or we can change entries.
    So, for example, this reference to the
  • 32:36 - 32:41
    secondary directory, this has a size
    parameter. Right. And this size refers to
  • 32:41 - 32:44
    the size of that directory. And actually,
    what we can do is, we can change that
  • 32:44 - 32:49
    size. So we can make the directory appear
    to be smaller without removing any of
  • 32:49 - 32:57
    those entries. Now, during boot, this PSP
    directory, that Christian already talked
  • 32:57 - 33:03
    about, is parsed. So this PSP directory
    contains, among other things, the
  • 33:03 - 33:07
    reference to the AMD public key, which is
    used to authenticate all the applications
  • 33:07 - 33:13
    which are loaded. Now, this directory also
    has a secondary directory. The content is
  • 33:13 - 33:19
    not really relevant here. So the on-chip
    bootloader that executes first will set up
  • 33:19 - 33:24
    this boot ROM service page that Alex
    talked about. And this boot ROM service
  • 33:24 - 33:32
    page contains a copy of those directory
    entries, just for the first directory. And
  • 33:32 - 33:36
    also the on-chip bootloader will copy the
    AMD public key itself to the boot room
  • 33:36 - 33:43
    service page. So it only copies the AMD
    public key if it's been verified before.
  • 33:43 - 33:48
    OK. So now this boot room service page
    contains this AMD public key and this
  • 33:48 - 33:54
    public key in memory is from then on used
    to authenticate applications. So the off-
  • 33:54 - 34:00
    chip bootloader, which executes later,
    will use that boot ROM service page and
  • 34:00 - 34:05
    will extend it. Specifically, it will copy
    the entries of the secondary directory to
  • 34:05 - 34:11
    that boot ROM service page. So I guess you
    can already see where this is going.
  • 34:11 - 34:16
    So, what could possibly go wrong here?
    Laughter
  • 34:16 - 34:21
    Well, we have space for 64 entries here.
    And if
  • 34:21 - 34:27
    we write more entries to that page, we'll
    hit the AMD public key. So the off-chip
  • 34:27 - 34:32
    bootloader should better check that we
    only copy at most 64 entries. There it is.
  • 34:32 - 34:37
    There is a check. Let's say this is the
    function that appends entries and it says:
  • 34:37 - 34:43
    okay, if the number of entries exceeds 64,
    we return an error code and do not copy.
  • 34:43 - 34:49
    Sounds good. Thing is, that number refers
    to the number of entries in the secondary
  • 34:49 - 34:57
    directory. So this has a maximum size of
    64. But there is already space, there are
  • 34:57 - 35:01
    entries there on this boot ROM service
    page. So, actually, what we enforce with
  • 35:01 - 35:08
    this check is, whatever we append can have
    at most 64 entries, and within that 64
  • 35:08 - 35:14
    entries, well, there's the AMD public key.
    Super convenient. So what we do now, we
  • 35:14 - 35:18
    place our own public key inside the
    directory structures of the firmware file
  • 35:18 - 35:25
    system. The off-chip bootloader copies the
    entries and copies the AMD public key.
  • 35:25 - 35:35
    Applause
    So what does it mean for us? Now, all this
  • 35:35 - 35:41
    parsing happens before the first
    application is loaded. So that means we
  • 35:41 - 35:46
    control the very first application and can
    replace the content. And from there on, we
  • 35:46 - 35:50
    control the userland part of the Secure
    Processor.
  • 35:51 - 35:54
    So, now coming to the next part.
  • 35:54 - 36:00
    So, the natural next target is, of course,
    I mean, we have userland code execution,
  • 36:00 - 36:07
    we want to have the rest. Kernel mode. So,
    how can we take over the kernel mode? Now,
  • 36:07 - 36:11
    let's have a look at how this distinction
    between kernel and user mode happens. So,
  • 36:11 - 36:16
    if we look at the virtual memory layout,
    we'll see that there is a user mode part
  • 36:16 - 36:22
    and a fixed split with the kernel mode
    where our off-chip bootloader resides. So,
  • 36:22 - 36:27
    our application, which we already control,
    can try to access that memory, of course,
  • 36:27 - 36:30
    but that won't work. Right. The MMU
    will prevent any access to privileged
  • 36:30 - 36:40
    memory. Okay. So let's see how this works
    at runtime. So, this bootloader component,
  • 36:40 - 36:44
    if we specify the privileged memory a
    little bit more, we have code and data
  • 36:44 - 36:49
    there. And at runtime another type of
    directory is parsed. And this is called
  • 36:49 - 36:53
    the BIOS directory. I mean, it's a similar
    structure as the directory before. We have
  • 36:53 - 36:58
    entries and the reference to a secondary
    directory. The entries here, again, of no
  • 36:58 - 37:05
    relevance. So during boot, the off-chip
    bootloader will copy those entries into
  • 37:05 - 37:10
    its data section. OK? So, for the copy
    operation, we need some some information.
  • 37:10 - 37:16
    So, let's say this is the copy operation,
    kind of looks like `memcopy`. What we need
  • 37:16 - 37:21
    is destination, where to copy? We need
    source. This is the secondary directory,
  • 37:21 - 37:27
    this is the thing we want to copy, which
    is already under our control. So,
  • 37:27 - 37:33
    convenient, we control whatever data is
    copied. And, we need a size value. So,
  • 37:33 - 37:40
    where do we get that size? Oh yeah, this
    entry here has a size value. Super. It's
  • 37:40 - 37:45
    ours also, right? We control the directory
    structures. We can manipulate the size. So
  • 37:45 - 37:49
    to sum up, we have a copy operation into
    privileged memory with attacker-controlled
  • 37:49 - 37:57
    data and attacker-controlled size. This is
    a very old meme, and I think it's
  • 37:57 - 38:02
    appropriate because this this bug is so
    easy to prevent, actually. But for us it's
  • 38:02 - 38:10
    good, because now we control everything in
    red here. So, we control that part. The
  • 38:10 - 38:16
    thing is, as you can see, code is not part
    of what we control. So, what might be here?
  • 38:16 - 38:27
    What is of interest for us to overwrite?
    Thing is, it's the page tables. The page
  • 38:27 - 38:31
    tables are part of the data section within
    the privileged part of the virtual memory
  • 38:31 - 38:37
    space. So again, what we do, we place our
    own page tables here. The data is copied
  • 38:37 - 38:42
    and replaces the page tables in memory of
    the Secure Processor. So, now, if we look
  • 38:42 - 38:48
    at that virtual memory overview again,
    well, our page tables define the virtual
  • 38:48 - 38:54
    memory a bit different. We make everything
    user-writeable. So, we control the
  • 38:54 - 38:59
    application, our application now can touch
    the privileged memory and just overwrite
  • 38:59 - 39:04
    everything there, if we want to. For that,
    we need to reimplement everything. But, we
  • 39:04 - 39:10
    can patch now the Secure Operating System,
    if we want.
  • 39:10 - 39:17
    Applause
  • 39:17 - 39:19
    So, that means, this parsing of the
  • 39:19 - 39:23
    directory also happens before the first
    application. So, we control the first
  • 39:23 - 39:28
    application, that takes over the
    bootloader, if you want. And from there
  • 39:28 - 39:34
    on, we have everything. All those issues I
    presented were fixed, were even fixed
  • 39:34 - 39:39
    before we discovered them. Right? So, we
    might not be the first one that discovered
  • 39:39 - 39:43
    them. Some of you (may) remember that
    there was some web site called
  • 39:43 - 39:49
    AMDFlaws[.com]. They did not present too
    many technical details. Maybe what they
  • 39:49 - 39:55
    discovered was something I present here. I
    don't know. Thing is, it does not really
  • 39:55 - 39:58
    matter for us because the Secure Processor
    does not implement any rollback
  • 39:58 - 40:04
    prevention. So we can always go back and
    refresh a vulnerable firmware. And from
  • 40:04 - 40:12
    that, use whatever code we want to place
    there. So, what what we did is, we used
  • 40:12 - 40:19
    all this on an Epyc Naples based server
    system. And, you cannot just use that
  • 40:19 - 40:25
    issue on every AMD system, because the
    bootloader we're using was signed with a
  • 40:25 - 40:32
    key specific for the Epyc Naples CPU
    series. However, we believe, we have not
  • 40:32 - 40:36
    tested it thoroughly yet, but we believe
    the same kind of issues exist in
  • 40:36 - 40:43
    bootloaders which are signed with a Ryzen
    first generation key. And, for the rest,
  • 40:43 - 40:48
    we don't know yet. So, maybe for
    Threadripper or Epyc Rome, there are
  • 40:48 - 40:54
    similar issues, maybe not. We don't know.
    So the question is, is this really a
  • 40:54 - 41:00
    security issue? I mean, of course it's a
    security issue, but, for whom? So,
  • 41:00 - 41:07
    everything we did requires physical access
    to the device. So, if it were my laptop,
  • 41:07 - 41:13
    personally, I wouldn't be concerned too
    much. However, there are some things where
  • 41:13 - 41:18
    this is a real issue. For example, if you
    rely on Secure Boot. Because the Secure
  • 41:18 - 41:22
    Processor is the first part that boots up,
    and if that is broken, everything later on
  • 41:22 - 41:28
    is also broken. So, Christian already told
    you that AMD plans to use this Secure
  • 41:28 - 41:32
    Processor [as] a trusted execution
    environment. If your application relies on
  • 41:32 - 41:38
    that, you better not have any security
    issues in that Secure Processor. And, for
  • 41:38 - 41:44
    the last part, the Secure Encrypted
    Virtualization technology from AMD is
  • 41:44 - 41:49
    dependent on the integrity of the Secure
    Processor. If that is broken, this
  • 41:49 - 41:54
    technology is also broken. So, Christian
    and I published a paper about that. If
  • 41:54 - 42:00
    you're interested, you can read it up.
    But, for us here, this is actually more of
  • 42:00 - 42:05
    an opportunity, right? Because we can gain
    more insight into this PSP with code
  • 42:05 - 42:11
    execution. We can do a lot of cool things
    with that. So, it allows to do further
  • 42:11 - 42:16
    research on other subsystems which are
    present in the AMD CPUs. For example, the
  • 42:16 - 42:22
    PSP is responsible to load the SMU
    firmware. The PSP allows access to the SMM
  • 42:22 - 42:29
    mode. So, this is a "ring -2 mode" on the
    x86 CPUs. So, [it is] higher privileged
  • 42:29 - 42:35
    than your kernel, and there is proprietary
    code running in that mode. With the PSP,
  • 42:35 - 42:41
    you have access to that code and could
    replace it, analyze it, whatever. And, the
  • 42:41 - 42:44
    PSP is responsible to kick off the x86
    calls at all. So everything that comes
  • 42:44 - 42:51
    later is, in theory, now under our
    control. Thank you. That's it.
  • 42:51 - 43:00
    Applause
  • 43:00 - 43:04
    Herald: Yes. Thank you very much, Robert,
    Alexander and Christian. That was
  • 43:04 - 43:10
    fantastic. Wow. I have a lot of questions
    I guess [in my?] head going on. But do we
  • 43:10 - 43:14
    have any questions from the audience? And
    if you have any questions, we have
  • 43:14 - 43:18
    microphones lined up here. A question is,
    just so that you know what we're talking
  • 43:18 - 43:23
    about with questions, is a sentence with a
    question mark behind it and not your life
  • 43:23 - 43:29
    story. And I think I saw number one first.
    So, let's start with number one.
  • 43:29 - 43:35
    Mic 1: Hey, is there a reason why the page
    table is located at the end of the data
  • 43:35 - 43:38
    segment?
    Robert: I don't think so. I mean, ...
  • 43:38 - 43:41
    Mic 1: "Just because"?
  • 43:41 - 43:45
    Robert: You have to place it somewhere.
    should be in the [interrupted]
  • 43:45 - 43:49
    Mic 1: Why not in the beginning?
    Robert: I don't know. No idea.
  • 43:49 - 43:53
    Herald: That's what I meant with "a lot of
    weird questions" here. From the signal
  • 43:53 - 43:56
    angel we had one question.
    Signal Angel: And this question goes to
  • 43:56 - 44:02
    the first lecturer. Didn't you have access
    to an SPI flasher relay(?) to attempt a
  • 44:02 - 44:07
    "Time of Use versus Time of Check"
    [TOCTOU] attack?
  • 44:07 - 44:14
    Christian: So, we had access to different
    tools, but the TOCTOU attack that you
  • 44:14 - 44:21
    mentioned was not even necessary to mount
    the attacks we talked about. And actually
  • 44:21 - 44:27
    so far, we don't see any possibility to
    mount a TOCTOU attack.
  • 44:27 - 44:34
    Herald: OK. So I think I saw microphone 5
    next up. Is there somebody at the
  • 44:34 - 44:37
    Microphone?
    Mic 5: Yes. So, I was wondering if you
  • 44:37 - 44:40
    considered looking at the boot ROM for
    issues.
  • 44:40 - 44:49
    Robert: Yes, of course. The thing is, we
    cannot find its code in the memory any
  • 44:49 - 44:56
    more after we mounted our attacks. So, I
    believe, the boot ROM code is not there
  • 44:56 - 45:03
    anymore, which would make it much easier
    to analyze. We tried simple things, like
  • 45:03 - 45:09
    increasing directory sizes, which are
    processed by the boot ROM itself. We
  • 45:09 - 45:13
    haven't found any suspicious thing there,
    yet.
  • 45:13 - 45:18
    Herald: Microphone 2.
    Mic 2: Thanks for your research. You have
  • 45:18 - 45:26
    really nice big power over the system
    right now. Do you have plans to make a PSP
  • 45:26 - 45:36
    firmware which is minimal and which makes
    your system work, but without some strange
  • 45:36 - 45:43
    untrusted code?
    Robert: I wouldn't call it plans yet. Of
  • 45:43 - 45:47
    course there are ideas to do that. The
    thing is, some of the functionality which
  • 45:47 - 45:52
    is implemented from AMD is really
    required. So, the stages that Alex talked
  • 45:52 - 45:58
    about, they configure and train(?) your
    DRAM. So without those stages, you don't
  • 45:58 - 46:05
    have access to memory. Your x86 cores
    wouldn't work. And to reimplement that
  • 46:05 - 46:10
    without having access to any manuals is
    really, really hard work. So, I'm not too
  • 46:10 - 46:14
    confident that this will be possible in
    the near future.
  • 46:14 - 46:19
    Mic 2: I just refer to a Management Engine
    cleaner, and there is such a project,
  • 46:19 - 46:24
    which makes your Management Engine
    firmware slim.
  • 46:24 - 46:30
    Robert: So, the AMD firmware is already
    kind of slim. The only thing that is not
  • 46:30 - 46:36
    strictly required on the systems we have
    been looking at would be the SEV firmware,
  • 46:36 - 46:41
    which is loaded on request, and you can,
    like, disable that by just flipping a bit
  • 46:41 - 46:47
    inside that file. The system would still
    boot, but when it tries to initialize the
  • 46:47 - 46:52
    SEV technology, the kernel would say, "OK.
    This does not work." The system will still
  • 46:52 - 46:56
    work after that.
    Mic 2: Thanks. And last little question.
  • 46:56 - 47:03
    Does PSP work with microcode somehow?
    Alexander: We didn't find anything related
  • 47:03 - 47:06
    to any microcode there so far.
    Mic 2: Thanks.
  • 47:06 - 47:12
    Herald: So let's move on to Microphone 3.
    Mic 3: Thank you first for the great talk.
  • 47:12 - 47:18
    I have one question. Do you have maybe
    found something evil or potentially evil
  • 47:18 - 47:24
    in the code that it does?
    Alexander: No. So far, they didn't find
  • 47:24 - 47:30
    anything which could be used for an
    attack, for example. So, what the PSP
  • 47:30 - 47:36
    might be able to do is, access PCIe
    devices. We found some code related to
  • 47:36 - 47:41
    that, but we are [stutters] not sure yet
    whether it's actually used, because also
  • 47:41 - 47:47
    the PSPs executed or is existing on graphics
    cards made by AMD. So, that might be also
  • 47:47 - 47:51
    ready to[?] that. We couldn't find
    anything there yet, but so far, the PSP
  • 47:51 - 47:54
    looks rather clean compared to the entire
    Management Engine.
  • 47:54 - 47:58
    Mic 3: Thank you.
    Herald: So, we have a question from the
  • 47:58 - 48:03
    Internet.
    Signal: Is the AMD public key an RSA one,
  • 48:03 - 48:09
    only 576 bits?
    Robert: It's an RSA key, yes, but it's
  • 48:09 - 48:17
    2048 bits for the first generation Epyc
    CPUs and I think 4069 [meaning 4096] for
  • 48:17 - 48:20
    later generations.
    Herald: Microphone 2.
  • 48:20 - 48:27
    Mic 2: For me, it seems like preventing to
    flash old vulnerable firmware is really
  • 48:27 - 48:33
    important for a scenario like Secure
    Encrypted Virtualization. Can you comment
  • 48:33 - 48:40
    on how difficult it is for AMD to add this
    retrospectively?
  • 48:40 - 48:48
    Robert: Okay. So technically, rollback
    prevention is there for, I guess, mobile
  • 48:48 - 48:53
    devices, for example. You have that. It
    should be possible. For adding this
  • 48:53 - 48:57
    functionality afterwards, I don't think
    that's really possible, because the on-
  • 48:57 - 49:03
    chip bootloader is the thing that loads
    the off-chip bootloader and verifies it.
  • 49:03 - 49:09
    And that software component has to, like,
    stop loading if the firmware version does
  • 49:09 - 49:14
    not match, for example. And you have to
    change that. And that functionality is not
  • 49:14 - 49:19
    there and you cannot update the on-chip
    boot ROM. So, in that sense, I don't think
  • 49:19 - 49:24
    that that's possible to change. And if you
    look at our paper, you will see that the
  • 49:24 - 49:29
    former issues are kind of devastating for
    the SEV technology, because there are some
  • 49:29 - 49:36
    keys which are now accessible, which can
    be used for attacking SEV-protected
  • 49:36 - 49:39
    guests.
    Mic 2: Thanks.
  • 49:39 - 49:45
    Herald: Microphone 3, please.
    Mic 3: One question. Did you analyze the
  • 49:45 - 49:55
    API to the x86 core? Did you find anything
    that could be exploited without flashing
  • 49:55 - 50:00
    anything so that you could directly go
    from x86 to PSP exploitation?
  • 50:00 - 50:07
    Alexander: Yeah, we tried to find the
    necessary code to interface with the x86.
  • 50:07 - 50:12
    We think we found one place where the x86
    cores are released after the PSP
  • 50:12 - 50:16
    initialized the whole system. But
    obviously, we can't do much with it except
  • 50:16 - 50:22
    preventing the x86 to boot at all. And
    otherwise we couldn't find anything there
  • 50:22 - 50:27
    yet. So we focused on, on a bit of other,
    like the memory controller, and didn't
  • 50:27 - 50:33
    have a deeper look at the x86 interface.
    So what there is, the BIOS can interface
  • 50:33 - 50:39
    with the PSP using a special mailbox
    register which is mapped in MMIO space in
  • 50:39 - 50:44
    x86 for requests. So, it can, for example,
    the UEFI init boots, it will say to the
  • 50:44 - 50:48
    PSP "Hey, this is my system management
    mode code region, please protect that for
  • 50:48 - 50:53
    me" and it will execute this request. But
    apart from that, we couldn't find anything
  • 50:53 - 50:55
    so far.
    Mic 3: Thank you.
  • 50:55 - 51:00
    Herald: So, Microphone 4.
    Mic 4: Hi. So, is it correct that your
  • 51:00 - 51:09
    work enables 100% open source firmware for
    this kind of processors? And if so, have
  • 51:09 - 51:13
    you already contacted the CoreBoot team to
    make that actually happen?
  • 51:13 - 51:22
    Robert: So. 100 percent open source. As
    for the PSP, there is this on-chip boot
  • 51:22 - 51:27
    ROM which we can't replace, right? So,
    this will be closed source. Then there is
  • 51:27 - 51:33
    code of the off-chip bootloader, until the
    first exploit, which runs, which is not
  • 51:33 - 51:39
    open source. In theory, you could from now
    on take over the PSP, write your own code.
  • 51:39 - 51:44
    But, as I said before, you have to
    reimplement a lot of functionality without
  • 51:44 - 51:49
    having any documentation, right? So,
    technically it's possible, I guess, to do
  • 51:49 - 51:54
    something like that. Practically, I'm not
    too sure.
  • 51:54 - 51:57
    Herald: So we're gonna go to the internet
    for another question.
  • 51:57 - 52:03
    Signal: Is it possible to block PSP from
    within Linux or BSD, for the system's
  • 52:03 - 52:09
    runtime, by using search and boot flags?
    Robert: Sorry, to block what?
  • 52:09 - 52:15
    Signal: To block the PSP from the Linux or
    BSD.
  • 52:15 - 52:20
    Alexander: So, what you can do is, like
    Robert mentiond already, you can flip a
  • 52:20 - 52:25
    bit in the SPI flash and then the PSP,
    once it initialized the whole system, it
  • 52:25 - 52:30
    won't run the SEV app, for example,
    because the signatures won't match
  • 52:30 - 52:36
    anymore. And there is no other sort of
    interface where the PSP is actually
  • 52:36 - 52:41
    triggered. Or we couldn't find it so far.
    Herald: Microphone 3.
  • 52:41 - 52:46
    Someone: I think he was first.
    Herald: Oh, okay, all right. Right.
  • 52:46 - 52:49
    Microphone 2 then. Sorry.
    Mic 2: Did you try to enable any
  • 52:49 - 52:56
    superpowers from PSP like JTAG or special
    tricks with voltage or something else?
  • 52:56 - 53:02
    Robert: When the first application that is
    loaded has some strings in it like Debug
  • 53:02 - 53:08
    Unlock. Sounds interesting. But then
    again, JTAG, where would you access the
  • 53:08 - 53:13
    JTAG of the PSP? You need to have some
    connection to the lines, right?
  • 53:13 - 53:18
    Mic 2: Intel supports USB debugging.
    Robert: Yeah, I know. With special
  • 53:18 - 53:21
    devices, right?
    Mic 2: No, even wire cable.
  • 53:21 - 53:27
    Robert: Okay. So anyhow, I have the
    suspicion that this DebugUnlock app is
  • 53:27 - 53:32
    responsible to to allow some debug mode.
    Which then, I assume, with special
  • 53:32 - 53:37
    hardware, you can have JTAG. But we have
    not touched it yet.
  • 53:37 - 53:39
    Mic 3: Thanks.
    Herald: Now Microphone 3
  • 53:39 - 53:46
    Mic 3: So I'm as far from a liar
    laughing, um, a lawyer as possible, but
  • 53:46 - 53:52
    could AMD in any way file a cease and
    desist for anything you do?
  • 53:52 - 53:57
    Robert: Probably not, I guess.
    Mic 3: Just curious.
  • 53:57 - 54:01
    Robert: I have no idea.
    Mic 3: Thank you.
  • 54:01 - 54:07
    Robert: And, as I said before, we're not
    the ones that initially discovered, or
  • 54:07 - 54:10
    probably not the ones that initially
    discovered these issues. And it's not
  • 54:10 - 54:16
    really about these issues. I mean, for me
    personally, these issues are a nice way to
  • 54:16 - 54:21
    get more insight into the PSP. And it's
    not about having the super new security
  • 54:21 - 54:26
    issue, whatever. So if AMD wants to file
    something, I guess they would have also
  • 54:26 - 54:33
    filed other people that did similar
    research before. Maybe they did. I don't
  • 54:33 - 54:35
    know.
    Herald: So we had another question from
  • 54:35 - 54:38
    the Internet.
    Signal: How long did it take you to
  • 54:38 - 54:43
    reverse engineer and develop all this
    stuff?
  • 54:43 - 54:52
    Robert: So I think beginning of 2018,
    Christian was starting with his master's
  • 54:52 - 54:58
    thesis. And we spent a lot of time on
    figuring out how this firmware file system
  • 54:58 - 55:04
    works, and the boot process and writing
    these PSPTrace and PSPtool to better
  • 55:04 - 55:12
    understand the components of the firmware.
    And Alex joined in May, May-ish this year.
  • 55:12 - 55:19
    And, well, we're still working on it,
    right? So the emulator, once we figured
  • 55:19 - 55:26
    out a lot of information about the PSP, I
    think the emulator was easy to develop,
  • 55:26 - 55:31
    in the sense that it didn't take too
    much time. But of course, there was a lot
  • 55:31 - 55:38
    of work going into it before that.
    Herald: So I do not see, oh yes I do see
  • 55:38 - 55:40
    another question from the internet. Let's
    go for that.
  • 55:40 - 55:45
    Signal: Yeah, last question. Did you try
    to glitch the PSP by manipulating the
  • 55:45 - 55:54
    voltage of the socket(?)?
    Robert: Why? I think our approach is
  • 55:54 - 56:00
    easier, but no, seriously, we did not try.
    Herald: So with that, I don't see any
  • 56:00 - 56:06
    further questions. And I would like you to
    help me thank Robert, Alexander and
  • 56:06 - 56:08
    Christian for this fantastic talk.
  • 56:08 - 56:10
    postroll music
  • 56:10 - 56:21
    Subtitles created by c3subtitles.de
    in the year 2020. Join, and help us!
Title:
36C3 - Uncover, Understand, Own - Regaining Control Over Your AMD CPU
Description:

more » « less
Video Language:
English
Duration:
56:37

English subtitles

Revisions