Matthew Garrett ([info]mjg59) wrote,
@ 2008-06-09 19:03:00
Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Entry tags:advogato, fedora

Things in your computer that you do not have the source code for:

  • Your BIOS
  • Your video BIOS
  • Your ACPI tables
  • Your ethernet card (in almost all cases)
  • Your wireless card (in almost all cases, though there are efforts to write open source firmware for Prism 54 and Broadcom hardware)
  • Your CPU microcode
  • The embedded controller that responds to things like the power button being pressed and makes your computer go and controls your fan and turns on LEDs and the like
  • Your keyboard controller (which is often the same thing as above)
  • The firmware running your disks
  • The firmware running your DVD drive
  • In many cases, the firmware that runs your disk controllers
  • For AMD and Nvidia, the code that's running on your graphics card
  • The firmware running your trackpad
Anyone think of anything I've missed?

Things people have suggested:
  • Laptop batteries
  • Modems (wired and wireless)
  • Embedded controller in any docking station
  • UPSes

More suggestions:
  • Some sound cards
  • Network card boot roms
  • Fingerprint readers
  • USB card readers
  • Flash media
  • USB mass storage
  • Webcams
  • Touchscreens
  • Any lights out management
  • TPM firmware
  • Monitor itself
  • Intel's AMT madness hardware
  • Mice
  • Various firewire and USB peripherals

(Post a new comment)

DNA & questions
(Anonymous)
2008-06-09 06:34 pm UTC (link)
The DNA for the microbes and other fauna that inevitably live in them.

(Reply to this) (Thread)
Re: DNA & questions
[info]mjg59
2008-06-09 06:36 pm UTC (link)
I think at most you can claim that DNA is interpreted bytecode, but it's one of those situations where it was genuinely written in that form.

(Reply to this) (Parent)
DNA
(Anonymous)
2008-06-09 06:36 pm UTC (link)
The DNA for the microbes and other fauna that inevitably live in them.

(Reply to this)


[info]base3
2008-06-09 06:43 pm UTC (link)
unrar?

(Reply to this)


[info]ajaxxx
2008-06-09 06:54 pm UTC (link)
Other boot ROMs, notably PXE and SCSI and misc. Also some sound cards are firmware'd, iirc.

(Reply to this)


[info]ewx
2008-06-09 06:57 pm UTC (link)
The firmware in your display.

(Reply to this)

Modem DSP stuff?
[info]https://login.launchpad.net/+id/3BWeerr
2008-06-09 07:03 pm UTC (link)
Dunno what the right name for it is, but hardcore code athat lets the modem do it's modulation etc.

(Reply to this) (Thread)
Re: Modem DSP stuff?
[info]mjg59
2008-06-09 07:05 pm UTC (link)
Ooh, good point. True for both wired and wireless modems, though perhaps less true for some softmodems.

(Reply to this) (Parent)
Embedded computers :)
[info]nchip
2008-06-09 07:29 pm UTC (link)
ACPI and BIOS are especially good at hiding the the hardware from driver developers, directly contributing to the poor suspend/resume experience on PC Linux.

However, embedded computers can be more open. For Thecus N2100 NAS "computer" we have source code for everything redboot (bootloader), kernel, and none of the onboard devices need loadable firmware. The onboard RTL r8169 ethernet might have a permanent firmware, and if you insert a sata disk you will definetly get firmware..

(Reply to this)


[info]fooishbar
2008-06-09 07:30 pm UTC (link)
Also, if you own a mobile phone (some of which are unbelievably close to computers), you've got the boot ROM, probably the bootloader (hell, the whole OS in most cases), the GSM stack, the GPS stack, and myriad others.

Also, any USB device you own. Mass storage? Ruh row. Ethernet? Fail. Sound? etc.

Your TV, DVD player, etc. Air conditioner/climate control. The thing what controls the engine and brakes on your car.

(Reply to this) (Thread)

