Stallman rants about FreeBIOS

[YKhan]

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

» Stallman's new campaign to free the BIOS | Open Source | ZDNet.com
http://blogs.zdnet.com/open-source/index.php?p=179

Yousuf Khan

 

[Robert Myers]

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

» Stallman's new campaign to free the BIOS | Open Source | ZDNet.com
http://blogs.zdnet.com/open-source/index.php?p=179

It could all be in silicon. Probably will be. Not just the BIOS.
Everything that makes money.

RM

 

[Greg Lindahl]

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

Old news; the Xbox has this feature. Fortunately, the average PC maker
doesn't have a business reason to do it, yet.

-- greg

 

[Gnu_Raiz]

It could all be in silicon. Probably will be. Not just the BIOS.
Everything that makes money.

RM

If it can be done in silicon, would that bring boot times down? I thought
the whole reason for Stallman's rant is becasue of DRM being put into
bioses. You know that whole trusted computing crap! I think basic bios
stuff can be put into silicon, but what about Billy G's idea of bios, and
what he wants to accomplish on a hardware level? Didn't someone say that
hardware would be free, and software would be the only thing that costs
money?

I also thought that Intel was against a free bios anyway, with their new
agenda on what they call the EFI bios with driver support.
http://64.233.187.104/search?q=cach...uting/dt05041.pdf+bios+++intel+++future&hl=en

I guess its called the Extensible Firmware Interface, is driver based, so
people can do binary linking. Of course I will let all you folks tell me
if its good or bad, as I have no clear idea what Intel is trying to do.
The good thing about Stallman is at least you know where he stands on an
issue.

Gnu_Raiz

 

[Robert Redelmeier]

If it can be done in silicon, would that bring boot times down?

If hardware is more uniform/standardized, boot time can
be reduced. See Xbox or DVD players as an example.

I thought the whole reason for Stallman's rant is becasue
of DRM being put into bioses. You know that whole trusted
computing crap!

Yup. I think that's precisely RMS' worry. And I agree.

I think basic bios stuff can be put into silicon, but
what about Billy G's idea of bios, and what he wants to
accomplish on a hardware level?

MS has done this for time time with their hardware standards.
So far, they've been careful to keep those standards reasonably
open and Linux-compatible. If they ever try to shut'em down,
the anti-trust liability would be _huge_. Please remember
that even though the punishment has been defanged, MS is
still an adjudged monopoly. On notice.

In short, I expect DRM (if it flies) in OS software.

Didn't someone say that hardware would be free, and software
would be the only thing that costs money?

I've heard it before, and it's coming true, at least
in the MS/commercial software world. I can buy a bare-bones
box with Linux for $200. Adding MS Windows costs +$100.

I also thought that Intel was against a free bios anyway,
with their new agenda on what they call the EFI bios
with driver support.

I'm not entirely sure exactly where Intel stands, but they
will have trouble supporting a totally open BIOS because AFAIK
the CPU microcode is IPLed by the BIOS. A legacy for fixing
the PentiumFDIV bug.

The rest of the BIOS has more to do with the chipset
and other hardware (programming) than the CPU.

But that microcode IPL probably sticks in RMS' tender craw just
like the nVidia Linux driver which AFAIK mostly does a GPU IPL.
But that whole issue of firmware is a gaping hole in the GPL.

-- Robert

 

[Greg Lindahl]

If it can be done in silicon, would that bring boot times down?

If hardware is more uniform/standardized, boot time can
be reduced. See Xbox or DVD players as an example.

Boot time can be reduced without changing hardware -- see LinuxBIOS
for an example. LinuxBIOS can actually boot a variety of OSes, not
just Linux. However, the information needed to fully initialize a lot
of PC hardware isn't availble -- video cards can be done efficiently
by emulating their BIOSes, but things like the memory controller and
stuff built into southbridges can't be done that way.

-- greg

 

[demonmaster]

<none>

If it can be done in silicon, would that bring boot times down? I thought
the whole reason for Stallman's rant is becasue of DRM being put into
bioses. You know that whole trusted computing crap! I think basic bios
stuff can be put into silicon, but what about Billy G's idea of bios, and
what he wants to accomplish on a hardware level? Didn't someone say that
hardware would be free, and software would be the only thing that costs
money?

I also thought that Intel was against a free bios anyway, with their new
agenda on what they call the EFI bios with driver support.
http://64.233.187.104/search?q=cach...uting/dt05041.pdf+bios+++intel+++future&hl=en

I guess its called the Extensible Firmware Interface, is driver based, so
people can do binary linking. Of course I will let all you folks tell me
if its good or bad, as I have no clear idea what Intel is trying to do.
The good thing about Stallman is at least you know where he stands on an
issue.

doesn't matter who's against it -- can't be stopped not even at the
hardware level.

 

[Robert Myers]

If it can be done in silicon, would that bring boot times down? I thought
the whole reason for Stallman's rant is becasue of DRM being put into
bioses. You know that whole trusted computing crap! I think basic bios
stuff can be put into silicon, but what about Billy G's idea of bios, and
what he wants to accomplish on a hardware level? Didn't someone say that
hardware would be free, and software would be the only thing that costs
money?

