Stallman rants about FreeBIOS

[Ketil Malde]

It is really hard to see how that could happen without turning the
whole world of Linux software upside down. Maybe I just lack
imagination.

I agree it's not likely to happen to computing in general. I don't
consider it unlikely to happen to niches -- after all, it is
approximately how the (unmodified) X-box works.

Let's say Sony (since it's more Linux agnostic) sets up PS3 to only
boot signed OSes. I don't think that's very far-fetched. Then they
are free to provides a signed Linux kernel for it, and thus you get to
run GPL software on it, without actually getting the freedoms the GPL
was supposed to ensure.

Or, rather, the only way I see it happening is if the content owners
give enough money to get congress to mandate such a thing.

If it is presented as elimination of software piracy and copyright
breach, I'm sure you could get at least some elected officials to
listen (even if very few in the industry actually want this to
happen).

-kzm

 

[Bernd Paysan]

The problem is also that this represents a loophole in the GPL. If
you embed DRM in the hardware and require the OS to be signed¹,
you could distribute GPL-compliant source code to your hearts content,
without granting the users the freedom to actually *run* modified
code.

As I understand, the GPL requires you to ship *all* sources. If the
signature of the OS binary is a fundamental part of its functionality, you
have to include this private key into the source distribution.

 

[Robert Myers]

I also had the impression that EFI applications could be using
bytecodes. I am sure it is not required, but isn't this a possibility ?

http://developer.intel.com/technology/efi/main_specification.htm

<quote>

The EFI Driver Model is designed to be generic and can be adapted to
any type of bus or device. Also included in the EFI 1.10 Specification
is a set of companion documents that describe how to write PCI bus
drivers and PCI device drivers. These companion documents also
describe how to store an EFI driver in a PCI option ROM while
maintaining compatibility with legacy option ROM images. The EFI
Driver may be compiled for EFI Byte Code to enable a single image to
support multiple platforms, including IA-32 and Itanium®.

</quote>

RM

 

[David]

The problem is also that this represents a loophole in the GPL. If
you embed DRM in the hardware and require the OS to be signed¹,
you could distribute GPL-compliant source code to your hearts content,
without granting the users the freedom to actually *run* modified
code.

You also have to include all required tools for building your modified
code and making it runable, as part of the "source" of the gpl'ed code.
You don't have to include source for those tools, as long as you have the
rights to distribute them. You also don't have to distribute standard
tools for the system used for compilation - that means you don't need to
include gcc, make, or whatever with the source code. But if you binary
needs to be signed with a non-standard tool or using a non-standard key,
you'd have to include the tool and key with the source code. So there is
no loophole (assuming my interpretation of the GPL is correct, of course)
- you can't distribute GPL'ed software for a DRM platform without
publishing the keys and defeating the whole point (if there ever was a
point) of DRM.

 

[Eric Gouriou]

Nope. EFI and EFI applications are architecture specific - IA32 or
IA64 right now.

I also had the impression that EFI applications could be using
bytecodes. I am sure it is not required, but isn't this a possibility ?

A search for "EFI application bytecode" returned this:
<URL:http://www.kernelthread.com/publications/firmware/>

In all those posts I didn't see a single reference to EFI being
mostly open-sourced already:
<URL:http://www.tianocore.org/>

Intel selected the BSD license for this code. I imagine that
the GPL may have caused quite a few legal issues for hardware
manufacturers. I understand that the code is not complete, however
it shouldn't be a surprise to anyone, given that Intel also needs
the support from traditional BIOS companies to promote EFI.

Eric

(who never had anything to do with EFI besides booting IPF
hardware)

 

[Casper H.S. Dik]

As I understand, the GPL requires you to ship *all* sources. If the
signature of the OS binary is a fundamental part of its functionality, you
have to include this private key into the source distribution.

Why the private key? Wouldn't just the signature suffice? After
all, it *is* sufficient to reproduce the binary.

I think requiring the private key is a stretch; if are also not
required to ship the sources of whatever else the linker deposits
in the binary, such as crt0.o, any shared data from libc, etc.

Casper

 

[Casper H.S. Dik]