(Anonymous)
2008-06-09 07:39 pm UTC (link)
Buying a Neo Freerunner as soon as it comes up for sale, so that solves most of that problem, other than GSM which we can blame on (among other things) government.

(Reply to this) (Parent)(Thread)

[info]fooishbar
2008-06-09 07:51 pm UTC (link)
Er, still the boot ROM, entire GSM stack, probable wifi firmware (if it has wifi), power management, etc, etc.

(Reply to this) (Parent)(Thread)

[info]broonie
2008-06-09 08:04 pm UTC (link)
The boot ROM on the Freerunner is u-boot (which is GPLed). The power management is all open too, in Linux and u-boot.

(Reply to this) (Parent)(Thread)

[info]fooishbar
2008-06-09 08:07 pm UTC (link)
You're conflating bootloader and boot ROM (unless they've somehow put uboot in ROM). Also, PM in hardware is getting very sophisticated these days, regardless of how much control is exerted in software.

(Reply to this) (Parent)(Thread)

[info]broonie
2008-06-09 08:37 pm UTC (link)
In systems like this the bootloader is the boot ROM - it contains the first instruction executed by the processor after it comes out of reset. This is done by placing the bootloader in flash mapped at the appropriate address, there's no literal ROM.

I'm familiar with the complexity of modern PMICs (I work on drivers for some, among other things) but I'm not sure what sorts of features you're concerned about here? I really wouldn't say that they were so complex that it's reasonable to worry about them as software - the automation tends towards straightforward decisions, mostly surrounding low power states with no OS running.

(Reply to this) (Parent)(Thread)

[info]fooishbar
2008-06-09 08:50 pm UTC (link)
How do you handle things like flashing if your bootloader's shot? I work on systems which have bugs in their boot ROM (literal ROM) that we've needed to either work around or get new silicon revisions for ...

(Reply to this) (Parent)(Thread)

[info]broonie
2008-06-09 09:11 pm UTC (link)
If the system is so borked that it can't boot at all then you loose and need to use something out of band like JTAG to recover them by reflashing. Basically, you need to be very careful about what you flash for the bootloader if you don't have a recovery mechanism - if you do flash something broken then you're in trouble. This usually works OK in practice - scary warnings and so on tend to be effective enough.

It's not unknown for hardware to include two jumper-selectable flash banks, allowing one to have a backup bootloader in case things do get broken. If you've got a backup copy you can also do things like write protect it for added robustness (it doesn't need to do anything more than get the system to the point where the primary flash can be recovered, really, so it doesn't have such a need for bugfixing).

(Reply to this) (Parent)(Thread)

[info]fooishbar
2008-06-09 09:44 pm UTC (link)
I'd be interested to know if it didn't have a boot ROM that allowed for pulling a bootloader over a serial interface, doing any early init at all (flash?) or similar. JTAG is pretty painful.

(Reply to this) (Parent)(Thread)

(Anonymous)
2008-06-09 10:32 pm UTC (link)
To the best of my knowledge, if you hose u-boot on the Neo, you get to use a JTAG to recover. This represents a big part of why they readily supply developer kits with JTAGs: for people doing bootloader-level hackery.

(Reply to this) (Parent)

[info]broonie
2008-06-09 10:48 pm UTC (link)
Yes, that's exactly the configuration - it's very standard for u-boot based systems. People don't want to burn either board space or BoM cost on a separate boot ROM. The developer version comes with a JTAG board, it's not part of the vanilla ship.

Like I say, the nearest thing you'll usually see is a write protected second flash area.

(Reply to this) (Parent)

[info]nunfetishist
2008-06-09 10:55 pm UTC (link)
You might consider what some ARMs do at reset as software, but I imagine it's actually done in hardware. They do things like copy the first page of flash into some internal RAM (because you've not set up your SDRAM yet) and run it. This is your code. Your IPL, if you like, that sets up the RAM, and copies your kernel and such into it, and branches to it. It's very common in such small devices that if you stuff that up, it's time to get the JTAG probe out.

