4 ms·

I'm always mildly surprised to find people posturing that having closed source modules in the CPU is completely intolerable while basically all modern hardware

by simias 9y ago

I'm always mildly surprised to find people posturing that having closed source modules in the CPU is completely intolerable while basically all modern hardware is closed source. Even if they release the source code for the PSP they won't release the verilog of the underlying IP to see how it's implemented. And you'd still run a closed source CPU, with a closed source GPU and a closed source USB controller and a closed source PCI controller etc etc... How many of the people complaining about the lack of PSP source code are willingly running a closed source GPU driver? How many of them are running Windows, Mac OS or some other closed source operating system? It reminds me of when people were blowing a fuse over the linux kernel's use of Intel's built-in PRNG. I'm all for open hardware design but focusing on these particular modules is a bit counterproductive I think, if tomorrow AMD or Intel were to release CPUs without this particular "feature" the surface of attack would not shrink massively. Hardware is open or it's not. Nowadays it's overwhelmingly not open, so you have to blindly trust AMD, Intel and the variour ARM SoC vendors not to fuck you over[1] and having the PSP source code wouldn't change much about that. [1] They probably do.

Tharkun 9y ago
The scope matters. You can get a machine to run reasonably well without relying on closed source graphics drivers. If your GPU firmware is evil in some way, it's on your GPU and you can be pretty confident it won't compromise the rest of your machine or your network. If a driver is compromised, there will be signs of abnormal behaviour (you can inspect what software on your machine is doing at runtime). With AMD's PSP or Intel's ME, there are no such limitations in how bad things can get. These things could take all the data you have in memory, connect to some shady network location and dump all the data. All the while there is no trace of that activity in your OS, because of none of this nonsense lives in your OS.
- simias 9y ago
  I guess my point is that as long as the hardware itself is closed source you have to trust the vendor anyway. Suppose the PSP source code was open sourced, how can you be sure it's actually what's being run by the CPU? How can you know certain instructions aren't backdoored somehow? It makes it a bit more difficult to implement such backdoors of course, but it's still perfectly doable. Again, I'm happy that people value their privacy and campaign for more open source but it seems a bit myopic to put all our attention on this tiny part of the problem. The risk is that if tomorrow AMD decides to actually open source the PSP many people will think that we won and the battle is over when we've just removed one of thousands of possible attack vectors.
  - zanny 9y ago
    Analysts working on the Intel ME can test if its active by testing line voltages around he mainboard. Someone did manage to hard disable it, and it could be proven in how voltages dropped at various points on the motherboard. If all else fails it is still a physical piece of hardware.
    - simias 9y ago
      That's good, but then shouldn't we petition to have a way to physically disable these modules instead of begging for a source code that won't get us anywhere closer to a trusted computing environment? It's a lot easier to validate that something is not running than it is to validate that it's running correctly.
      - zanny 9y ago
        Disabling the ME / PSP usually breaks booting. It would require stripped down open source PSP / ME firmware anyway to bypass it during boot.
  - admax88q 9y ago
    > as long as the hardware itself is closed source you have to trust the vendor anyway Because it's an ongoing effort. Years ago people were running GNU software on proprietary kernels/operating systems. You can't get to fully free and open hardware in one step. Firmware is the next battlefield, and its an area that hardware manufacturers have been winning. The firmware on a modern machine is orders of magnitude larger than it was 10 years ago, while provided essentially the same features. More and more closed source code is running on your machine. If we don't push back sooner or later your linux install will only be running in a virtualized environment provided by the proprietary OS running in "firmware"
  - Karliss 9y ago
    Intentional hardware backdoors are hopefully small and made by somewhat competent people. Hardware vendors already can't be trusted with writing code that does something useful there is no need to have any additional attack surface in code that provides almost no valuable functionality.
- eropple 9y ago
  > If your GPU firmware is evil in some way, it's on your GPU and you can be pretty confident it won't compromise the rest of your machine or your network. How can you be confident of this when your GPU can DMA into anything?
  - em3rgent0rdr 9y ago
    of course if your GPU can DMA anything, then all bets are off. But provided you are in control of all pathways connecting to your GPU, and can bitsniff the traffic, then you can verify that it isn't doing anything that your open-source driver doesn't want it to.
    - eropple 9y ago
      Sure, if you do do that on every piece of hardware. Which means your drivers are all either sandboxed or formally verified, as are the parts of the kernel that touch them, and the parts that touch them... ...which is obviously not the world we live in.
  - nhaehnle 9y ago
    You can enable the IOMMU to prevent a PCI device from doing arbitrary DMA.
    - wolfgke 9y ago
      If you look at > https://en.wikipedia.org/w/index.php?title=List_of_IOMMU-supporting_hardware&oldid=790636784 https://en.wikipedia.org/w/index.php?title=List_of_IOMMU-sup... at least for Intel processors only the more expensive ones support IOMMU (Intel VT-d). On the other hand for modern AMD processors this feature seems to be commonly supported.
