Hacker News Reader

Comment by icebraining | Hacker News Reader

The good thing is that these parts are firmware, thus non-executable code.

What? Firmware is definitively executable, it just doesn't run on the CPU.

And besides, if you look at the list of proprietary files being copied, there are plenty of normal libraries: https://github.com/CyanogenMod/android_device_semc_iyokan/bl...

View on HN

With statements like this, the author is doing the community a disservice. It is very important to understand that a modern smartphone contains enough CPUs to be used against you, even if you only run Open Source on the primary one.

This might not matter for most users, but it can decide about live and death for some, like journalists in crisis zones.

There is so much prorprietary firmware everywhere that can fuck you over.

Your mainboards almost always have proprietary firmware. Coreboot is woefully underutilized and underfunded in this regard.

All hard drives have proprietary firmware, and often have proprietary processors on board. They are for all intents and purposes isolated computers in and of themselves, and nobody talks about how closed they are.

Graphics hardware is predominantly proprietary, even the most open discrete cards (AMD's) which have technical documentation have proprietary firmware blobs. I can only barely trust myself using these on the pretense that others have already decompiled the blobs and found nothing particularly malignant on a few older model cards. Every other manufacturer except Intel and very recently Broadcom with a single model of GPU are whole stack proprietary.

Network radios, as mentioned in this article, are almost always either wholly proprietary or have a firmware blob like GPUs.

CD drives also have proprietary firmwares like hard drives.

All TVs are running proprietary whole stack firmware on internal computers.

Dumbphones also are computers, just whole stack proprietary.

Your fridge, toaster, many ovens, and microwaves, if digital, are also whole stack proprietary computers.

This stuff is everywhere. There is literally no way to liberate yourself. Even Richard Stallman is driving a car with a proprietary on board computer, and probably cooks food in a proprietary Microwave.

> Your mainboards almost always have proprietary firmware. Coreboot is woefully underutilized and underfunded in this regard.

If you care about this, buy a Chromebook. The new ones have Coreboot. Of course, Google blah blah evil, but you can put your own OS in so the stack goes Coreboot->Uboot->(preferred Linux distro)

The real problem with many chromebooks is how they use firmware blobs Intel provides as injectors in Coreboot. They aren't really open firmware at all.

AMD is pretty much the only company doing anything in this regard. Many of their recent chipsets are supported, like fm1 and fm2.

And I thought "coreboot" meant really 100% free software. Depressing.

There's a fork of it that is 100% free software: http://libreboot.org/ . Unfortunately it only supports one computer, the Thinkpad X60.

(They even removed the CPU microcode updates, which IMHO is going a bit too far; there's already microcode in the CPU, and Intel issues those updates to fix various errata in the hardware. Maybe it was done more as an ideological thing.)

And of course having different firmware for different OSes defeats the point of firmware standards. I think it is possible to run UEFI as a payload in coreboot.

Or this, which is AFAIK the only 100% blob-free PC-compatible:

http://shop.gluglug.org.uk/product/ibm-lenovo-thinkpad-x60-c...

https://www.fsf.org/news/gluglug-x60-laptop-now-certified-to...

If the FSF likes it, I think you can be pretty sure it's as free as it gets...

The example that I found most amusing was that SD Cards have proprietary firmware -- turns out buying old SD Cards may be the cheapest way to get a single-board programmable microcontroller. [1]

[1] http://gizmodo.com/sd-cards-are-tiny-hackable-computers-for-...

It's not just firmware, although that stuff is a risk, but the threat from mobile basebands is very real.

I'm talking about drivers. Can you provide an example? How the firmware needed for your camera can be executed on its own?

e.g. The camera firmware blob could be tagging all your pictures with some kind of hidden watermark. Who knows ?

EDIT: Just to clarify, firmware blobs are not executed "on their own", they are normally executed on a micro-controller that is embedded in the baseband / power management / gpu / any other chip.

That was exactly my point.

That my have been what you meant, but it wasn't what you wrote in the blog post. And besides, it's irrelevant if it runs "on its own" or not; in fact, technically, only the bootloader runs on its own, everything else has to be loaded by some piece of software, including the OS itself.

The firmware that runs the baseband processor manages communication via the radio (and sometimes wifi and bluetooth as well)[0]. Once loaded, that firmware will have plenty of opportunities to phone home or otherwise provide information about your location, activities, etc.

[0]: http://en.wikipedia.org/wiki/Baseband_processor

There is usually little or no security boundary between the AP and complex peripherals (like the baseband, cameras, GPU, audio subsystem, etc.) Usually these will have direct access to main memory (like having a DMA channel given to them), and will have firmware loaded into them by the AP at boot. After which, they can damage the integrity and privacy of your 100%-OSS AP software.

The baseband, particularly, is of concern because it's connected to the outside world, and is powerful and complex. And almost always closed, and provided by an American company (Qualcomm).

Why would anybody ever write code that isn't intended to be executed?

The camera executes its firmware, and it has direct access to the memory, flash, network, etc.

FYI the cameras in most phones (at least the ones I've played around with) contain no firmware. It's just a relatively dumb image sensor connected via a MIPI interface to the main SoC, and is under control of it. It cannot access memory on its own.

Do you have any blogs/articles about that? Free software video hardware is still hard to get afaik.

Don't know of any particular blogs/articles but you can e.g. Google "OV5647 datasheet" and read the datasheet for the RPi's camera chip. There's not much that could be a security concern on the camera module itself, since it's relatively dumb; it's what controls it that's a different issue.

Reply on news.ycombinator.com