JTAG's not such a pain: if you're a developer you most likely already have a shell script to reblat the flash on the device on the end of your JTAG cable with some known-working image.

(This is certainly how our stuff works.)

(Reply to this) (Parent)

(Reply from suspended user)

(Reply from suspended user)
Some more ...
(Anonymous)
2008-06-09 07:31 pm UTC (link)
- The battery in your laptop
- The UPS for your server
- The laptop docking bay
- The firmware in the fingerprint reader that's part of your laptop
- I'd bet all those fancy 15-in-1 card readers have firmware too
- external USB storage devices often have firmware
- IPMI BMC (is this the same as the 'embedded ontroller' above? Not necessarily, I would think)
- There must be firmware for the touchscreen
- Do all the USB devices you have plugged into your computer count? Or only if they're keyboards/mice? What about the built-in keyboards/mice which are on USB?

(Reply to this)

Don't be too focused on firmware
[info]http://digitalvampire.org/roland/
2008-06-09 07:36 pm UTC (link)
You clearly don't have the RTL for any of the ICs in your computer (CPU, chipset, NIC, etc). Even if you're running on a synthesized CPU on an FPGA, the FPGA itself probably has hard-coded blocks that you're missing the source to.

(Reply to this)


(Anonymous)
2008-06-09 07:37 pm UTC (link)
I'll add a catch-all for "hardware", though that doesn't really count the same way. I think we'd all like source code for our hardware, but I'd rate it below many of the items on your list.

Regarding "your video BIOS", it seems worth noting that some modern graphics drivers don't touch the video BIOS, so it could potentially go away.

Arguably the same applies to ACPI, for many things people care about; certainly we could have P-states and C-states without it, though we don't usually have enough information for S-states.

One people don't often think about: the code to the various game consoles you might have, both on the system and in the games. How many people remain staunch advocates of FOSS while forgetting about things like consoles, let alone less obvious embedded systems.

Some items more in the spirit of your list:

USB device firmware. Many USB devices have embedded firmware.

Sound card firmware and/or AC.97 firmware.

TPM firmware (often on the embedded controller you mentioned, but potentially separate).

Smart card firmware (in most cases, though I *think* some FOSS smart cards exist).

The "code" running on the DVDs you play, and more plausibly the code running on any Blu-Ray disk you play.

(Reply to this)


[info]xencat
2008-06-09 07:37 pm UTC (link)
EFI (or covered under BIOS)
Soundcard
Bluetooth and IR (or covered under wireless)
North bridge
VIA padlock chip (or any other crypto accelerator)
Any HW sec module (fingerprint reader, smart card reader)
USB controller
FW controller
Any other I/O (PCI-E/X/etc)
Smart battery firmware (if you are on a laptop)
Memory chip code for saying how the RAM behaves
HDMI HDCP type stuff
Ethernet is interesting when you have TCP/IP offload and firewalling present
Display controllers in your monitor to handle digital signals (any other DSP?, on computer if a laptop)
If you are running a Dell, Toshiba, Lenovo, etc addition to BIOS that handles remote wiping
HW based full disk encryption
Camera (if in-built)

That'll do for now.

(Reply to this) (Thread)
Hm.
[info]gregdek
2008-06-09 07:42 pm UTC (link)
I'm curious about the purpose of this exercise. :)

(Reply to this) (Parent)

[info]kulbirsaini.wordpress.com
2008-06-09 08:00 pm UTC (link)
sounds like a plan to open source them :P

(Reply to this)

Wireless mouse/keyboard
(Anonymous)
2008-06-09 08:07 pm UTC (link)
The wireless (non-Bluetooth) mouse/keyboard combos probably use some onboard software for the radio protocol. Btw. is there actually a way to get battery levels from the Logitech PS/2 "Cordless Keyboard" batteries under Linux?

@gregdek: maybe there is no deeper purpose aside from making people think :)

(Reply to this)