em3rgent0rdr 9y ago
Even if hardware is not open, hardware can be isolated. Then provided you are in control of the communication between the isolated hardware, you can be more certain that you are in control. Security through isolation doesn't require perfect security of the closed components. The problem with the management engine is that it can't be isolated.
- simias 9y ago
  As the trend is to integrate more and more IPs into System-on-Chips hardware isolation is not really a given nowadays. You still have external memory I suppose, but you can do a lot just messing with the caches and the rest of the pipeline especially when we have more "high level" instruction sets dealing with AES and other crypto algorithms natively. Also I don't really see how having access to the PSP source code would factor into that. As long as you can't prove that the management engine is really running that code unmodified and there's no hardware backdoor to change its behaviour it won't really get you anywhere.
  - em3rgent0rdr 9y ago
    Obviously if the hardware is all integrated together, then you can't do isolation as I described. However, in your parent comment you used the example of a GPU, which is something that can perfectly be fined be isolated, and provided you can write an open-source driver and can bitsniff all the data coming in and out of your untrusted GPU, then you can be reasonably sure it is not for instance sending your screen data to your network controller.

by simias 9y ago

Tharkun 9y ago

The scope matters. You can get a machine to run reasonably well without relying on closed source graphics drivers. If your GPU firmware is evil in some way, it's on your GPU and you can be pretty confident it won't compromise the rest of your machine or your network. If a driver is compromised, there will be signs of abnormal behaviour (you can inspect what software on your machine is doing at runtime). With AMD's PSP or Intel's ME, there are no such limitations in how bad things can get. These things could take all the data you have in memory, connect to some shady network location and dump all the data. All the while there is no trace of that activity in your OS, because of none of this nonsense lives in your OS.

simias 9y ago
I guess my point is that as long as the hardware itself is closed source you have to trust the vendor anyway. Suppose the PSP source code was open sourced, how can you be sure it's actually what's being run by the CPU? How can you know certain instructions aren't backdoored somehow? It makes it a bit more difficult to implement such backdoors of course, but it's still perfectly doable. Again, I'm happy that people value their privacy and campaign for more open source but it seems a bit myopic to put all our attention on this tiny part of the problem. The risk is that if tomorrow AMD decides to actually open source the PSP many people will think that we won and the battle is over when we've just removed one of thousands of possible attack vectors.
- zanny 9y ago
  Analysts working on the Intel ME can test if its active by testing line voltages around he mainboard. Someone did manage to hard disable it, and it could be proven in how voltages dropped at various points on the motherboard. If all else fails it is still a physical piece of hardware.
  - simias 9y ago
    That's good, but then shouldn't we petition to have a way to physically disable these modules instead of begging for a source code that won't get us anywhere closer to a trusted computing environment? It's a lot easier to validate that something is not running than it is to validate that it's running correctly.
    - zanny 9y ago
      Disabling the ME / PSP usually breaks booting. It would require stripped down open source PSP / ME firmware anyway to bypass it during boot.
- admax88q 9y ago
  > as long as the hardware itself is closed source you have to trust the vendor anyway Because it's an ongoing effort. Years ago people were running GNU software on proprietary kernels/operating systems. You can't get to fully free and open hardware in one step. Firmware is the next battlefield, and its an area that hardware manufacturers have been winning. The firmware on a modern machine is orders of magnitude larger than it was 10 years ago, while provided essentially the same features. More and more closed source code is running on your machine. If we don't push back sooner or later your linux install will only be running in a virtualized environment provided by the proprietary OS running in "firmware"
- Karliss 9y ago
  Intentional hardware backdoors are hopefully small and made by somewhat competent people. Hardware vendors already can't be trusted with writing code that does something useful there is no need to have any additional attack surface in code that provides almost no valuable functionality.
eropple 9y ago
> If your GPU firmware is evil in some way, it's on your GPU and you can be pretty confident it won't compromise the rest of your machine or your network. How can you be confident of this when your GPU can DMA into anything?
- em3rgent0rdr 9y ago
  of course if your GPU can DMA anything, then all bets are off. But provided you are in control of all pathways connecting to your GPU, and can bitsniff the traffic, then you can verify that it isn't doing anything that your open-source driver doesn't want it to.
  - eropple 9y ago
    Sure, if you do do that on every piece of hardware. Which means your drivers are all either sandboxed or formally verified, as are the parts of the kernel that touch them, and the parts that touch them... ...which is obviously not the world we live in.
- nhaehnle 9y ago
  You can enable the IOMMU to prevent a PCI device from doing arbitrary DMA.
  - wolfgke 9y ago
    If you look at > https://en.wikipedia.org/w/index.php?title=List_of_IOMMU-supporting_hardware&oldid=790636784 https://en.wikipedia.org/w/index.php?title=List_of_IOMMU-sup... at least for Intel processors only the more expensive ones support IOMMU (Intel VT-d). On the other hand for modern AMD processors this feature seems to be commonly supported.

em3rgent0rdr 9y ago

Even if hardware is not open, hardware can be isolated. Then provided you are in control of the communication between the isolated hardware, you can be more certain that you are in control. Security through isolation doesn't require perfect security of the closed components. The problem with the management engine is that it can't be isolated.

simias 9y ago
As the trend is to integrate more and more IPs into System-on-Chips hardware isolation is not really a given nowadays. You still have external memory I suppose, but you can do a lot just messing with the caches and the rest of the pipeline especially when we have more "high level" instruction sets dealing with AES and other crypto algorithms natively. Also I don't really see how having access to the PSP source code would factor into that. As long as you can't prove that the management engine is really running that code unmodified and there's no hardware backdoor to change its behaviour it won't really get you anywhere.
- em3rgent0rdr 9y ago
  Obviously if the hardware is all integrated together, then you can't do isolation as I described. However, in your parent comment you used the example of a GPU, which is something that can perfectly be fined be isolated, and provided you can write an open-source driver and can bitsniff all the data coming in and out of your untrusted GPU, then you can be reasonably sure it is not for instance sending your screen data to your network controller.