| |||||||||||||
GNU Linux-libre 3.5-gnu: Free and a halfGNU Linux-libre 3.5-gnu: Free and a halfPosted Jul 23, 2012 21:02 UTC (Mon) by mslusarz (subscriber, #58587)In reply to: GNU Linux-libre 3.5-gnu: Free and a half by blitzkrieg3 Parent article: GNU Linux-libre 3.5-gnu: Free and a half They removed some left firmware files and patched out all firmware references, e.g.:
diff -ur linux.git/arch/x86/kernel/microcode_intel.c linux-gnu/arch/x86/kernel/microcode_intel.c
--- linux.git/arch/x86/kernel/microcode_intel.c 2012-07-23 22:35:28.360336765 +0200
+++ linux-gnu/arch/x86/kernel/microcode_intel.c 2012-07-22 02:07:51.000000000 +0200
@@ -412,10 +412,10 @@
const struct firmware *firmware;
enum ucode_state ret;
- sprintf(name, "intel-ucode/%02x-%02x-%02x",
+ sprintf(name, "/*(DEBLOBBED)*/",
c->x86, c->x86_model, c->x86_mask);
- if (request_firmware(&firmware, name, device)) {
+ if (reject_firmware(&firmware, name, device)) {
pr_debug("data file %s load failed\n", name);
return UCODE_NFOUND;
}
diff -ur linux.git/Documentation/arm/IXP4xx linux-3.5/Documentation/arm/IXP4xx
--- linux.git/Documentation/arm/IXP4xx 2012-07-23 22:35:26.360336729 +0200
+++ linux-gnu/Documentation/arm/IXP4xx 2012-07-22 02:07:55.000000000 +0200
@@ -35,17 +35,13 @@
See arch/arm/mach-ixp4xx/include/mach/platform.h for access functions.
- Timers (watchdog, OS)
-The following components of the chips are not supported by Linux and
-require the use of Intel's proprietary CSR softare:
+The following components of the chips are not supported by Linux /*(DEBLOBBED)*/:
- USB device interface
- Network interfaces (HSS, Utopia, NPEs, etc)
- Network offload functionality
-If you need to use any of the above, you need to download Intel's
-software from:
-
- http://developer.intel.com/design/network/products/npfamily/ixp425.htm
+/*(DEBLOBBED)*/
DO NOT POST QUESTIONS TO THE LINUX MAILING LISTS REGARDING THE PROPRIETARY
SOFTWARE.
Very helpful :/
(Log in to post comments)
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 23, 2012 21:15 UTC (Mon) by xorbe (subscriber, #3165) [Link]
They also spammed the latest /. Linux article.
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 23, 2012 22:30 UTC (Mon) by cortana (subscriber, #24596) [Link]
Well, at least they don't censor the fact that they are censoring references to the required firmware. :)
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 24, 2012 8:57 UTC (Tue) by mpr22 (subscriber, #60784) [Link] I'm deeply disappointed that they say "The following components of the chips are not supported by Linux" instead of "The following components of the chips are not supported by Linux-libre". It seems... somewhat frugal with the truth.
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 24, 2012 8:58 UTC (Tue) by mpr22 (subscriber, #60784) [Link] Psha. Partial parse failure on my part.
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 24, 2012 9:49 UTC (Tue) by dsommers (subscriber, #55274) [Link]
> diff -ur linux.git/arch/x86/kernel/microcode_intel.c linux-gnu/arch/x86/kernel/microcode_intel.c
> --- linux.git/arch/x86/kernel/microcode_intel.c 2012-07-23 22:35:28.360336765 +0200 > +++ linux-gnu/arch/x86/kernel/microcode_intel.c 2012-07-22 02:07:51.000000000 +0200 > @@ -412,10 +412,10 @@ > const struct firmware *firmware; > enum ucode_state ret; > > - sprintf(name, "intel-ucode/%02x-%02x-%02x", > + sprintf(name, "/*(DEBLOBBED)*/", > c->x86, c->x86_model, c->x86_mask);
So they even remove code which patches the CPU for vulnerabilities ... I see the purpose of being clean in regards to firmware related to I/O devices (GPU, RAID/HDD, NIC etc) - and I agree to that! But when also blocking updates of the CPU which may impact security issues and/or stability of the overall system, that seems a bit too strict.
A more suitable name for this kernel would probably be 'linux-sterile' - except it doesn't make the CPU sterile to issues. And it requires you to replace the CPU whenever a critical issue is found in the CPU core; which normally would have been patched via a microcode update.
But of course, there are other CPU vendors than Intel and AMD ... It just makes linux-libre less useful on Intel and AMD, IMO.
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 24, 2012 11:31 UTC (Tue) by gioele (subscriber, #61675) [Link]
> So they even remove code which patches the CPU for vulnerabilities
Are you sure that the microcode patches the CPU for vulnerabilities? http://www.mail-archive.com/package-announce@lists.fedora...
More seriously, <http://www.securiteam.com/securityreviews/5FP0M1PDFO.html>.
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 24, 2012 12:12 UTC (Tue) by dsommers (subscriber, #55274) [Link]
> Are you sure that the microcode patches the CPU for vulnerabilities?
> http://www.mail-archive.com/package-announce@lists.fedora...
Well, lets separate between microcode and firmware updates. It may feel like the same thing to the end user. However, you can easily replace almost any hardware device which doesn't have an open firmware or with another device doing the same job which doesn't require software loaded firmware at all.
Microcode updates are a bit different, as that patches the CPU. The CPU is far more difficult to replace, as that might even require you to replace the motherboard as well. You might even be able to live without a peripheral device not functioning, but if the CPU gives you headache - there's not an easy remedy to solve that, except of via microcode updates or replace the CPU.
Also, often a driver firmware is needed to be loaded to actually make it function at all. But a CPU must be able to boot without having received a microcode update.
Regarding if these updates fixes vulnerabilities ... Some years ago somebody explained this very well to me, but my memory isn't good enough to pin-point exactly which CPU this was and the errata from Intel. But the issue was related to that an "unprivileged" (user mode) operation could access memory regions it shouldn't have access to, due to the CPU failing to properly check if it was running in kernel mode or user mode. And a microcode update fixed this faulty behaviour.
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 24, 2012 16:09 UTC (Tue) by xorbe (subscriber, #3165) [Link]
Blocking cpu ucode patches is a really stupid thing to do. Unless you like occasional hangs and/or possible data corruption.
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 24, 2012 16:55 UTC (Tue) by patrick_g (subscriber, #44470) [Link]
I agree with you...but why this µcode is not under an open source license ? Currently it's an opaque blob.
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 24, 2012 17:31 UTC (Tue) by khim (subscriber, #9252) [Link] It's easy: µcode source includes large pieces of high value intellectual property which are related to the actual design of the CPU. Not something you want to ever expose for the competitors. Not even AMD/Intel staff have free access to the required data. Only some highly-trusted teams do. Note that most of the information is not used to create the actual binary blob (and thus can not be pulled from the end result). I think open-sourcing of this code will happen much later then out-sourcing Windows code. Which, of course, will happen when hell will freeze over few times, so...
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 24, 2012 23:04 UTC (Tue) by nix (subscriber, #2304) [Link] Not even AMD/Intel staff have free access to the required data. Only some highly-trusted teams do.Am I the only person who thinks this is absolutely hilarious? Microchip engineering is advanced technology, surely, but it is not Colossus. All the major chip companies are roughly on par with each other technologically: people flow between them, taking what they know (and despite ridiculous contracts of employment forbidding it, you cannot delete *experience* with a contract, and experience is what matters: these people know what will work and what does not). Keeping this stuff secret so your competitors won't know about it is ridiculous: they already do. But secrecy for secrecy's sake because Only We Have The Secret Sauce and Only We Have Real Engineers is a typical pathology of large companies. I wonder if anyone in them actually believes this stuff, or if they're all having a huge joke at our expense.
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 25, 2012 4:50 UTC (Wed) by jzbiciak (✭ supporter ✭, #5246) [Link] Not only that, it's not always true. I have sitting in my reading stack a rather interesting book: The Anatomy of a High-Performance Microprocessor: A Systems Perspective, ISBN 0-8186-8400-3 If you follow the link above, you'll see that it's apparently used as a textbook in many courses. It goes into incredible low-level detail about the AMD K6-III processor. It's very highly detailed about all sorts of low-level stuff, including bit-patterns used for the various internal microcode tables. This book is dated 1998, which made it current when that chip was still fairly "new". That said, such a book would have a fairly narrow audience, so I'm not surprised we don't see more of these. I'm willing to grant that this is book far more the exception than the rule. And, AMD is likely rather different than Intel. Everything I've heard about Intel (including from folks who worked there) is that information is highly compartmentalized. Also, I wouldn't be the least bit surprised if some of these updates are for "brown paper bag" bugs, and obscuring the updates softens the ego blow. Also in my office at work is a ~16 year old specification for a processor that didn't see production. Stamped all over it are "Strictly Private" declarations. It's at only a slightly deeper level of detail than the K6-III book above. We lost a lot of engineers when that project was canceled, and many ended up places like AMD, Centaur (remember them?), etc. You can bet they didn't forget what works and doesn't work. Indeed, one of the people we lost was a person we hired for his specific expertise and experience with the ISA this processor would run. Stepping back a bit: I think a big piece of it comes down to support. If you document something, you invite people to use it. If you invite people to use it, they expect some amount of support, even if you stamp all over it that there is no support. The support burden may be indirect: Somebody tweaks their microcode, shares it with folks who install it without realizing what they're signing up for, and machines start failing mysteriously. That puts more support calls into the channel. Microcode also has another special property: It's essentially another instruction set, and one that's highly subject to change, perhaps even between steppings of the same device. Documenting it would in some sense "fix" it. In any case, refusing to load a microcode blob into a CPU is just silly. You're no less free than if you force people to go buy a newer stepping of the CPU you already have, but which has the update in its microcode ROM already. It makes no sense. How is ROM you can't access or change more free than RAM that holds a copy of the same bits?
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 25, 2012 5:29 UTC (Wed) by raven667 (subscriber, #5198) [Link]
> How is ROM you can't access or change more free than RAM that holds a copy of the same bits?
The strict FSF position is that the difference is that it's changeable, in the way that software is, but that you don't have the rights or the tools to do so but the manufacturer does have those rights and tools so it is not an equitable arrangement. At least that's my understanding. In any of the copyleft licenses like the GPL all parties have an equal and high level of rights to the software, rights that usually only the author has, to inspect, modify, distribute, and in the case of the GPLv3, run the result on the target hardware.
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 25, 2012 20:53 UTC (Wed) by khim (subscriber, #9252) [Link] The strict FSF position is that the difference is that it's changeable, in the way that software is, but that you don't have the rights or the tools to do so but the manufacturer does have those rights and tools so it is not an equitable arrangement. Right. This is what they preach. Sadly this is not what they do. Let me remind you one fact, which is vital for the understanding of my ire: Some CPUs can boot Linux but need blobs to run it correctly. Now we have two choices:
The FSF-advocated solution (hardware without any binary blobs) no longer exist. Now, in this world, in this reality the solution where OS brings the required blob is obviously more robust (it's easier to update small microcode as compared to the whole firmware: microcode is provided by Intel where BIOS blob is provided by motherboard manufacturer and usually quite old and buggy), easier to hack (format of microcode is unknown, but it's loaded on each reboot anew thus it's safer to experiment with it) and thus better for any user (user who don't care about freedom get more robust system, user who cares about freedom gets more hackable system). But for some reason FSF pushes for the other, worse solution. Why? What's the point?
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 27, 2012 0:10 UTC (Fri) by cry_regarder (subscriber, #50545) [Link]
Because by their position, doing otherwise is aiding and abetting? You may not find their position pragmatic, but it is principled.
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 27, 2012 0:32 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
> Because by their position, doing otherwise is aiding and abetting? You may not find their position pragmatic, but it is principled.
No, we find their position unprincipled as it specifically demands that the vendors _reduce_ the control the user has over the device (unless the vendor gives complete control)
saying that devices with firmware blobs are bad is very legitimate.
saying that it's better to have devices with firmware blobs that the user cannot replace (or can only replace if they use proprietary software) than to have firmware blobs that the user can replace with free software is crossing a line that gets them called out. This is letting their rules violate the principles they claim to have.
Free Circuits Foundation Posted Jul 25, 2012 12:24 UTC (Wed) by man_ls (subscriber, #15091) [Link] How is ROM you can't access or change more free than RAM that holds a copy of the same bits?Elaborating on the above post: the Free Software Foundation believes that ROMs are similar to circuit schematics, and it is not called the "Free Circuits Foundation" (as cool as that would sound). Software is infinitely malleable, while hardware is set in stone the moment it is produced. If the firmware can be updated it is software; otherwise it is hardware. It is a very simple criterion that does not imply freedom. The point is that firmware (as software) is quite conveniently upgradeable, and that users should have the right to choose what software runs on their machines. With hardware the right to choose is exercised at the shop counter, and stops there. Answering to grandparent: industrial secrets are a problem of the manufacturer; if they place their convenience (to keep designs in secret) above mine (to choose what software I am running), there is a priority inversion somewhere.
Free Circuits Foundation Posted Jul 25, 2012 18:14 UTC (Wed) by khim (subscriber, #9252) [Link] Elaborating on the above post: the Free Software Foundation believes that ROMs are similar to circuit schematics, and it is not called the "Free Circuits Foundation" (as cool as that would sound). Software is infinitely malleable, while hardware is set in stone the moment it is produced. If the firmware can be updated it is software; otherwise it is hardware. It is a very simple criterion that does not imply freedom. Yes, this is simple criterion but this is not the criterion used in Linux-libre. Instead of supporting only hardware which does not need any non-free software it supports only the hardware which brings it's own binary blobs on it's own flash and rejects devices which keep said blobs in main OS distribution. I still fail to see how exactly removal of my ability to [potentially] tinker with a piece of of something frees me. It certainly frees my pockets (since the hardware if the first kind tends to be more expensive), but I'm not sure that's what FSF is trying to achieve. Answering to grandparent: industrial secrets are a problem of the manufacturer; if they place their convenience (to keep designs in secret) above mine (to choose what software I am running), there is a priority inversion somewhere. Not really. When you bought the hardware you knew that it'll require this binary blob to function properly. If it's fair or not is irrelevant. You've accepted the hardware and you are stuck with it. Now, again, I can understand the position "we will never support any piece of hardware which uses non-free software". This can be a "heroic" effort: reject all the HDDs, SSDs, eMMC, AMD/Intel/NVidia/Quallcom CPUs (which all require binary blobs to functions) and try to create some "new free world" on this basis. But to reject (or poorly support in case of CPU) hardware which needs some blobs while simultaneously produce good support for hardware which is literally identical but includes said blobs in flash... that's fanaticism, pure and simple. I can understand the concerns related to copyright (what if this blob is non-redistributable? big problem then), but from freedom POV that's obvious case of "redoubling the efforts when you have forgotten your aim".
Free Circuits Foundation Posted Jul 25, 2012 19:34 UTC (Wed) by gioele (subscriber, #61675) [Link]
> But to reject (or poorly support in case of CPU) hardware which needs some blobs while simultaneously produce good support for hardware which is literally identical but includes said blobs in flash... that's fanaticism, pure and simple
How is this different from binary blobs for anything else? Printers for example: most of them are paperweights without their binary blobs.
The Stallman's and FSF's point is that you should have access to the sources (and necessary build environment) of any user installable software. Regardless of the goodness of point itself, it is hard to understand why so called "firmware" is any different from normal "driver" software from this point of view. They are both collections of executable instructions compiled from sources, installed into a memory connected to a CPU and such instructions are used to drive the behaviour of an hardware component.
Free Circuits Foundation Posted Jul 25, 2012 20:30 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
>The Stallman's and FSF's point is that you should have access to the sources (and necessary build environment) of any user installable software. Regardless of the goodness of point itself, it is hard to understand why so called "firmware" is any different from normal "driver" software from this point of view.
Let's see. FSF declares 3 main freedoms:
>0. The freedom to run the program, for any purpose (freedom 0).
>1. The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.
>2. The freedom to redistribute copies so you can help your neighbor (freedom 2).
>3. The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.
Basically, devices like network cards were never designed to run arbitrary software. So I fail to see how 3 freedoms might be violated.
Free Circuits Foundation Posted Jul 26, 2012 1:39 UTC (Thu) by jebba (✭ supporter ✭, #4439) [Link]
>>1. The freedom to study how the program works
> > you can run anything you want on your computer. The details of firmware blobs do not matter to applications running on the CPU
Incorrect.
The program the FSF is talking about in this case is the blob, not what is running on your CPU. It doesn't matter *which* chip is running the code; whether it runs on your main CPU or a chip on your network card is irrelevant.
Free Circuits Foundation Posted Jul 26, 2012 1:45 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
So do they also require VHDL/Verilog source code for the main CPU? After all, you might want to tweak it!
Firmware blobs are even with compliance with GPL since they are executed on a separate embedded computer which interacts with the main CPU using well-known industry standard protocols (signaling over PCI/PCIe/whatever).
Free Circuits Foundation Posted Jul 26, 2012 15:29 UTC (Thu) by jebba (✭ supporter ✭, #4439) [Link]
> So do they also require VHDL/Verilog source code for the main CPU? After all, you might want to tweak it!
Do you really think the FSF's four freedoms require the design code to the CPU?
> Firmware blobs are even with compliance with GPL
The firmware blobs themselves may not be GPL'd themselves though, making them non-free.
> they are executed on a separate embedded computer
Which processor they run on is irrelevant from the perspective of the FSF.
Free Circuits Foundation Posted Jul 26, 2012 20:45 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
>Do you really think the FSF's four freedoms require the design code to the CPU?
And why do they require design of network card's microcode? What's the difference?
>The firmware blobs themselves may not be GPL'd themselves though, making them non-free.
>Which processor they run on is irrelevant from the perspective of the FSF.
Free Circuits Foundation Posted Jul 26, 2012 21:44 UTC (Thu) by jebba (✭ supporter ✭, #4439) [Link]
>>Do you really think the FSF's four freedoms require the design code to the CPU?
>And why do they require design of network card's microcode? What's the difference?
Microcode/firmware is a software application with source code. The design files are to manufacture hardware, they aren't applications. I presume you know this though.
>>The firmware blobs themselves may not be GPL'd themselves though, making them non-free.
We're talking about the Free Software Foundation, not the Free Hardware Foundation.
>>Which processor they run on is irrelevant from the perspective of the FSF.
Meh, I've been bitten by a troll.
Free Circuits Foundation Posted Jul 26, 2012 21:49 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
>Microcode/firmware is a software application with source code.
Nope. Microcode is an essential part of the hardware.
>The design files are to manufacture hardware, they aren't applications.
> We're talking about the Free Software Foundation, not the Free Hardware Foundation.
> Meh, I've been bitten by a troll.
Free Circuits Foundation Posted Jul 27, 2012 2:45 UTC (Fri) by jzbiciak (✭ supporter ✭, #5246) [Link] Microcode/firmware is a software application with source code. The design files are to manufacture hardware, they aren't applications. I presume you know this though. Are you familiar at all with FPGAs and CPLDs? I'll give you a hint: The "P" stands for "Programmable." Many of these require their bitstreams to be loaded at power-up before they perform their function. This bitsteam is loaded from some other device on the board, most often some form of serial EEPROM or flash. Often, the logic that's in these same FPGAs and CPLDs will get reduced to an ASIC if the volumes are high enough, but not always. The source code for the FPGA/CPLD is the same source code used to produce the ASIC, generally. Microcode is essentially a part of the design that's been moved from the fixed-in-transistor domain (much like an ASIC) to the programmable domain. The same source code (also likely in the same sort of HDL, although perhaps a custom HDL for the purpose) underlies both. Microcode compiled to a ROM instantiated in transistors is as much an "application with source code" as the very same microcode compiled to an image loaded into the patch-RAM next to the ROM it replaces. The bright line you suggest exists doesn't. Here's an example of a microcode ROM embedded in a voice-synthesis processor. It's 2K bytes, so it's reasonable to suggest it had source code associated with it. This ROM contains control sequences for making various sounds "baked in" to the chip. The chip is sold as a product that makes specific vocal sounds listed in the datasheet. If I replaced this ROM with a RAM and required you to load a bitstream to make this processor functional, are you suddenly less free? I'd argue that because you can now receive bug-fixes, I've only increased the value of this part to you. As a matter of fact, the specific device I took that clip from has a pin that disables the internal ROM and lets you fetch that same control data from external memory. Because that's technologically possible, are you saying free software should not use this chip? Or it should only use this chip with the original baked-in ROM?
Free Circuits Foundation Posted Jul 27, 2012 2:48 UTC (Fri) by jzbiciak (✭ supporter ✭, #5246) [Link] Microcode is essentially a part of the design that's been moved from the fixed-in-transistor domain (much like an ASIC) to the programmable domain. The same source code (also likely in the same sort of HDL, although perhaps a custom HDL for the purpose) underlies both. I meant to say "Loadable microcode" above. My point is, what is so magically freeing about baking microcode into ROM vs. allowing it to be overridden by a copy in RAM? The manufacturer sells you a hardware device that only they have the capacity to modify. Just, in one case you have to buy an entirely new chip to get an update, and in the other, they can send you a field update. The line between hardware and software is often blurry, which is why terms like "firmware" exist.
Free Circuits Foundation Posted Jul 26, 2012 20:53 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
> Which processor they run on is irrelevant from the perspective of the FSF.
right, according to them what matters is if the software has any ability to be upgraded.
according to the FSF logic, they would be happy to have a system that booted from Windows in ROM (because it can't be updated by the manufacturer or the user), but are unwilling to have Linux run on a system that has a video card with the ability to update the firmware stored in flash on the video card.
Guess what, there are a lot of companies that would love to sell you a non-updateable device that you replaced every time there was a new update required.
do you really think that would be a better world?
Free Circuits Foundation Posted Jul 26, 2012 21:49 UTC (Thu) by jebba (✭ supporter ✭, #4439) [Link]
> unwilling to have Linux run on a system that has a video card with the ability to update the firmware stored in flash on the video card.
Where do you get this from? RMS himself used proprietary systems to bootstrap everything, and I bet there are plenty within FSF which may have a system which may have a part that can be flashed. I don't think they've ever said "never run a system which can be flashed". What they are doing is distributing software which removes non-free parts and references.
You are confusing their goal of systems that have free/open firmware, with a mandate that you can't use a system that isn't 100% perfect.
Free Circuits Foundation Posted Jul 26, 2012 22:03 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
If they have no objection to running things in ROM, but do have objections to the OS loading binary blobs into the processor, then they should not object to running a system with the OS in ROM, but (as this topic shows), they do object to running a system with free software that loads a binary blob into another piece of hardware (like a video card) to run on that other hardware.
The Openmoko example where they wanted to have them modify the hardware to make it impossible to replace a binary blob rather than have the identical blob loaded from the OS is a perfect example of them following their policy to it's illogical extreme.
Given two devices that are otherwise identical, they should prefer the device that has the software/firmware able to be replaced by the user over the device that the user cannot replace the software on.
Yes, it's far better if the software being loaded is open, nobody is disagreeing with that. What we are disagreeing over is the idea that hardware the user cannot load software on is better than hardware the user can load software on.
Free Circuits Foundation Posted Aug 2, 2012 12:37 UTC (Thu) by TRauMa (guest, #16483) [Link]
What I don't get is that you keep talking about the user being able to replace the blob. Replace with what? He can't create a new blob, he can't make changes to the original blob - the only thing he *can* do is replace it with another blob from the vendor.
On a system where this is possible, he can actually be coerced to "upgrade", and there may be other "functionality" baked in that he doesn't want.
On a system where this is not possible, the vendor has no easy way to make the system less free after the fact. Given this, the user is protected better.
Free Circuits Foundation Posted Aug 2, 2012 13:30 UTC (Thu) by mjg59 (subscriber, #23239) [Link]
Reverse-engineered free firmware was developed for the PCI Broadcom 802.11 devices, permitting them to be used for academic research into new wireless protocols. That would have been impossible if the firmware had been in ROM.
Free Circuits Foundation Posted Jul 27, 2012 8:51 UTC (Fri) by etienne (subscriber, #25256) [Link]
> do you really think that would be a better world?
It may become a better world, long term, because the company selling you a new hardware to fix a bug you need becomes very expensive, no one buy anything more from them, and they go bust.
Free Circuits Foundation Posted Jul 26, 2012 10:15 UTC (Thu) by khim (subscriber, #9252) [Link] The program the FSF is talking about in this case is the blob, not what is running on your CPU. It doesn't matter *which* chip is running the code; whether it runs on your main CPU or a chip on your network card is irrelevant. This is their pretence, not reality. If they were consistent then Linux-libre announce will looks somewhat like this: Here is our 100%-free version of GNU/Linux OS. To use it you need to dig i80386 CPU somewhere (80486 and newer are not supported because they need microcode and we don't have source for said microcode), find one of these ten motherboards (which are compatible with coreboot; BIOS and UEFI are not supported because they use proprietary binary blobs without source), dig out and restore dizen on RLL hard drives (IDE, SCSI and other such beasts are not supported because they include binary blobs and single RLL hard drive is not big enough to contain this version of Linux-libre), find twenty-years old Ethernet card (all the newer ones are not supported for the same reason… of course very few old ones are supported either)… and enjoy your freedom… if you can. Instead they support bazillion devices with upgradeable firmware which only exist without source. Everything which contains binary blobs in supplied flash is supported while everything where binary blob is supplied by OS is not. This is hypocrisy, plain and simple: they pretend they are fighting against binary blobs, but in reality they just sweep the problem under the carpet. The whole project is huge embarrassment for FSF - it just portrays them as hypocritical fanatics.
Free Circuits Foundation Posted Jul 26, 2012 15:37 UTC (Thu) by jebba (✭ supporter ✭, #4439) [Link]
> This is their pretence, not reality
This is outright false.
There are many network cards that don't require blobs, for instance. In fact, most don't need need firmware uploaded to them. The list of kernel drivers far exceeds the list of firmware blobs in linux-firmware.
You don't need coreboot for them to distribute a free kernel. You don't need coreboot for them to distribute a free OS. You would need coreboot if you wanted your system to be 100% free, but that is separate from what they *distribute*.
In fact, if what you were saying is true, basically no one would be able to run the linux-libre kernel, yet people do. How do you reconcile that?
Free Circuits Foundation Posted Jul 26, 2012 16:03 UTC (Thu) by nybble41 (subscriber, #55106) [Link]
> There are many network cards that don't require blobs, for instance. In fact, most don't need need firmware uploaded to them.
I think you're missing the point. These CPUs don't require microcode blobs. Their original microcode is stored in a ROM on the chip. You only need a blob if you want to _update_ the microcode. Similarly, most network cards have firmware in flash memory which _can_ be upgraded, but doesn't need to be uploaded after every reboot.
The FSF isn't removing the firmware itself (which wasn't included to begin with), or even the ability to load it. They're just censoring information about it from the kernel source and log messages, and thus preventing users from making an informed decision between keeping the non-free firmware/microcode they received with the device, or loading a different non-free firmware/microcode version which may work better. It would be rather destructive if anyone was actually forced to use their version; I certainly don't see how removing this information adds any value.
Free Circuits Foundation Posted Jul 26, 2012 16:30 UTC (Thu) by khim (subscriber, #9252) [Link] There are many network cards that don't require blobs, for instance. No. There are many cards which come with blob preinstalled on flash. In fact most PCI and probably all PCI devices need some kind of blob to even be recognizable by the host. The list of kernel drivers far exceeds the list of firmware blobs in linux-firmware. What this has to do with anything? You would need coreboot if you wanted your system to be 100% free, but that is separate from what they *distribute*. Yes. But what exactly they are distributing? The answer is obvious: system which works just fine on "car with the hood welded shut" but refuses to work with a car where hood is open but mechanics under it is unknown. Is it really the direction they want to push the industry in? In fact, if what you were saying is true, basically no one would be able to run the linux-libre kernel, yet people do. How do you reconcile that? Have you actually read what I wrote? Any system chock-full of undecipherable binary blobs is fine - as long as said blobs come preinstalled. Only systems where said blob comes from the OS (and thus available for hacking even if not in source form) are excluded. IOW: if you take Linux-libre as a stance it says basically this: Moar blobs, we need moar! Make sure they are as hard to obtain and modify as possible, remove all hope of any access to the actual hardware - and we'll be happy. PS3 firmware of 200MiB of god knows what which is required to use the thing? Yes, please: this is what we want. As long as all the stuff which makes the hardware uncontrollable by user comes preinstalled - we are happy. We don't want to ever access it, it can't hack it at all - it's even better. FSF is still fighting windmills while world moved on and we have totally different problems WRT our ability to control the hardware we own.
Free Circuits Foundation Posted Jul 26, 2012 21:57 UTC (Thu) by jebba (✭ supporter ✭, #4439) [Link]
> PS3 firmware of 200MiB of god knows what which is required to use the thing? Yes, please: this is what we want.
Really? You think that is what they want? I don't get why firmware brings out the trolls so heavily. You are obviously shoving words in their mouth that are far, far, far from what their actual goals are.
Now, you can say RMS is going about it wrong. But this is the man that made a lot of this system we are using, and has made other major contributions (e.g with wikipedia). I'll take his path over yours, as you seem quite disingenous and he has produced *many significant* real-world results.
Free Circuits Foundation Posted Jul 27, 2012 8:10 UTC (Fri) by khim (subscriber, #9252) [Link] You think that is what they want? This is what Linux-libre wants. Yes, FSF claims that PS3 is awful piece of shit, but… actions speak louder then words. And PS3 is better-supported target that other, freer systems as far as Linux-libre is concerned. I'll take his path over yours, as you seem quite disingenous and he has produced *many significant* real-world results. It's your choice. Only please, remind me what significant real-world results he produced WRT to OS kernel? AFICS he produced couple of miserable failures (HURD is technical failures while Linux-libre is ideological failure). In other ares, yes, RMS is formidable, in the area of OS kernel development… not so much.
Free Circuits Foundation Posted Jul 25, 2012 20:32 UTC (Wed) by khim (subscriber, #9252) [Link] How is this different from binary blobs for anything else? It's [mostly] the same, of course. Printers for example: most of them are paperweights without their binary blobs. Most???? Hardly. Very few of them require binary blobs to be uploaded before you can use them. What they usually require instead is very complex and heavy prepossessing done on your system. And yes, these "blobs" can frequently mess with your system and they are despised and reviled for this reason. But [rare] printers which don't need such complex dances but instead have multimegabyte blob which you can shove via USB to the device which can then be used using standard protocol (usually PostScript)… yes, these can be treated similarly to HDD or CPU. IOW: you are correct when you point out that not all binary blobs are created equal. If they are injected in your system (and especially if they are injected in your kernel) then they are dangerous. And there are grey area, too. But the dichotomy used by FSF (binary blob is Ok if it comes preinstalled on the flash but it's not Ok if it must be uploaded on system startup) makes no sense whatsoever. Think about it: RMS started with the infamous printer problem. With clear problem (printer driver was crap) and obvious solution (if it's broken you can try to fix it) which met surprising wall (source was not available and thus unhackable). The long-term solution offered was free-software: if all the software in use will come with sources then it'll be easy (or at least possible) to fix problems. This is audacious and extremely long-term solution and I can only applaud for the RMS's bravery (this is honest opinion, not sarcasm). But… let's see on the situation in XXI century, shell we? Today we have two types of hardware:
Hardware which does not require any blobs are surprisingly rare today: even "simple" things like LCD controller or Ethernet adapter nowadays include [relatively] powerful CPU and firmware blob. The Stallman's and FSF's point is that you should have access to the sources (and necessary build environment) of any user installable software. Bingo! And now, in this world, where every chip has some kind of firmware, FSF approach leads to the "solution" which is not only more expensive, but also less hackable! FSF's preferred "solution" is always, always, ALWAYS worse from the hackability POV! If the binary blob is uploaded from the host system then there are quite real possibility that someone will be able to reverse-engineer it and fix it. If blob is sealed in flash then it's unhackable. Remember the Santayana’s definition? "Fanaticism consists in redoubling your efforts when you have forgotten your aim". If this is not an example of fanaticism then what is? When you reach the stage where you push for the "solution" which makes the original problem which started the whole movement worse… I just don't know what to say after this point. Regardless of the goodness of point itself, it is hard to understand why so called "firmware" is any different from normal "driver" software from this point of view. Rilly? You don't understand? Driver is embedded in your OS execution environment. It can affect literally every aspect of your system (especially if it's kernel-level driver, but even if it's merely a binary blob executed with root privileges it's still quite invasive). Firmware, on the other hand, is executed on physically separated CPU in restricted environment. Microcode blob for the CPU is interesting corner-case: it's executed on your CPU and can, theoretically, do anything... but you can not avoid that. Without this binary blob contemporary CPU can not ever boot Linux-libre! The only difference between having microcode blob in BIOS and having it in Linux is the possibility of upgrade: it's harder and riskier to upgrade BIOS.
Free Circuits Foundation Posted Jul 27, 2012 22:43 UTC (Fri) by pabs (subscriber, #43278) [Link]
Printers run (proprietary) operating systems, some of which have had security researchers look for and find vulnerabilities. I for one want to be able to run Free Software (such as Debian) on my printer. You seem to be talking about host-side printer drivers rather than printer operating systems.
Free Circuits Foundation Posted Jul 27, 2012 23:03 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
some printers run operating systems, some are little more than a buffer driven from the main CPU (the buffer is just because the CPU allocation on the main CPU may not be stable enough.
This is very similar to the modem/winmodem split where the modems had dedicated hardware to process the data and the winmodems were little more than sound cards that could hook to a phone line.
At the low end, khim is right, at the high end, you are right.
But in any case (getting back to the topic at hand), are you really more free with a printer that you can't upgrade the software on than with one that you send a binary blob from the OS to initialize?
Free Circuits Foundation Posted Jul 28, 2012 4:46 UTC (Sat) by scientes (guest, #83068) [Link]
today even the low end printers often run full operating systems. You can bet your ass all the printers with SD slots are sure full operating systems.
Free Circuits Foundation Posted Jul 25, 2012 20:15 UTC (Wed) by jzbiciak (✭ supporter ✭, #5246) [Link] How about HDLs? Most (all?) CPUs have large components written in a hardware design language such as VHDL or Verilog, which is then compiled down to gates and ultimately transistors. The same HDL can often be compiled for an FPGA. I find the FSF's position somewhat inconsistent inasmuch as CPUs can be software, but they're not demanding the source code for the CPUs they run. The OpenCores projects at least look to change that. The position of the hardware vendors (and one that I personally find reasonable) is that they're selling you something that should be considered hardware. The fact that they have some mechanisms to fix hardware bugs without fully discarding and replacing it does not change the fact that it's hardware. It would be little different than the days when CPUs were made of discrete logic, and a technician could come and blue-wire the board or swap out a component here or there to fix/improve its behavior. Just like the kernel / user-space interface, the CPU's instruction set and registers for the CPU form the hardware/software boundary. That is, the boundary is defined by the programmer's model of the machine. Microcode is not part of the programmer's model. These microcode updates, IMHO, are on the hardware side of the boundary, and have similar semantics to the blue-wire scenario above. At the computer shop, you don't generally know what stepping CPU you're getting, so you can't crack open the processor's (usually lenghty) errata document and determine what bugs you're buying. But, microcode updates allow processor vendors to fix bugs in older steppings to address errata and make them more like newer steppings. As a result, we all get cheaper processors faster, and are insulated from bugs that might creep in. I'm OK with this. I don't see it infringing on my freedoms to write whatever software I like to run on said computer. I see it as a cheaper but semantically equivalent step to just replacing a processor with some defects with another with presumably fewer defects. Blocking microcode updates just tilts too hard at windmills for my taste.
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 24, 2012 16:37 UTC (Tue) by lindi (subscriber, #53135) [Link]
Is there a git repo for linux-libre somewhere? Their tools seem to be focused on tarballs.
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 24, 2012 21:22 UTC (Tue) by lxoliva (subscriber, #40702) [Link]
Not yet, I'm afraid. There are plans to create a deblobbed git repository tracking upstream, but we don't have the code to write a clean history so that we don't end up offering the very traps we set out to disarm.
This plan will require improvements to the deblobbing infrastructure that will enable us to fix the long-standing implementation bug that completely disables the blob-loading machinery. The intent is to avoid asking for blobs, but the Linux interface makes it hard to avoid that without also preventing users from loading the blobs if they really mean to. The solution for that is awkward, and not really achievable with the current deblobbing machinery.
There are also plans to improve git so as to enable back-and-forth merging between clean and blobful trees, to make cooperation easier without betraying our principles, but we're not there yet. We can always use help! More brains are welcome ;-P :-D
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 25, 2012 8:02 UTC (Wed) by gioele (subscriber, #61675) [Link]
> There are also plans to improve git so as to enable back-and-forth merging between clean and blobful trees,
Have you got any pointer to these plans? Such modifications to git would be very helpful to all the projects that maintain patches on top of git trees, think OpenWRT or all the Debian packages.
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 25, 2012 9:45 UTC (Wed) by lindi (subscriber, #53135) [Link]
Well I wanted git precisely to be able to observe the history. How the number of modifications to mainline change over time for example. I don't want to start unpacking hundreds of tarballs and running diff against them..
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 24, 2012 17:04 UTC (Tue) by nix (subscriber, #2304) [Link]
It's interesting that they deblob the intel microcode driver, given that the microcode it accepts is not so much 'non-free' as 'just plain unavailable'. (Unless you split up the microcode files Intel *does* make available -- by hand, as far as I can tell -- you still have to use microcode_ctl to load them. Not that those files are even slightly free, hell, there isn't even a changelog.)
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 24, 2012 21:38 UTC (Tue) by lxoliva (subscriber, #40702) [Link]
Have you actually looked at the license of the microcode blobs? It's not just that they're software without corresponding sources, the license is also quite obnoxious! Sorry, I'm about to hit the road for FISL so I don't have it handy, but it shouldn't be too hard to find the license file if you have the blob (and its userland loader) installed on your system.
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 24, 2012 23:01 UTC (Tue) by nix (subscriber, #2304) [Link]
Oh, I'm aware the license for the blobs Intel provides is obnoxious -- but the blobs Intel provides are *not* the blobs that were deblobbed from the Intel microcode driver! The blobs that driver accepts are mythical things available nowhere at all (but which rumour has it that scripts that are banging about in various places on the Internet may or may not be able to produce from the blobs Intel does provide). One wonders whether a blob that doesn't exist is somehow even less free than a blob that does who-knows-what that is provided without changelog and without indication of wtf it fixes...
|
|||||||||||||