The EFI Driver Model is designed to be generic and can be adapted to
any type of bus or device. Also included in the EFI 1.10 Specification
is a set of companion documents that describe how to write PCI bus
drivers and PCI device drivers. These companion documents also
describe how to store an EFI driver in a PCI option ROM while
maintaining compatibility with legacy option ROM images. The EFI
Driver may be compiled for EFI Byte Code to enable a single image to
support multiple platforms, including IA-32 and Itanium®.

Ah, the reinvention of IEE1275.

Casper

 

[Casper H.S. Dik]

There were mentions of OpenFirmware in this thread. My understanding
is that OpenFirmware, while defined by some (ISO?) standard, is not
open by the current standards of 'Free Software' proponents. My impression
is that EFI ends up being more open, which probably annoys some zealots
so much that they have to conveniently ignore the facts (I am not
talking about RMS here).

Why is Open Firmware not open? Just because the Free Software
Zealots redefined what open means? C'mon.

I don't think there are free OpenFirmware implementation.

Casper

 

[Eric Gouriou]

http://developer.intel.com/technology/efi/main_specification.htm

<quote>

The EFI Driver Model is designed to be generic and can be adapted to
any type of bus or device. Also included in the EFI 1.10 Specification
is a set of companion documents that describe how to write PCI bus
drivers and PCI device drivers. These companion documents also
describe how to store an EFI driver in a PCI option ROM while
maintaining compatibility with legacy option ROM images. The EFI
Driver may be compiled for EFI Byte Code to enable a single image to
support multiple platforms, including IA-32 and Itanium®.

</quote>

Thanks, however Fred's post already mentioned that drivers could
be using bytecode. The question is about EFI 'applications', since
Fred appeared to make a distinction between driver and application.
I was not aware that there was a distinction between the two.

There were mentions of OpenFirmware in this thread. My understanding
is that OpenFirmware, while defined by some (ISO?) standard, is not
open by the current standards of 'Free Software' proponents. My impression
is that EFI ends up being more open, which probably annoys some zealots
so much that they have to conveniently ignore the facts (I am not
talking about RMS here).

Repeated disclaimer: I am just an interested bystander when it comes
to EFI.

Eric

 

[Robert Redelmeier]

You also have to include all required tools for building
your modified code and making it runable, as part of the
"source" of the gpl'ed code.

Where does it say this in GPL v2 ?

This is a hole I expect closed in v3.

-- Robert

 

[Bernd Paysan]

Why is Open Firmware not open? Just because the Free Software
Zealots redefined what open means? C'mon.

Note also that the way Open Firmware exchanges drivers is by tokenized
*source*. Not exactly what Free Software Zealots want (comments don't get
tokenized), but close enough for all practical purposes.

I don't think there are free OpenFirmware implementation.

www.openbios.org

Not completed, but with rapid progress.

 

[Toon Moene]

The problem is also that this represents a loophole in the GPL. If
you embed DRM in the hardware and require the OS to be signed¹,
you could distribute GPL-compliant source code to your hearts content,
without granting the users the freedom to actually *run* modified
code.

According to humorix.org (http://humorix.org/articles/2004/12/preview/),
in their "Year 2005 in preview" this will be solved by RMS, thusly:

Dec. 2 -- The newly created Free Hardware Foundation, headed by Richard
M. Stallman, finally demonstrates a practical, non-evil application for
DRM hardware. Using an open BIOS architecture, the system will refuse to
run any software that is not released under an open source license.

"Our DRM system is designed to manage and protect your digital rights,
not the rights of Hollywood executives jockeying to buy their fifth
luxury yacht," RMS explains. "The idea is simple: All software must
include the source code, which is compiled on the fly by the CPU. All
binary code will be automatically chucked into /dev/null."

In another interview, RMS adds wryly, "This is one platform Microsoft
will not be able to embrace and extinguish. If they try to force Windows
to run on this hardware by hacking the DRM restrictions, then they will
be in violation of the DMCA. Bwahahahaha!"

 

[Bernd Paysan]

In comp.sys.ibm.pc.hardware.chips David


Where does it say this in GPL v2 ?

In section 2:

" 2. You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:

a) You must cause the modified files to carry prominent notices
stating that you changed the files and the date of any change.

b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
^^^^^^^^^^
parties under the terms of this License."

