Hacker News new | past | comments | ask | show | jobs | submit login

Joanna Rutkowska has written a nice paper on the topic, highly recommended: http://blog.invisiblethings.org/papers/2015/x86_harmful.pdf

Edit: There's also a talk from 32c3 for those more inclined to watch a video. I am pretty worried ever since I watched that: https://www.youtube.com/watch?v=rcwngbUrZNg

(which is why I have researched non-Intel laptop alternatives..cliffnotes: GPUs without BLOBs are hard to find and there will be some severe tradeoffs which is expected)




I like her summary of Intel ME:

"We have seen that Intel ME is potentially a very worrisome technology. We cannot know what’s really executing inside this co-processor, which is always on, and which has full access to our host system’s memory. Neither can we disable it.

If you think that this sounds like a bad joke, or a scene inspired by George Orwell’s work, dear reader, you might not be alone in your thinking..."


  > GPUs without BLOBs are hard to find
Any devices without firmware are hard to find. Even if only some have option to upload firmware almost every device on market have closed-source firmware inside it: NICs, USB controllers, hard drives and especially modern SSD, sound cards, etc.


NICs exist, occasionally: Atheros Wifi chips work with open-source firmwares. And it shouldn't be too hard to find a GBit ethernet NIC without.

Everything else is a lost cause right now. Keyboards, mice, displays, … Everything is running proprietary firmware blobs.


Keyboards and mice have the distinction of being low enough resource that they can be independently implemented with cheap microcontrollers - there's currently a whole cottage industry for keyboards, spurred on by enthusiasm for discrete switches. And hopefully these microcontrollers' cheapness is enough to ward off Hanlon's razor's silicon. Furthermore, there's fewer avenues for backhaul from non-connected peripherals, especially mass backhaul.

I think in time, "Internet access" will come to be recognized as a bug, much the same way that "turing completeness" is starting to be recognized as such for programming languages. Not needed for most uses, very easy to accidentally obtain, and game-over for tractability when it shows up. The question is what a general better "restricted language" looks like that is able to accomplish all that we'd like.


> Atheros Wifi chips work with open-source firmwares.

Interesting. Isn't such firmware able to initiate unlawful transmissions? How are they going to deal with this new FCC goodness?


Funnily, the FCC requirement is incompatible with the EU laws.

The EU laws say that while a normal user shouldn’t be able to make unlawful transmissions, the manufacturer may NOT prevent the customer from installing alternative software (like openwrt) just to fulfil the first requirement.

Basically, to conform with EU law, you have to violate US law, and the other way round.


Any sources?

And no, it's not mutually exclusive. In principle, it should be possible to enforce regulatory constraints in hardware. But then I guess you can forget about taking this hardware to another country, unless they make this hardware as smart (read: complex) as drivers currently are.


It will likely be ignored. How do you prevent NSA from anything.


The upcoming Keyboardio model 01 has an open source firmware, you can dive in at https://github.com/keyboardio/KeyboardioFirmware


> 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.


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.


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.


> 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). 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.


"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.


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.


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.


And it shouldn't be too hard to find a GBit ethernet NIC without.

I think just about every cheap, "value" (i.e. no advanced features) NIC qualifies; the Realtek ones come to mind.


Actually, since you mention Realtek, some of their gigabit NICs do take some firmware. I have a vague notion that it's not needed for the basic functionality of sending and receiving packets, but I might be wrong - it's been a few years since I dealt with it.


Well, I'm dumb. Of course the firmware has to be embedded in the BIOS or the chip itself, because most machines with Realtek NICs support network booting. Firmware loading in OS drivers probably only delivers updates.

So there is firmware, it can be updated by the OS, we don't know exactly what's inside. Though at least the firmware isn't designed to update the OS as in those Soviet Russia jokes.


atheros microcode is not opensource, only the driver is. the microcode binary has a liberal license, but good luck turning that into source code.


Note that the video is also available on media.ccc.de (this is the source, youtube is just a "bad" mirror):

https://media.ccc.de/v/32c3-7352-towards_reasonably_trustwor...

This is her corresponding blog post:

http://blog.invisiblethings.org/2015/12/23/state_harmful.htm...




Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: