gforth
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gforth] setting up a linux system so to learn gfroth and GNU/linux


From: Bernd Paysan
Subject: Re: [gforth] setting up a linux system so to learn gfroth and GNU/linux
Date: Wed, 20 Aug 2014 22:51:04 +0200
User-agent: KMail/4.11.5 (Linux/3.11.10-21-desktop; KDE/4.11.5; x86_64; ; )

Am Mittwoch, 20. August 2014, 10:46:37 schrieb Anton Ertl:
> > Nope, it wasn't the printer firmware, it was the driver which ran on the
> > general purpose computer, talking to the printer.
> 
> Yes, I wrote that it was the driver.  Whether the software runs on the
> CPU of the computer or on some peripheral processor makes little
> difference as far as freedom is concerned.

Sure. But it also makes little difference if the non-free blob is stored on 
the device itself (inside a Flash, with an update possibility), or outside the 
device.  Either way, you have a device with a non-free firmware blob, and you 
could modify it.  If you look at the printer example, today you'd instantly 
know what to fix first: Remove the check for the DRM chip inside the ink or 
toner cartridge.

> If the printer maker wants to "outsource" the storage device to an
> FSF-approved distribution, and want that OS to upload the software to
> the printer, it has to use free software (e.g., Ghostscript) for the
> printer.  Or it does not outsource and pay extra for flash; that's
> then part of the cost of using proprietary software.

But this additional cost does not improve your freedom.  You've decided to buy 
some non-free hardware, where you can't change the firmware.

> > These
> > embedded devices are single-purpose things, and as a copyrighted entity,
> > all their implementation details (including the firmware) is IMHO just
> > one work.
> Actually the fact that the software only works on that particular
> hardware should make it more attractive for the manufacturer to
> provide the software part as free software.  Other manufacturers
> cannot profit directly from the software.

Indeed.  But unfortunately, these hardware people are so detached from the 
free software world that they don't get it at all.

> Not sure what the "one work" thing is about.  AFAIK that's not
> anything from copyright law.

Firmware and hardware are developed together, and therefore, the combination 
of both is the actual work.  Copyright revolves around what the artist thinks 
is the work.  We had cases where printer manufacturer argued that their ink 
cartridge is protected by copyright, because they added a DRM chip, and they 
won.

> > http://www.coreboot.org/Binary_situation
> 
> The first sentence on this page is
> 
> |While we aim for a 100% free boot process, recent developments (and
> |general unwillingness by some hardware companies to provide
> |specifications) make it hard to achieve.
> 
> That's very different from the position that you seem to take here,
> which is that we should not aim to avoid proprietary blobs.

No. I'm on the free hardware side, and think that by choosing proprietary 
hardware, you already accepted these proprietary blobs.  And since I think it 
doesn't matter where the blob actually is stored (because it's a binary blob 
regardless of location), I think this discussion about binary blobs in a 
distribution doesn't really contribute anything.  It's an arbitrary point 
where you accept your freedom to be taken away, and if you set arbitrary 
points, you probably don't have a good reason.

> And according to that page, you may be able to boot a recent AMD board
> without blobs.

Yes, apparently AMD still manages to keep the blobs inside the device.  
Probably they initialize the thing with a ROM-like mask, and fix that mask so 
that newer processors don't need updates (because there is no better microcode 
available).

The blob is still there.   It's just moved somewhere else.  You still can 
modify the firmware/microcode.  And if there's a new bug discovered, you might 
want to, maybe urgently.  Having no free microcode means you are giving away 
freedom.

> Then the hardware manufacturer then incurred a cost and (in a
> competetive market) reduced its profit by using proprietary firmware.
> 
> Also, things are done in software that are not done in firmware.
> Software not ready for prime time?  Ship the hardware anyway, we will
> update the software later, maybe automatically.  Now that our
> proprietary software phones home, what else can we do with it ...

Yes, there are ample of reasons not to trust proprietary stuff.  I'm currently 
involved in a free (as in software) hardware security module.  This is because 
a larger number of people started to distrust HSMs from vendors like RSA 
security, when it became obvious that the random number generator in these 
modules was broken, and the NSA put it there.  It is obvious that for such 
purposes, you don't want to have a proprietary hardware, which nobody can 
audit, but anybody with enough money can compromise.

> Sure, free firmware and free hardware would be great.  But even if we
> don't have that, that's no reason to ignore proprietary software blobs
> when it comes to declaring an OS "100% free software".

Yeah, it's of course in the non-free section.  You make an informed choice, 
you know what it is: It's non-free firmware for your non-free hardware you 
bought.

> And while the difference between software (dealt with by the OS) and
> firmware (stored on the peripheral) may appear negligible to hardware
> people like you, from a practical point of view it's a big difference:
> In general you cannot even tell for sure if a peripheral has firmware
> (and what it consists of), while the software blob is something the OS
> has to deal with explicitly.

I've looked at an iPhone teardown once, since my Dialog ex-boss said, Apple 
doesn't want firmware in our device (he IMHO misunderstood something, and 
Apple was actually happy that finally our chip had some firmware inside, so 
that bugs can be fixed in the field - which is very important for them), and 
found out that all bigger chips apart from Dialog's had a microprocessor and 
firmware inside.  You find the data sheets on the web (apart from Dialog's 
part, which is top secret).  I even found out for several *which* particular 
microprocessor or DSP is embedded, and those had free tools, because they were 
standard controllers (like 8051 or so).

If you had seen the "BadUSB" thing in the news, you'd know that most USB 
memory sticks apparently have the same controller inside, and just as well, 
there are free tools to write firmware for this processor.  And you can update 
the firmware with little effort, which makes them an easy attack vector (by 
e.g. pretending to be a keyboard).

So you actually can find out if there is firmware inside your device.  It's 
probably that you don't care.

> Anyway, for the original poster: This is more of a philosophical
> discussion.  If you find a 100% free distribution that works
> satisfactorily with your hardware, good for you, otherwise just use a
> distribution like Debian, Fedora or OpenSuse that includes proprietary
> blobs, and be aware of the issue (and look at the recommendations)
> when you buy new hardware.

I don't think buying non-free hardware without blob is giving you any more 
freedom.  If you have the choice to buy hardware with a free firmware blob, do 
so; more so if the hardware description itself has a free license.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

Attachment: signature.asc
Description: This is a digitally signed message part.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]