GNU Linux-libre 4.13-gnu Deblobs More Drivers

[phoron]

Linux-libre works well on a wandboard, although I don't use all features (they may or may not work). It complains of sdma engine (uses traditional DMA), and I guess wifi may not work (not tested). I'm not up to date on etnaviv userspace, though.

I find it a very useful project and wish mainstream linux was so "crippled" as libre-linux and the burden was on people adding proprietary code, not on those wanting free software.
Linux-libre is useful to see what problems with the hardware.

Some hardware may have preinstalled proprietary firmware, that's correct. But at least with linux-libre you make sure you're not updating it to newer versions with more antifeatures.
Sadly you cannot be sure anymore than vendors will limit themselves to fixing bugs. Sometimes they even OTA brick devices because they want you to buy a new one.

[starshipeleven]

Anyway, there is a reason of not including these? I mean, it's already IN the CPU anyway.

*mumble mumble* freedom *mumble mumble*

[starshipeleven]

Tell that to the Dell laptop in the office next to mine that's been running Linux-libre without a hitch for the past 3 years (Arch Parabola FSF-approved distro). Everything just works.

Could you state model or at least general hardware it has onboard?

Afaik if it does have a normal BIOS/UEFI then anything up to Ivy bridge or haswell should work fine (later Intel iGPUs need blobs, also sound also other stuff).

[Luke]

Sadly you cannot be sure anymore than vendors will limit themselves to fixing bugs. Sometimes they even OTA brick devices because they want you to buy a new one.

The fact this this has EVER happened (the Samsung phones with the exploding batteries) means you cannot safely allow any vendor on any device to push closed system updates, ever. A device on which such updates cannot be blocked is a device that must never be purchased at all. This also has the result that any device dependent on closed updates for security cannot be used as a server and cannot be used for browsing random websites at all.

If auto-updates can be disabled (as rooting a phone often does and is usually possible on Android but difficult on Windows 10), then individual updates can be checked online prior to installation. Otherwise, you get things like the manufacturer bricking recalled devices, new DRM features in firmware added to old networked printers(to block refilled ink etc) or maybe even coffee machines, that sort of thing.

At this time, vendors often take the position that the user is a hostile hacker and otherwise is a product, not the customer. For this reason I don't ever want to see things like Android vendors or Microsoft being able to find or write a kernel that is so secure that no exploit to root your own phone, laptop, or desktop is possible. Too often people have to hack into their own devices just to get control. Example is having to root phones to install system-wide adblocking via a modifed /etc/hosts file. Google sells ads and does not want ads disabled on Android phones.

Also, hacked updates to CPU microcode signed with the NSA's copy of Microsoft's key and delivered to Windows users have been suggested as an approach to taking control of computers by the US government. Linux distros presumably won't share keys this way, so their microcode updates should be safer but this depends on how good the implementation of the package signing system it. Ever since I heard about a possible weakness in Debian's package signing system, I have locally compiled by own kernels and the entire portion of the cipher stack underlying cryptsetup. This is on the assumption that few in law enforcement would want to push their precious modified source code to a known hacker who will then have posession of it, and could release it or turn it against them.

I also am keeping in place an older an presumed good set of microcode files for the CPU, new enough to get rid of any microcode bugs on that early production CPU but without regular updates a targetted attack by that vector gets much harder.

With linux-libre, an attack on burned-in microcode would require replacing the target CPU with one from the NSAS's own fab. If the microcode is stored in flash on the CPU die, it would still have to be physically intercepted for a reflash. Buying off the shelf with cash, no name, and no warranty registration blocks this line of attack.

[timofonic]

Let's just not call it a "system" as long as they do not provide working open alternatives to the proprietary stuff.
As it stands right now, this is just a crippled piece of software, more of a political statement than a practical solution.

I fully agree. To me, this isn't True Deblob (let's invent a term) at all.

True deblob would require extensive, advanced, highly skilled reverse engineering done by a very big team or equally skilled people.

The rest is just propaganda.

Free Software Foundation and GNU project: If you want to stay relevant, form a team of "Freedom Warriors" able to reverse engineer *ABSOLUTELY EVERYTHING*. I heard Russian and Chinese are very good at it, but there are others. Maybe some of them aren't motivated by money but have a strong ideology towards freedom and then copyleft, possibly being infoanarchists.

[starshipeleven]

With linux-libre, an attack on burned-in microcode would require replacing the target CPU with one from the NSAS's own fab. If the microcode is stored in flash on the CPU die, it would still have to be physically intercepted for a reflash.

Don't know what you meant to say here, so bear with me.
Microcode on the CPU die is in a good old-fashioned ROM. It's not flash. It's permanent read-only memory, written at the fab. Microcode updates must be loaded on runtime each boot.

This can be done from BIOS (which does have a place on the mobo flash chip where it stores microcodes for the CPUs it supports), or from the OS itself.

So if you want to intercept malicious NSA microcode swaps, you need to look in your board firmware first, or make sure that the OS can load your trusted microcode and overwrite whatever was loaded by board firmware.

[onicsis]

True deblob would require extensive, advanced, highly skilled reverse engineering done by a very big team or equally skilled people.

But Nouveau team had a certain degree of success, actually a good one. Until NVidia it began signing firmware for newer video cards
Maybe this large and highly skilled teams should put their efforts into designing [some] hardware from scratch.

[starshipeleven]

Sadly you cannot be sure anymore than vendors will limit themselves to fixing bugs. Sometimes they even OTA brick devices because they want you to buy a new one.

Ah come on, it's not malice, it's just that the developers are underpaid/morons/overworked and make mistakes, and there is no QA anywhere because QA costs money.

Also, I'd like to note that you are mixing up full OS updates with hardware-specific firmware updates. The fact that both are called "firmware" due to crappy legacy definitions does not make them the same thing any more than placing a gun and a potato in the same drawer makes them both a deadly weapon.

Hardware-specific firmware updates usually are fine, and usually higher-quality than full OS updates of a device firmware-OS.

[starshipeleven]

But Nouveau team had a certain degree of success, actually a good one. Until NVidia it began signing firmware for newer video cards
Maybe this large and highly skilled teams should put their efforts into designing [some] hardware from scratch.

Yeah, I second this. Reverse-engineering isn't a solution and does get into the legal territory. Open hardware, much less.

[andyprough]

Could you state model or at least general hardware it has onboard?

Afaik if it does have a normal BIOS/UEFI then anything up to Ivy bridge or haswell should work fine (later Intel iGPUs need blobs, also sound also other stuff).

It's a Dell Inspiron 17R i5 from about 2011. Might have to buy a wifi dongle with an Atheros chipset for $10 from Amazon, as the wifi chips in the laptops often need proprietary drivers. Other than that, everything should work.