So if the signature is part of the *functionality* of the program, i.e. a
program without that signature would not do the same thing, the signature
is part of the program, and therefore the means to create it, the "source
code" to generate the signature (that's the private key, and in case of a
non-standard signature process, also the signature program) is part of the
overall source code.

If there's a loophole, than in sloppy interpretation of what the source code
is. The source code *is* the stuff to create the program from. It doesn't
need to be C code.

As I said in another posting, the mere fact of having a signature in a
source or binary package does not mean you have to give out your private
key. As long as the signature has no effect on the functionality of the
program, it is not part of the source code. I sign my program packages, but
you can build them to the same effect when you ignore my signature. It
doesn't contribute to the program, so it's a mere aggregate. And that's
clear - then it doesn't need to be GPL'd. If the signature is essential for
the program to work, it's no longer a mere aggregate, it's part of the
program.

 

[FredK]

Thanks, however Fred's post already mentioned that drivers could
be using bytecode. The question is about EFI 'applications', since
Fred appeared to make a distinction between driver and application.
I was not aware that there was a distinction between the two.

There were mentions of OpenFirmware in this thread. My understanding
is that OpenFirmware, while defined by some (ISO?) standard, is not
open by the current standards of 'Free Software' proponents. My impression
is that EFI ends up being more open, which probably annoys some zealots
so much that they have to conveniently ignore the facts (I am not
talking about RMS here).

Repeated disclaimer: I am just an interested bystander when it comes
to EFI.

My exposure to EFI was in relation to making VMS boot on Itanium.

EFI applications themselves are IA64 or IA32 binaries, they are not
interpreted. The drivers being in bytecode I think is an attempt to make
them architecture independent (so you don't need multiple objects in
ROM for each architecture), and in the context of drivers - there is an
interpreter and a virtual machine environment.

My only exposure to OpenBoot was in the context of an investigation to
replace the Alpha SRM and AlphaBIOS. It was developed by SUN, but
the developer got himself spun off into his own company to create
OpenBoot - which is used to boot MacOS, and could even be used to
boot a PC using a BIOS "wrapper". It is completely in Forth. You can
find OpenBoot drivers in some PCI adapters (if they work on Apple) -
which are a binary coded Forth.

 

[Yousuf Khan]

IIRC, LinuxBIOS gets into protected mode ASAP, because it's easier to
code for. I don't know what that has to do with Greg's comment, though.

Quite simple really, why would it be necessary to emulate the video bios
when all one would need to do is make a call to the actual video bios? I
was trying to figure out why the Linux bios isn't simply making a call
to the other bioses on the system. Obviously, a video bios is Real-mode
code, so the Linux bios cannot possibly make a simple call to it.

Yousuf Khan

 

[Chris Barts]

I guess we will need a FreeBIOS eventually before DRM totally stops us
from even booting our PCs.

As a tangential issue, is the term BIOS (Basic Input-Output System)
apposite anymore? Do any modern OSes or applications use the abstraction
layer the BIOS (is supposed to) implement?

As I understand it, and I might be wrong, the BIOS is only active during
the POST and in handing off control to whatever bootloader is installed
on the bootable media (disk, flash drive, network) the PC uses. In the
DOS and CP/M days, applications would actually call into the BIOS to get
the hardware to do stuff (not the fastest applications, but the system
calls were always there).

 

[Greg Lindahl]

Why is Open Firmware not open? Just because the Free Software
Zealots redefined what open means? C'mon.

Please don't throw stones at the wrong people. "Free Software
Zealots" generally care a lot about the meaning of "Free", but usually
not "Open".

For example, Stallman's recent "Free BIOS" rant only uses "open" when
talking about what the "Open Source" people are saying. He is using
their definition; no redefinition involved.

It's fine to disagree with what people say. But it's not as fine to
not get straight who said what.

-- greg

 

[David]

Where does it say this in GPL v2 ?

This is a hole I expect closed in v3.

-- Robert

From section 3 of GPL v2:

"The source code for a work means the preferred form of the work for
making modifications to it. For an executable work, complete source code
means all the source code for all modules it contains, plus any associated
interface definition files, plus the scripts used to control compilation
and installation of the executable. However, as a special exception, the
source code distributed need not include anything that is normally
distributed (in either source or binary form) with the major components
(compiler, kernel, and so on) of the operating system on which the
executable runs, unless that component itself accompanies the executable."

