3 ms·

> And it shouldn't be too hard to find a GBit ethernet NIC without. Just wonder how exactly you going to check if hardware have firmware inside it.

by SXX 10y ago

creshal 10y ago
Good point. Usually the criterion is "can we send it a firmware blob? Can we send it an open-source firmware blob?". If you have a firmware that can't be replaced at all, it's usually handwaved away.
- SXX 10y ago
  This is main point of many developers we can speak with in public like AMD Linux graphics team. There is a lot of people who blame them for proprietary firmware, but in same time totally okay about using tons of devices that simply not expose way to replace their firmware.
wolfgke 10y ago
The criterion by the FSF is: If you can't replace the firmware (by somethings free), but someone else is able to change the firmware, the firmware has to be considered as malware.
- Someone 10y ago
  But how do you know? Even if you can flash new firmware, how do you know it is all the firmware? There may be a layer below what you can see, with its own CPU, memory, and firmware.
  - wolfgke 10y ago
    > But how do you know? Even if you can flash new firmware, how do you know it is all the firmware? There may be a layer below what you can see, with its own CPU, memory, and firmware. We have to differ here: First question is whether there is a deeper layer below and the other one whether there is additional hardware on the SoC which could also patch the (main) firmware (say: firmware update Over The Air (OTA)). I can only give my personal private opinion on this topic: The first question is much more easy to answer: Some instructions only work in some sufficiently privileged processor mode, so you can be pretty sure that if they occur in the firmware (and they usually will) you are in this mode. If you know the processor you can simply look up in the documentation of the processor whether there are other even more privileged modes (in particular for some hypothetical hypervisor). Often for realtime or microcontroller stuff older or cheaper cores are used which simply lack this capability. Since virtualization is complicated it is hardly used in firmware, in particular if there exist realtime requirements (often there will be), which are complicated to handle if you do virtualization. So you can in most cases be pretty sure that there is no hidden virtualization layer. The much more interesting case is that there are other ICs on the SoC which could in principle patch the firmware or (much more often) access the memory (TLDR: this can be quite real). The good news is: This will usually be some specific part of the SoC and its existence can be seen or disproved if you are willing to decap/xray the chip (see for example the xray image at http://www.bunniestudios.com/blog/?p=4297 http://www.bunniestudios.com/blog/?p=4297). For these parts one can usually find signs in the firmware. For example if the firmware tries to communicate with another subsystem via device command or if the MMU is programmed to translate some virtual adress which doesn't seem to be backed by the chip memory (this could be some device memory) or if in the initialization code the firmware seems to try to send a patch to some device memory of another IC on the SoC. On the other hand, after decapping and xraying the chip and additionally finding no such dubious signs in the firmware, I would tend to believe that no such device exists. TLDR: You can never be completely sure, but if such a layer exists, I'm very sure that one can find strong signs for its existence.
    - Someone 10y ago
      "If you know the processor you can simply look up in the documentation of the processor whether there are other even more privileged modes" That requires trusting that the documentation is complete. And I think such a lower layer could be hidden very well, and need not be involved in day-to-day operations. For example, in your network card it could sniff traffic, becoming active only after receiving a very specific series of packages. And the change could be as simple as ignoring a signature on over the air firmware updates. Yes, decapping, X-raying, and years of work can always uncover such stuff, but it is the only way to be absolutely, absolutely sure. If you're China, Russia or the US and buy military hardware, I think you should be somewhat worried about this.

> And it shouldn't be too hard to find a GBit ethernet NIC without. Just wonder how exactly you going to check if hardware have firmware inside it.

by SXX 10y ago

> And it shouldn't be too hard to find a GBit ethernet NIC without. Just wonder how exactly you going to check if hardware have firmware inside it.

creshal 10y ago

Good point. Usually the criterion is "can we send it a firmware blob? Can we send it an open-source firmware blob?". If you have a firmware that can't be replaced at all, it's usually handwaved away.

SXX 10y ago
This is main point of many developers we can speak with in public like AMD Linux graphics team. There is a lot of people who blame them for proprietary firmware, but in same time totally okay about using tons of devices that simply not expose way to replace their firmware.

wolfgke 10y ago

The criterion by the FSF is: If you can't replace the firmware (by somethings free), but someone else is able to change the firmware, the firmware has to be considered as malware.

Someone 10y ago
But how do you know? Even if you can flash new firmware, how do you know it is all the firmware? There may be a layer below what you can see, with its own CPU, memory, and firmware.
- wolfgke 10y ago
  > But how do you know? Even if you can flash new firmware, how do you know it is all the firmware? There may be a layer below what you can see, with its own CPU, memory, and firmware. We have to differ here: First question is whether there is a deeper layer below and the other one whether there is additional hardware on the SoC which could also patch the (main) firmware (say: firmware update Over The Air (OTA)). I can only give my personal private opinion on this topic: The first question is much more easy to answer: Some instructions only work in some sufficiently privileged processor mode, so you can be pretty sure that if they occur in the firmware (and they usually will) you are in this mode. If you know the processor you can simply look up in the documentation of the processor whether there are other even more privileged modes (in particular for some hypothetical hypervisor). Often for realtime or microcontroller stuff older or cheaper cores are used which simply lack this capability. Since virtualization is complicated it is hardly used in firmware, in particular if there exist realtime requirements (often there will be), which are complicated to handle if you do virtualization. So you can in most cases be pretty sure that there is no hidden virtualization layer. The much more interesting case is that there are other ICs on the SoC which could in principle patch the firmware or (much more often) access the memory (TLDR: this can be quite real). The good news is: This will usually be some specific part of the SoC and its existence can be seen or disproved if you are willing to decap/xray the chip (see for example the xray image at http://www.bunniestudios.com/blog/?p=4297 http://www.bunniestudios.com/blog/?p=4297). For these parts one can usually find signs in the firmware. For example if the firmware tries to communicate with another subsystem via device command or if the MMU is programmed to translate some virtual adress which doesn't seem to be backed by the chip memory (this could be some device memory) or if in the initialization code the firmware seems to try to send a patch to some device memory of another IC on the SoC. On the other hand, after decapping and xraying the chip and additionally finding no such dubious signs in the firmware, I would tend to believe that no such device exists. TLDR: You can never be completely sure, but if such a layer exists, I'm very sure that one can find strong signs for its existence.
  - Someone 10y ago
    "If you know the processor you can simply look up in the documentation of the processor whether there are other even more privileged modes" That requires trusting that the documentation is complete. And I think such a lower layer could be hidden very well, and need not be involved in day-to-day operations. For example, in your network card it could sniff traffic, becoming active only after receiving a very specific series of packages. And the change could be as simple as ignoring a signature on over the air firmware updates. Yes, decapping, X-raying, and years of work can always uncover such stuff, but it is the only way to be absolutely, absolutely sure. If you're China, Russia or the US and buy military hardware, I think you should be somewhat worried about this.