[info]loic
2008-06-09 08:11 pm UTC (link)
Anything usb that you plug in has a microcontroller in it. I don't know if that's "in your computer", but I sure find it handy to have a keyboard and mouse.

The processes for manufacturing many of the parts in your computer are secret, proprietary and patented too, if that counts...

(Reply to this)


[info]gerald_duck
2008-06-09 09:08 pm UTC (link)
  • Firewire peripherals (which infamously have bus-master access to your physical memory)
  • The microcode in your SDRAM
  • KVM switch
  • Optical mouse firmware (for people who aren't using trackpads)
  • Sound card DSP code
  • Hardware security module

(Reply to this) (Thread)

[info]womble2
2008-06-09 11:53 pm UTC (link)
SDRAM has microcode?! I thought it just had some (EEP)ROM you could query via I2C/SMbus.

(Reply to this) (Parent)(Thread)

[info]gerald_duck
2008-06-10 01:41 am UTC (link)
Complicated state machine or simple microcode? You decide.

But it certainly has something that orchestrates the complicated overlapping sequences of commands from the host.

(Reply to this) (Parent)

[info]zaitcev
2008-06-09 09:27 pm UTC (link)
I'm surprised nobody mentioned the LOM and other console controllers (or am I not reading comments well?) They commonly contain a webserver and ssh server, which is a ton of code. It's not common in desktops, but these things get into smaller and smaller servers. You can get a very basic 1U with LOM and remote KVM which is actually built into the mobo.

(Reply to this) (Thread)

[info]thargol
2008-06-09 10:04 pm UTC (link)
They commonly contain a webserver and ssh server

I wish they didn't. Or rather, that's all well and good, provided they give you a plain old serial console as well. The trouble is, modern PCs don't tend to. Last time I looked, Sun hardware still did, but I fear that won't last, either...

(Reply to this) (Parent)

[info]womble2
2008-06-09 11:52 pm UTC (link)
You're thinking of the BMC (baseboard management controller). LOM stands for LAN-on-motherboard, a chip with 1 or more (usually 2) network controllers and PHYs and an internal port connected to the BMC.

(Reply to this) (Parent)(Thread)

[info]mjg59
2008-06-09 11:57 pm UTC (link)
Lights Out Management

(Reply to this) (Parent)(Thread)

[info]womble2
2008-06-10 12:15 am UTC (link)
Sorry, yeah, LOM stands for two different but related things.

(Reply to this) (Parent)

[info]jldugger
2008-06-09 09:58 pm UTC (link)
I'm not sure if it's already on the list or not, but we don't have source for the firmware in the UPEK fingerprint scanners (common on new tablets).

The Wiimote (not technically IN my computer, but it does connect and operate) runs firmware and I've heard its a programmable microcontroller.

Also schematics for most of the hardware. I gather you're after software / programming, rather than general designs, but Verilog / VHDL are unambiguous design languages for things in my computer. These are certainly things, and certainly have source code. We might define these people as crazy moonbats, but there is http://www.opencores.org/ and people do participate...

And just so we don't exclude the previous paragraph by merit of being the most loony thing mentioned, here's an idea even more loony: surely you'd need the source to the machines that interpret the Verilog / VHDL code and translates that into hardware or you haven't quite reached a truly free design.

(Reply to this)


[info]nunfetishist
2008-06-09 10:51 pm UTC (link)
Firmware in optical mouse that does image processing?

(Reply to this)


[info]lionsphil
2008-06-09 11:34 pm UTC (link)
Any crap lurking in EFI, although I assume you've bundled that under "BIOS" here.

I'm not sure why I should be caring about things like keyboard firmware, though. I don't feel restricted in freedom, or even particularly security, that I can't effectively replace it, as long as externally it behaves like a keyboard so that OSS code can work with it.

(Reply to this)

RAID controler firmware
(Anonymous)
2008-06-09 11:38 pm UTC (link)
None of the firmwares embedded in RAID controllers are open source (think Adaptec, LSI Logic, 3Ware, etc.). And they tend to be buggy, we that.

And we don't have opensource tools to manage them (well OpenBSD has, but not Linux) either (detect when a drive failed, blink the led for this drive, move a spare drive on an array, ...). Hardware RAID is really the weak point for opensource kernels on servers.

(Reply to this)


[info]martling
2008-06-10 12:02 am UTC (link)
Anyone think of anything I've missed?

The hardware.

The distinction between firmware and hardware is becoming increasingly irrelevant. The two are increasingly designed together with few clear interface lines between them. Mobile phone manufacturers are at the extreme of this, using some very smart modelling systems to optimally spread a set of functionality freely between software and ASIC area to meet a balance of power and cost constraints for given usage profiles.

I expect that PC hardware will increasingly go the same way, and I see little reason why the host CPU should be left out of the optimisation: think softmodems gone crazy. Eventually we will get to the point where the hardware, firmware and driver are all synthesised from the same source code, and even the manufacturer won't be able to tell you what the interface is in any human-readable form.

The idea that open source can just deal with software is dangerously outdated. Unfortunately, doing something about that requires a lot of money rather than just a lot of spare time.

(Reply to this)


[info]deviant_
2008-06-10 12:05 am UTC (link)
Keyboards and mice, and really virtually any usb device. A very large chunk of them are devices like the Cypress EZ-USB, which basically is a keyboard controller with loadable firmware.

EFI, sortof -- basically we've got code for most of it, except 1) actual drivers that aren't part of the reference source, 2) CSM (i.e. BIOS), 3) any changes the vendor has made, which typically winds up being things like apple wrapping the boot manager in some incompatible hairbrained crap of their own.