I don't know whether DRM signing would count as "scripts used to control
compilation and installation of the executable", but it could well do.

 

[Robert Redelmeier]

From section 3 of GPL v2:
"The source code for a work means the preferred form of the
work for making modifications to it. For an executable work,
complete source code means all the source code for all modules
it contains, plus any associated interface definition files,
plus the scripts used to control compilation and installation of
the executable. However, as a special exception, the source code
distributed need not include anything that is normally distributed
(in either source or binary form) with the major components
(compiler, kernel, and so on) of the operating system on which
the executable runs, unless that component itself accompanies
the executable."

I don't know whether DRM signing would count as "scripts used
to control compilation and installation of the executable",
but it could well do.

I don't see any binary tools like compilers, checksum or signature
generators listed in sec 3, second sentence. "script" appears to
mean some sort of makefile. "interface def files" would appear
to be hw drivers. A sig.gen is neither of those, and even if it
were distributed, it might not contain the secret key that the
BIOS would need.

When you distribute GPG, you're not required to distribute keys.

Oddly, the last sentence excludes binaries that the second
sentence never included. What the second sentence could
[and perhaps should] have said is "plus any tool necessary
to modify and rebuild a binary runnable after modification."
Then let the last sentence exception operate.

Sony [neutral example] could distribute everything, but with
a single signature, valid only for a kernel complied exactly
per the makefile. Any mods would blow the sig.

The problem with this hole is it's locked in GPLv2, and
I doubt the Linux kernel can be shifted to v3 or later.
Hence we _really_ do need FreeBIOS or at least commercial
BIOSes without boot sigs.


-- Robert

 

[Andrew Reilly]

I don't see any binary tools like compilers, checksum or signature
generators listed in sec 3, second sentence.

I think that the first sentence "preferred form for .. making
modifications", and the third (special exception) probably covers it.
IANL etc. I.e., compilers would be included, because you need them in
order to make modifications, except they're excluded by sentence three,
because they're usually part of the target OS. I guess that if the target
OS is a BIOS which doesn't come with a compiler, then the OS
(program) distribution necessarily *does* include a compiler. Oh, look:
it does.

"script" appears to
mean some sort of makefile. "interface def files" would appear to be hw
drivers. A sig.gen is neither of those, and even if it were
distributed, it might not contain the secret key that the BIOS would
need.

Then it wouldn't be a sufficient form for making modifications, would it?

When you distribute GPG, you're not required to distribute keys.

No, but they're not necessary for making modifications to the GPG program.

Oddly, the last sentence excludes binaries that the second sentence
never included. What the second sentence could [and perhaps should]
have said is "plus any tool necessary to modify and rebuild a binary
runnable after modification." Then let the last sentence exception
operate.

I reckon the first sentence covers this.

Sony [neutral example] could distribute everything, but with a single
signature, valid only for a kernel complied exactly per the makefile.
Any mods would blow the sig.

Then that wouldn't be sufficient for making modifications.

The problem with this hole is it's locked in GPLv2, and I doubt the
Linux kernel can be shifted to v3 or later. Hence we _really_ do need
FreeBIOS or at least commercial BIOSes without boot sigs.

The individual authors are free to release subsequent versions of their
software under whatever license they like. It would take consent from all
contributors, which would be a serious management problem, but unless
something in GPLv3 was very controversial, I doubt that you'd have much
more than that practical difficulty: if the authors used GPLv2 in the
first place, they'd probably be even happier to use GPLv3. Besides which,
doesn't GPLv2 contain words along the lines of "or any subsequent version
of this license"?

What I don't understand about the whole DRM'd BIOS issue is how they
expect it to achieve anything at all? Would it be impossible, or illegal
in some sense, to get an interpreter signed? If you've got a
signed perl or python executable, then you can still do whatever you like.
If you've got a signed JVM or Bochs/Dynamo/FX!32 then you can run
anything at all. If the answer is "yes" (no interpreters), then where
does that put the VBA part of MS-Word etc, or some random postscript
printer engine, or any other Turing-complete extension language?

Cheers,