I also thought that Intel was against a free bios anyway, with their new
agenda on what they call the EFI bios with driver support.
http://64.233.187.104/search?q=cach...uting/dt05041.pdf+bios+++intel+++future&hl=en

I guess its called the Extensible Firmware Interface, is driver based, so
people can do binary linking. Of course I will let all you folks tell me
if its good or bad, as I have no clear idea what Intel is trying to do.
The good thing about Stallman is at least you know where he stands on an
issue.

Intel wanted to provide a standard way to boot IA-64. A standard PC
boot couldn't be used because itanium could not start (or execute,
even) in IA-32 real mode. They had to do something, and EFI is what
they did.

I haven't had much of a chance to play with EFI, but what I've seen
(you can get in there between the firmware and the OS, if you have to,
and EFI applications run on a virtual machine) seems pretty
attractive.

I have tremendous respect for RMS, but I think he's probably fighting
a losing battle. I'm not sure I fully understand why he's so
exercised. The future is that Windows will have some kind of foolish
DRM scheme that people will quickly crack. Applications could migrate
onto silicon as one copy protection strategy.

Someone will have to explain to me how Intel would or could make life
impossible or even difficult for Linux. Even Intel wouldn't want to
step on that toe.

Sure, the whole OS could migrate into EFI. It's already happened.
With no disk installed, my itanium box boots into linux. Not an
especially powerful linux, but that's a detail. You can boot into
linux, fiddle things if you like, and then boot a disk-based OS.

I'd think Bill Gates should be more worried than Richard Stallman.
There's no reason at all why you even need a hard disk on a box that
will do what most users want to do with a PC, and no particular reason
why you need Windows, either.

RM

 

[FredK]

snip

Intel wanted to provide a standard way to boot IA-64. A standard PC
boot couldn't be used because itanium could not start (or execute,
even) in IA-32 real mode. They had to do something, and EFI is what
they did.

I haven't had much of a chance to play with EFI, but what I've seen
(you can get in there between the firmware and the OS, if you have to,
and EFI applications run on a virtual machine) seems pretty
attractive.

EFI is a small, very simple OS. It's not really a virtual machine
environment.
It provides various IO related interfaces to allow access to hardware in an
abstracted way. From its user interface side, it has a menu interface, and
there is a shell from which you can "run" EFI applications from a FAT
formatted disk partition. Applications can be as varied as a FTP program
(which exists), platform diagnostics, or boot loaders - a special type app
that loads some OS specific code, declares the end of boot services, and
never returns.

EFI also runs the platform and device initialization using ACPI - which
allows
the system vendor to embed a interpreted byte code that describes and
initializes non-standard things like core chip sets.

Sure, the whole OS could migrate into EFI. It's already happened.
With no disk installed, my itanium box boots into linux. Not an
especially powerful linux, but that's a detail. You can boot into
linux, fiddle things if you like, and then boot a disk-based OS.

Well... this isn't true as far as I know. Boot loaders are a special form
of EFI application used to load some OS specific code, transfer control
and never return. The Linux method is a EFI application called "elilo"
which is normally resident on a hard drive in the FAT formatted EFI
partition. "elilo" pulls in an image that contains a Linux kernel and
a memory disk. Or you could do a network boot using PXE (bootp on
steroids). But I don't know of anyone who is blasting "elilo" or the boot
kernel into flash ROM.

Intel could have used OpenBoot (Sun, Mac) as an alternative to rolling
their own. The advantage with EFI is that you can push things not
needed for booting onto mass storage instead of ever increasing ROM
sizes... things like diagnostics for example.

 

[Greg Lindahl]

EFI is a small, very simple OS.

This must involve a new definition of "small" and "very simple"!

Intel could have used OpenBoot (Sun, Mac) as an alternative to rolling
their own. The advantage with EFI is that you can push things not
needed for booting onto mass storage instead of ever increasing ROM
sizes... things like diagnostics for example.

Indeed, that's what LinuxBIOS does, too.

LinuxBIOS supports every device Linux does -- does EFI somehow use
drivers from some other OS, or are they unique?

-- greg

 

[Robert Myers]

snip


EFI is a small, very simple OS. It's not really a virtual machine
environment.

I'm sorry. I didn't mean to imply that the environment itself, which
as far as I know is linux, runs on a virtual machine. You'd have to
run a byte code interpreter in that environment to execute the kind of
EFI code that is interpreted at boot, but the intent, I believe, is
that device drivers be independent of CPU.

Well... this isn't true as far as I know. Boot loaders are a special form
of EFI application used to load some OS specific code, transfer control
and never return. The Linux method is a EFI application called "elilo"
which is normally resident on a hard drive in the FAT formatted EFI
partition. "elilo" pulls in an image that contains a Linux kernel and
a memory disk. Or you could do a network boot using PXE (bootp on
steroids). But I don't know of anyone who is blasting "elilo" or the boot
kernel into flash ROM.