(Reply to this)

Your post is mistitled
(Anonymous)
2008-06-13 12:54 am UTC (link)
The correct title should be “Things in your computer for which you do not need the source code.”

(Reply to this) (Thread)
Re: Your post is mistitled
[info]bignose.whitetree.org
2008-06-13 07:06 am UTC (link)
Yes.

Most of the things listed in this post are things that, once they're in the computer, *nobody* has freedom to alter the behaviour of non-descructively (i.e. without breaking and/or replacing entirely) once you receive it. For such things, not having the source code is no harm, because nobody is in a more privileged position than you to alter how the thing will behave.

There are a growing number of items (e.g. BIOS, devices with firmware) which *can* have their behaviour altered non-destructively after installation; for those items, it's worthwhile to ensure the source code is available to the item's owner under free license.

That's not true for most items on the list, though, so I'm not sure what the point of the post is.

(Reply to this) (Parent)(Thread)
Re: Your post is mistitled
(Anonymous)
2008-06-13 08:21 pm UTC (link)
Even if it's something *nobody* has the freedom to alter the behaviour of non-descructively, it's still useful that the source code is publicly available, if only to ensure that it doesn't do anything you wouldn't want it to (not that there's much it could do anyway, but still).

(Reply to this) (Parent)
For BIOS/EFI there are free alternatives
(Anonymous)
2008-06-24 05:23 pm UTC (link)
At least for BIOS/EFI on x86, there is a free (as in freedom) alternative: coreboot. http://www.coreboot.org/
It only performs the absolutely needed lowlevel init (RAM, IRQs, fans...) and then hands over to a payload (which can be anything from Linux over memtest86 to GRUB2, GNUFI, legacy BIOS emulation...). If you use it, you also have the choice to eliminate all non-free firmware for onboard devices from the shared ROM.

There are quite a few systems where the BIOS, onboard Video BIOS and network card firmware all have been eliminated thanks to coreboot and everything still works. You're even free to skip any CPU microcode updates if you want. Depending on the hardware, you can avoid embedded controller firmware if there's no such thing.

(Reply to this)

Create an Account
Forgot your login or password?
Login w/ OpenID
English • Español • Deutsch • Русский…