Hacker News Reader

It took Linksys months to make their firmware for their "new open source" WRT routers reasonable enough that DDWRT / OpenWRT didn't have to deny their patches.

All these hardware companies - the motherboard makers, the wifi radio makers, the hard drive makers, the peripheral and chipset makers - all write the most awful insecure disastrous code in the industry. But because nobody cares enough to put their wallet where their mouth is and refuse to buy hardware without access to the firmware to audit, improve, fix, or replace it this is what you are left with, and you get what you pay for.

And there are plenty of firmware settings you might want to change even without overclocking. Change the default boot hardrive? Firmware. Turn off unused ports on your motherboard? Firmware. Change fan speed settings? Firmware. Any implementation of network / usb booting? Firmware. Full HD encryption? Firmware.

I just know the next laptop I buy will be whatever the highest end liberated Chromebook at the time is, preferably without cancerous firmware blobs that control everything, but that seems unlikely considering how anti-freedom Intel is.

I just hope AMD saves x86 computing in the Zen generation. They are the underdog, they have reasons to not throw users under the bus for complete control of the platform like Intel does. But their hijacking of radeonHD and injection of firmware blobs there doesn't make me hopeful for first-gen freedom respecting hardware from them any time soon either.

RISC-V, save us!

> RISC-V, save us!

You presented evidence that hardware vendors write awful firmware code - why will these people write decent firmware as soon as RISC-V comes, i.e. what evidence do you have that we won't have the "accepted" behaviour of having RISC-V and bad firmware?

The point is that RISC-V will be documented; you don't need to blindly accept whatever firmware is bundled, because it's possible to write alternative firmware. This is actually the case for a lot of embedded processors and SoCs too, but it doesn't do as much good their because even when things are sufficiently documented they're still not actually standardized. Given the opportunity, projects like coreboot and OpenWRT produce great results.

The problem there is that x86 is well-documented too. Painfully so in a lot of cases. Overly so in some. You can get, with a few clicks, the documentation, including pinouts, register settings, etc for any processor Intel has, the chipset, peripheral controllers, pretty much everything. The biggest thing you can't get documentation for is the $10 thunderbolt controller some boards have, for asinine reasons. The problem more is the companies that make the boards farm out the coding to the lowest common denominator, so all that gory documentation goes to waste all too often. RISC-V isn't going to save us from crappy motherboards, unfortunately.

I like to hope and pray that since RISC-V was found on the principles of royalty free open instruction sets and blueprints that anyone who sockets the architecture might follow through.

A lot of the problems with x86 motherboard vendors is probably that they legally cannot disclose a lot of the internal documentation and code handed them from Intel, because Intel uses some of it as a trade secret against ARM / AMD.

Intel gives a fuckton of information to any and everyone, they submit code to the TianoCore project, they pretty much bend over backward to say, "here, take this, make your stuff not suck." The UEFI forum's pretty similar in access to tools and specifications. This all comes down to a race to the bottom for coders because software's a liability to a lot of the companies developing hardware, even if things are handed to them pretty much on a silver platter.

Poke around Intel's firmware developer center http://firmware.intel.com/develop . There's pretty much everything there you need to make a firmware that isn't terrible, but companies will find a way to provide one anyway.

I'm not seeing where firmware.intel.com has any documentation for stuff that's lower-level than EFI modules and drivers. They've got a Firmware Support Package that "provides a binary package to initialize the processor, memory controller, and Intel chipset initialization functions", but only for some mobile and embedded platforms. Otherwise, they seem to just refer you to Phoenix, AMI, and friends so you can license their buggy stuff to build a custom GUI for. There's really not much benefit to the community in making it possible to build better EFI modules if you've got no way to integrate them into a usable replacement firmware for your existing hardware.

The real problem is that SoCs are SoCs, not Cs. The peripherals (networking, graphics, disk interface, etc.) don't necessarily need to be open on a RISC-V processor.

This is also true with ARM, which is why I doubt RISC-V is a solution to the problem of bad firmware and/or lack of SoC documentation. ARM is "open" in the sense that the CPU architecture is publicly documented --- you just can't legally implement the CPU without licensing it from ARM.

FYI the pre-Pentium subset of x86 has been public-domain and free of patents for a long time, and I believe several more Pentium-level patents are going to expire soon, so in that sense a lot of the basic x86 instruction set is more open than ARM. No doubt if RISC-V becomes popular there will be plenty of proprietary extensions to it too.

> I just know the next laptop I buy will be whatever the highest end liberated Chromebook at the time is, preferably without cancerous firmware blobs that control everything, but that seems unlikely considering how anti-freedom Intel is.