I'm not sure what I said that you're disagreeing with. As far as I
know, the prompt I get at boot is linux. It isn't fully functional,
but, as I said, that's a detail. It's as much an OS as the ] prompt
was on an Apple ][--more actually, because it is a disk operating
system.

Sure, the widget that loads Linux (or whatever) loads from disk and
runs as a garden-variety program, but there is no reason at all why
full functionality couldn't be in firmware and, I believe, such a
thing will come to pass for thin, diskless clients. Such a client
will pull its operating system in via PXE? Maybe. No reason why it
has to, though.

RM

 

[FredK]

This must involve a new definition of "small" and "very simple"!

Well. Think about it. It is a ROM resident OS. It provides IO services,
memory management services, and a command line interface. It allows
you to write disk resident applications that it will simply run. It isn't
"that" big, or "that" complicated.

Now, EFI is just one *part* of the firmware - there is also ACPI, PAL
and SAL.

Indeed, that's what LinuxBIOS does, too.

LinuxBIOS supports every device Linux does -- does EFI somehow use
drivers from some other OS, or are they unique?

Unique. They have a port/class like mechanism as I understand it, where
EFI abstracts the high level, and the devices themselves provide the low
level "port" code. PCI object format was extended so not only does it have
BIOS (ia32), and OpenSource (Forth), but also a new format for EFI.

 

[FredK]

I'm sorry. I didn't mean to imply that the environment itself, which
as far as I know is linux, runs on a virtual machine. You'd have to
run a byte code interpreter in that environment to execute the kind of
EFI code that is interpreted at boot, but the intent, I believe, is
that device drivers be independent of CPU.

Nope. EFI and EFI applications are architecture specific - IA32 or
IA64 right now. The ACPI layer uses an interpreter for the "code"
that knows how to enumerate the platform and devices, and also
how to access that platform specific hardware (like a core chipset).

I also believe that the object format in the PCI devices ROM may
be an interpreted byte stream - but I don't recall offhand.

I'm not sure what I said that you're disagreeing with. As far as I
know, the prompt I get at boot is linux.

An Itanium system will initialize to a boot menu. One selection is
"shell" -
this is not Linux. If you put a Linux distribution CD into the system, it
"should" auto-boot it into a simple Linux kernel. But Linux isn't in the
ROM AFAIK on any Itanium system.

Sure, the widget that loads Linux (or whatever) loads from disk and
runs as a garden-variety program, but there is no reason at all why
full functionality couldn't be in firmware and, I believe, such a
thing will come to pass for thin, diskless clients. Such a client
will pull its operating system in via PXE? Maybe. No reason why it
has to, though.

It is certainly possible to blast it into the ROM or Flash instead of
having it disk resident.

 

[Yousuf Khan]

Boot time can be reduced without changing hardware -- see LinuxBIOS
for an example. LinuxBIOS can actually boot a variety of OSes, not
just Linux. However, the information needed to fully initialize a lot
of PC hardware isn't availble -- video cards can be done efficiently
by emulating their BIOSes, but things like the memory controller and
stuff built into southbridges can't be done that way.

Does LinuxBIOS go into Protected Mode or does it stay in Real Mode like
regular BIOSes?

Yousuf Khan

 

[Yousuf Khan]

Intel could have used OpenBoot (Sun, Mac) as an alternative to rolling
their own. The advantage with EFI is that you can push things not
needed for booting onto mass storage instead of ever increasing ROM
sizes... things like diagnostics for example.

These days with big & cheap flash available for use as firmware, you
might as well put everything into ROM.

Yousuf Khan

 

[Wes Felter]

I'm not entirely sure exactly where Intel stands, but they
will have trouble supporting a totally open BIOS because AFAIK
the CPU microcode is IPLed by the BIOS. A legacy for fixing
the PentiumFDIV bug.

Intel will give you the microcode update for your processor and a Linux
driver to load it. If Linux can do it, LinuxBIOS can do it.

 

[Wes Felter]

Does LinuxBIOS go into Protected Mode or does it stay in Real Mode like
regular BIOSes?

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.

 

[Greg Lindahl]

This must involve a new definition of "small" and "very simple"!

Well. Think about it. It is a ROM resident OS. It provides IO services,
memory management services, and a command line interface. It allows
you to write disk resident applications that it will simply run. It isn't
"that" big, or "that" complicated.[/QUOTE]

Ah. I wonder if it's bigger or smaller than LinuxBIOS. It certainly is
funny (ok, let's just say expensive) that EFI requires unique device
drivers.

Don Becker, champion of the "3 card monte" boot, which is quite similar
to LinuxBIOS, likes to make fun of EFI as being bloated in comparison.

-- greg

 

[Ketil Malde]

Yup. I think that's precisely RMS' worry. And I agree.

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.

-kzm

¹ And of course, you only sign OS'es that require applications to be
signed, which in turn only work for DRM-protected compliant data.

 

[Robert Myers]

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.

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.

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. The
problem, then, is with what congress might do, not with what Intel is
doing. Without someone to blame it on, Intel will never get there,
and Microsoft alone isn't powerful enough as someone to blame it on.

RM