Yep, I don't think you'll find x86 Chromebooks without blobs. Nowadays the only way Intel provides to boot their hardware is "here, take this binary and put it at the beginning of your BIOS".

Same thing with AMD, btw.

I'm fine with ARM, hopefully future iterations of the ASUS C201[1] are portable to Libreboot in the future by the time I'm shopping for a new laptop. It won't be for a while, I hate giving these scum freedom denying companies my money for locked down puke.

[1]: https://libreboot.org/docs/hcl/c201.html

Agreed, but one small pedantic correction: the Linksys firmware was written by Chinese contractors. I know because I had to deal with them. It's also why the open source process took so long - the firmware was a binary blob and the contractors refused to cough up the GPL'd source.

The good news is that the eg Intel FSP firmware blobs would not be the problem in cases like this and never would be.

The problem is the Linux based boot loader that circumvents Windows Activation Technology. I am convinced that -- and that alone -- is why we live with UEFI.

au contraire, the problem is windows thinks it owns the machine I bought for the sole purpose of running linux.

It's poorly phrased, but I think he is agreeing with you.

Are you confusing WAT with SecureBoot?

Probably WAT, those bootloaders patching SLIC so Windows thinks it's a certain OEM system. I think those hacks are/were based on GRUB.

The thing I find particularly hard to grok is that they came up with this idea of putting disk-specific boot information on the motherboard. Then it was one simple step for board manufacturers to mix this with low level hardware settings which also need to be stored somewhere and produce the kind of trouble we are seeing.

Systems would be safer if this stuff was stored on disk and OSs never had any reason nor even possibility to tinker with motherboard's configuration memory.

> Systems would be safer if this stuff was stored on disk and OSs never had any reason nor even possibility to tinker with motherboard's configuration memory.

But isn't boosting the security of PC systems a selling point of the UEFI/Secure boot implementation? Or was that all a lie?

I'm not sure how moving boot settings from one OS-accessible place to another improves security.

If you are bothered by people booting unauthorized disks on your hardware, enforce signature checking on OS images.

> But isn't boosting the security of PC systems a selling point of the UEFI/Secure boot implementation? Or was that all a lie?

SecureBoot is a farce. 99.99% of users will never be the target of the attack it supposedly prevents and the other less than 0.01% of users know who they are.

On top of that it doesn't even work. The premise is for it to be used in combination with full disk encryption (since otherwise the attacker could just remove the drive), to protect the integrity of the boot shim that prompts you for the decryption password so the attacker can't replace it with one that gives the attacker the password. But there is necessarily an unencrypted analog connection between the human and the computer and the attacker can still capture the password that way.

Then it was one simple step for board manufacturers to mix this with low level hardware settings which also need to be stored somewhere and produce the kind of trouble we are seeing.

The "low level hardware settings" were always stored on the motherboard, ever since the PC/AT. The big difference is that a simple CMOS reset would reset those to the defaults, and the machine would be bootable with the defaults. In the old days some errant program could corrupt CMOS (writes to port 70h/71h), but that was relatively easily fixed.

With this UEFI stuff, it appears the configuration data is stored in nonvolatile RAM, there's no easy way to "reset to defaults", and the defaults are either missing/unusable.

the machine would be bootable with the defaults

The good-old-days weren't all Wine and Roses. For example, there was this: http://webpages.charter.net/danrollins/techhelp/0054.HTM

If you wiped out CMOS, a "simple CMOS reset" was not sufficient to allow booting, because knowledge of the type of disk you had installed was lost.

Sure, you could iterate thru those preloaded disk types and stumble upon the correct one. BUT, having a fixed selection of types proved to be too limiting. So there was a scheme to add drives types. That info was also stored in CMOS, so if you lost that, it was quite difficult to restore the configuration:

   Newer BIOSes provide a means to define a custom
   setting.  The setting will be stored in an
   undocumented location in CMOS memory (and is lost
   if the battery ever fails -- so write it down!)

It wasn't an insurmountable problem. It simply meant that you had to come up with a few bytes, perhaps by calling the manufacturer or integrator. But this was in the days before Google, so it wasn't easy to find this info with a quick search.

Drives have had CHS values printed on them since the very beginning. It does mean you have to open the case to read it, but you do have to open the case to reset CMOS anyway...

But the problem of drive geometry detection essentially disappeared with IDE autodetection, which quickly became the norm sometime in the early 90s.

I think the term is second-system. It, much like ACPI and systemd (heh), has been designed with the intent of solving all the "deficiencies" of what it is replacing in one fell swoop.

https://en.wikipedia.org/wiki/The_Mythical_Man-Month#The_sec...