Writing an End to the Bio of BIOS?
An anonymous reader writes "Intel and Microsoft are gearing up to move toward the first major overhaul of the innermost workings of the personal computer. The companies will begin promoting a technology specification called EFI (Extensible Firmware Interface) as a new system for starting up a PC's hardware before its operating system begins loading."
...it HAS to be bad, and an attempt to kill Linux.
That pretty much sums up the rest of the posts on this. Thanks, let's move on to the next story.
Why not just use Open Firmware?
Constitutionally Correct
So what happens when Intel and Microsoft decide they don't want anymore competition?
I have several IA-64 systems at work. IA-64 requires EFI (part of the intel spec). It's a major pain in the ass.. you have to have a dos fat formated filesystem to store bootloaders, and other utilities as a primary partition.. besides the fact that they changed the normal dos partition format for EFI. I wish they would have just ported OpenBoot.
I wonder if this new BIOS replacement will be designed based on the assumption that everybody is running the most current version of Windows.
When I see Microsoft and Intel working together I think of the platform lock-in of WinTel. This makes me wonder if they plan to have secret hooks offering advantages to their products. It will of course only be a matter of time for the likes of AMD and Linux to get up to speed, but sometimes a little time is all it takes to improve a market advantage through unfair practices.
"Anything is possible with enough programmers, time and pizza." (Substitute caffeine for time as needed.)
Of course that woukld include obligatory, non-overridable DRM chip driver?
Big Brother Has You!
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
One thing I've always hated about the standard PC BIOS is that you need a keyboard, video and mouse (kvm) to configure the thing.
It'd be great if EFI initialised a serial console if detected that there was no KVM attached to the system. It'd be great for custom-made PC routers and servers on generic hardware running Linux or xBSD.
Particularly Microsoft themselves - if X-Box reaches a third iteration - I doubt this'll make X-Box 2. It may well allow them to put a stop to the old trick of soldering in a new bios chip that takes precedence over the onboard bios, thereby allowing the user to run all sorts of software, legal oses and programs and illegal pirate copies.
Not really surprising. Microsoft will need some support from the BIOS to implement their DRM 'features'. I wonder how much this will impact Linux and other free systems. After all, MS now have enough XBox experience to ensure that only their operating system can be run.
I have a bad feeling that one day we might have 'consumer-oriented' windows computers which will be cheaper and will only run Windows...
It's been on the cards for some years. Anything has to be better than a chunk of 16bit Real Mode code providing a whole bunch of functions that no one uses any more.
What I'd like to see is a more intelligent system. We still have to load the boot manager as a 512 byte chunk from sector 0 of the "first" hard drive for crying out loud! If Intel get this right, we should have intelligence right at the start. Something like GRUB or XOSL running right from ROM would be great. The ability to control hardware properly at boot..
OpenFirmware would be better but it looks like Intel won't be going down that route. We can only hope for the best..
OpenFirmware is older than the hills, well tested, loved by all, and used on just about every machine EXCEPT Intel. Is anyone getting a sense of NIH syndrome?
Javascript + Nintendo DSi = DSiCade
I remember when we had to flash our BIOS off a 5 1/4 inch magnetic storage media and if there was a brown out like there so often were back before we had nuclear fission, you'd have to replace your EPROM! You kids have it so good these days.
peace,
-Grokent
The excuse "WEll, current BIOS systems is just patch written upon patch written upon patch. ITs a mess."
But it works. Is an EFI system going to be markedly faster? When you tell me you are loading device drivers at the BIOS level, that tells me "No"- you are creeping the OS lower.
So whats the deal?
from Intel's EFI web site: Together, these provide a standard environment for booting an operating system and running pre-boot applications.
AHhhh! Running PRE-BOOT operations! This sounds like a lame way to shoe-horn in DRM or something similar onto my machine before it loads up.
Maybe I'm acting paranoid, but the slowest thing on my windows computer is WINDOWS, not the bios- that runs pretty fast.
In the future, I would want to not be isolated from my friends in the Space Station.
There's been lots of worry about this sort of thing, given MS busines practices in the past.
Freedom is a hard concept for some folks to deal with
I hope that this turns into a financial disaster for them.
"It is a greater offense to steal men's labor, than their clothes"
No mention at all in the article of what has to be one of the biggest reasons for the push to change the boot process: Digital Restrictions Management/Trusted Computing/Palladium/Next Generation Secure Computing Base. (Notice how the name gets changed every time it becomes obvious what it really is.)
I noticed that the first PC to use EFI was a Gateway "Media Center" desktop. For those who do not know, Media Center is Microsoft's first attempt at highly integration of DRM (Digital Rights Management) into the core functionality of the OS. Knowing the agenda for Palladiam and so called "Trusted Computing" (Who do you trust today?) I would really think twice before letting the likes of Microsoft and Intel (remember the P4 CPU ID?) rewrite my PC at the BIOS level.
The "competition" between Pheonix BIOS and EFI could be the beginning of the split between closed platform "Trusted" PC's and open platform PC's. I would not be surprised if EFI has provisions (at some future point) to require the OS is signed. That rules out Linux, BSD, etc.
Naturally they are doing all this for our best interests.
"Anything is possible with enough programmers, time and pizza." (Substitute caffeine for time as needed.)
The original PC BIOS has incredibly remained basically unchanged since the days of the IBM PC, more than twenty years ago. We have all that legacy stuff in our PC's firmware that harks back to the days of MS-DOS and its limitations are being stretched to the breaking point by hacks and kluges (e.g. the disk size limits imposed by the real-mode BIOS calls). It would be nice to see it all go away for good.
On the other hand, it's Microsoft and Intel working together on this. This could very well be the next step towards the groundwork for Palladium, and more ugly DRM embedded into the lowest levels of PC hardware, that may well prevent anyone from running any operating system on commodity PC hardware besides that of Microsoft, among other baneful things. I'm not willing to bet that this new specification doesn't lay this type of groundwork in any way.
Qu'on me donne six lignes écrites de la main du plus honnête homme, j'y trouverai de quoi le faire pendre.
What do you mean when? I thought that decision was made back in 1994!
46. The Hobo smiles, his eyes glaze over, and he burps. "Beware the man who has lived longer than the Wasteland."
The download page requires a fake name and email, but you can skip that and get the latest version (1.10-001) here. (Total karma whore link: EFI homepage)
The license isn't actually too bad - it just says that if you provide them feedback, then you also grant them the right to implement your idea.
HIV Crosses Species Barrier... into Muppets
Imagine the horror of having to patch a system by swapping out chips. I think I recall some old time viruses that basically screwed up the bios royally, and which were not easily cleanable, to one degree or another.
Remember, this design is supposed to be a feature, not a flaw.
"It is a greater offense to steal men's labor, than their clothes"
Seems it's what's happening now. http://www.x86-64.org/
Take ACPI, for example. If you take out the P of ACPI, and stick to the configuration features, you end up with something very similar to (some parts of) OF. A device name tree? OF has it. An intermediate language for device initialization? OF has it.
OF has only one difference to ACPI: OF works. Devices are made with valid machine-language drivers, so that the OS doesn't have to patch it upon boot, etc, etc, etc. Don't take me wrong, I really believed that ACPI would be great, but when people started implementing it, we saw what mess it became. It was one of the reasons I moved away of the x86 platform. It is just a bunch of hacks.
So why Intel created ACPI? Because while ACPI is also "open", Intel can control it. And Intel knows that while it keeps the power of defining standards, it will be the leading chip manufacturer: it helps to keep it top of mind in terms of consumer ICs.
For those who don't know what OF is, take a look at this.
Heck, older SGI Octanes are going for peanuts (comapared to thier original price) on ebay, and they are mostly upgradeable to current spec. And Apple is over there just drooling for my cash.
There really shouldn't be that much going on in BIOS, that's what the whole B part means, ya know.Free Mac Mini Yeah, it's
I think Windows and Linux should form a joint platform. Windows OS with Linux firmware, called Windex!
http://github.com/gbook/nidb
I agree. I see the same thing with Apple. Every time I buy a Macintosh, I have the hardest time getting W2K to run on them. Damn lock in.
Wasn't Postscript good enough for them?
No wonder it's not hit mainstream.
This sounds like what Apple/IBM/Motorola/Sun started doing a long time ago with Open Firmware:
. sun.com/1275/e s/tn/tn1061.htm l
http://www.openfirmware.org/
http://playground
http://developer.apple.com/technot
http://bananajr6000.apple.com/
However, I'm wondering if this is how they will integrate digital rights management that the MPAA and RIAA want soo badly forced on to consumers computers? This could be it. Everyone's computer must authenticate with the Master Server in Redmond. :-)
Beyond that, this just means we'll blue screen faster or on detection of a non-MS operating system.
Personally I find fault with the logic of it's old therefore it's broken.
SPAM solution made easy: 1 spammer, 5 cords of rope, 5 hourses, and fireworks. Be creative.
This stuff runs essentially the same as it did in the 80s. Sure, it uses more memory, bigger hard drives, etc, but its all just built from the same thing. Which leads into #2-
The solutions which were created to deal with things (such as the BIOS) were only intended, by their creators, to be temporary solutions until somebody designed something better. However, the IBM PC became a standard, and everything since then been built upon that foundation.
So, for the first time in decades, people are looking at the PC and trying to make it better. Why cant we have computers which boot up in seconds, rather than minutes? Why cant we have power saving which actually works? Those features, and many more, will only be possible with a redesign. The old way of doing things carries too much baggage.
Its sad, because I had always thought computer people always look for the best way to do things. Unfortunately, computer people are just like everyone else, and all too willing to accept the status quo.
Manipulate the moderator system! Mod someone as "overrated" today.
You can see the way it is going now, open source adopted by other (I'm USA) governments (this is good, IMO).
The same will be true of the BIOS chips & even MB chip sets - they (forgin governments) are sharp enough to know it's a bad idea to have your system locked down (or into) something some one else has controll over.
So we buy all our stuff from overseas now, for price reasons. Soon we will be buying from them for freedom reasons (this may NOT bode well for the price we may have to pay in the future).
The day may be coming when we have to smuggle BIOS chips and/or Main Boards into the US, just to try to keep some freedom.
This may not be quite as "tinfoil hat" as it sounds now. Remember no one is looking out for your freedom - that task is up to you.
NewToNix - I lent my sig to a really nice government man, but he never returned it.
Someone above has posted a link from Kernel Traffic which explains quite nicely the fact that Linux already has early support for EFI as part of the IA-64 port (which has been backported to IA-32) and has a nice lenghty explanation from Intel about why they made certain design decisions that they did.
It all ends with a statement by an Intel person that none of what they're pushing as a standard is patented so that it can be as openly and widely adopted as possible. I'm pretty sure that no vendor lock-in will happen here.
If it's for-profit but free, you're not the customer -- you're the product (e.g., the Slashdot Beta's "audience").
Have you ever thought that the BIOS industry is trying to head down the way the mobile phone industry is? I mean, for example (in the UK anyway) your mobile phone is probably the biggest big brother device you own. If you buy a pay-as-you-go phone or a contract phone you need to phone the vendor after your contract has ended (or never, on pay-as-you-go) to get a code that 'unlocks' your phone, allowing you to insert any sim card from a competitor they want. Imagine the potential contracts you could develop using a similar method for PC's? Buy one of these hire purchase pc's that get paid out over 3 years (many families and people on budgets do this, probably dont need to tell anyone here its not a bargain as in 3 years that machine will be pretty worthless to other peoples standards). Then, after the 3 years is up.. you can pay another $40/40 in 'admin' charge to be sent a usb flash key or other data storage medium that unlocks your machine enabling another type of o/s? You could massively decrease the cost of o/s and pc in a home market while locking home users into draconian contract schemes disallowing certain applications, or o/s's (covered by DRM of course), after which time when the pc is worthless you can have all the features you want.. most home users not knowing any different will probably settle for a return scheme where they pay up for another 2 years for the upgraded version of the machine and so it goes on and on and on. I mean, if you really think about it it really doesnt seem such a crazy idea. It worked with mobile phones and an implementation like this in the future doesnt actually look that far off now.
EFI would be a total nightmare.
Vendor-supplied drivers without source are going to be BUGGY.
They are going to be doubly buggy if they are run with a compiler that has a buggy back-end.
And that back-end is going to be buggy if it's for some random bytecode that isn't widely used except for some silly EFI thing and is tested exclusively with just a few versions of Windows and _maybe_ occasionally on Linux.
Face it: firmware bytecode is a total braindamage. The only thing that works is _source_code_ that can be fixed, and lacking that, we're better off with a well-defined ISA that people are used to and that has stable simple compilers.
In other words: x86 object code is a better choice than some random new bytecode. It's a "bytecode" too, after all. And it's one that is stable and runs fast on most hardware. But as long as it's some kind of binary (and byte code is binary, don't make any mistake about it), it's going to always be broken.
EFI is doing all the wrong things. Trying to fix BIOSes by being "more generic". It's going to be a total nightmare if you go down that path.
What will work is:
standard hardware interfaces. Instead of working on bytecode interpreters, make the f*cking hardware definition instead, and make it SANE and PUBLIC! So that we can write drivers that work, and that come with source so that we can fix them when somebody has buggy hardware.
DO NOT MAKE ANOTHER FRIGGING BYTECODE INTERPRETER!
Didn't Intel learn anything from past mistakes? ACPI was supposed to be "simple". Codswallop.
PCI works, because it had standard, and documented, hardware interfaces. The interfaces aren't well specified enough to write a PCI disk driver, of course, but they _are_ good enough to do discovery and a lot of things.
Intel _could_ make a "PCI disk controller interface definition", and it will work. The way USB does actually work, and UHCI was actually a fair standard, even if it left _way_ too much to software.
Source code. LinuxBIOS works today, and is a lot more flexible than EFI will _ever_ be.
Compatibility. Make hardware that works with old drivers and old BIOSes. This works, just like cmdrtaco works his love sausage into rob malda every evening. The fact that Intel forgot about that with ia-64 is not an excuse to make _more_ mistakes.
Don't screw this up. EFI is not going in the right direction.
No, not PlayStation. "Personal System /2", IBM's attempt in 1985-86 to rewrite the PC Industry Standard Architecture into their own proprietary version. They charged a measely 5% licensing fee (in a market where margins were already in that range).
I predict this will die because:
Oh, and Microsoft is drifting into irrelevance.
sigs, as if you care.
I've always thought that Sun's PROM setup was much better than anything on any Wintel box. Serial console is standard. Booting your OS only requires configuring which disk to use. Hardware test tools built in. What's wrong with that?
I don't know what Windows XP is like booting up but I have 2 pretty much identical machines one of which runs Win2k and one of which runs Mandrake 9.2
Quite often I turn them both on at the same time and I can always log into Gnome around 30-40 seconds faster than I can log into Win2K.
I use a mac, you insensitive clod!
However, it has been obvious enough for the past few years that Microsoft, Intel, Dell et al. are pushing to reformulate the PC to become a "home appliance." Many consumers look forward to this eventuality, as the appliance-computer will focus on ease-of-use. However, these consumers are being hoodwinked. What they don't understand is that the increasing ease-of-use will be bought at the cost of their freedom.
Technological development often follows this pattern. As technologies become mainstream, they are often constrained and stifled. Their possible uses are severely limited not only to suit the "lowest common denominator" of user, but also to reflect the interests of big business and the bureaucracy.
For more on this, see Ursula Franklin's work which is incredibly insightful.
First off - if you haven't already, read the EFI specs: http://www.intel.com/technology/efi/index.htm
This has a good overview of what efi is and entails, as well as the specifications for it.
There are some good things about it - hardware drivers are easier to develop for it, it allows booting off of non-standard devices, and in some ways very similar to openFirmware. There is also linux support for efi (at least on IA64)
However, it has some serious drawbacks:
The potential is there to implement DRM, and attempt to "lock out" non-signed binaries, etc...
It requires a 100 Mb efi (FAT) partition (so it appears useless for diskless servers)
It appears to me at least that there are some potential serious security flaws to the implementation
Overall, EFI doesn't add anything that LinuxBIOS doesn't (except that EFI has been "blessed" by Microsoft), and it appears to be intel's way of locking in the BIOS market.
An ounce of perception is worth a pound of obscure
Nothing to fear I think, Remember the bootloader for alpha processors that microsoft required to be flashed to boot NT? Basically it was nt bootloader instead of the alpha console. Well it was supposed to only boot windows, but with some engineering it booted milo, which booted linux. this mostly stemed from alpha having a console that set up hardware for booting unix style, someone also made a bootloader for linux for that firmware, I think it was called aboot or something like that for the console boot. Actually alpha had a much cooler way of handling hardware than a bios, it could actually set up and control hardware in intesting ways, so I am all for it if this is what they are going for.
Whats the big deal here? Everyone knows bios is obsolete. It doesn't start with the all powerful internet letters "e" or "i". It doesn't have an embedded web browser. It can't play downloadable games. It even sounds all 80's - logo, DOS, bios, ROM... Not sexy. So here's the marketing redesign:
* Start with a leter "e" or "i". "e" is more powerful because it evokes environmentalist images of birds singing, clean water, air, beaches. I is too industrial... Let's go with E
* No StudlyCaps - Too 90s
* Avoid anything that sounds like a computer part from the movie Tron. To 80s.
* Add features that journalists want: pre-os software load (we don't want the OPERATING SYSTEM RUNNING THE COMPUTER), DRM, Support for hard drive loaded modules, and OnStar w/GPS for convenient assistance for law enforcement.
-- $G
After all, Linux runs on just about EVERY platform out there. From wrist watches to mainframes.
So, if there is something about this solution that RESTRICTS Linux's access, then isn't that sufficient warning that there are problems in this "solution"?
Is it possible to get the benefits proposed by this solution WITHOUT those restrictions?
Most of us do. But each person has a different idea of what is the "best way" to do something. That's why we have KDE and GNOME and all the others. That's why we have all those editors.
You list shorter boot times and better power savings. It appears that these are important to you. It appears that Linux compatibility is less important to you than those.
To others, that is reversed. They view Linux compatibility as more imporant than shorter boot times and better power savings.
Does that make them "wrong"?
You're posting on a pro-Linux site, asking why a solution that restricts Linux isn't popular here. While on a Microsoft-centric site, the response would be different.
It's all ones and zeros. There is no "right" or "wrong". Only design decisions based upon someone's criteria.
"Why cant we have computers which boot up in seconds, rather than minutes?"
Maybe you're just useing the wrong operating system.. mine does boot up in seconds. And yes, if your entire well thought out argument is "but maybe it'll boot faster (insert sparkly eyes)!" I really don't need a redesign with DRM and driver preloading.. which sounds slower.
You're reading Slashdot. Of course you like Linux and pc hardware
Without mentioning my previous employer by name, I spent most of 2003 working extensively with EFI.
h tm
I really don't think it's the terror people are making it out to be, despite MS's involvement.
EFI is essentially taking the higher level driver stuff and pushing it down into the system firmware. I think this could have cool benefits for Linux (and any other operating system, or anybody coding an OS).
For example:
If EFI becomes widespread, in theory you may never have to worry about installing a hardware driver again (for Linux or any other OS). EFI has an interpreter for EBC (EFI byte code). EBC drivers can be stored in the firmware of a pci/pcix card. When the system boots EFI interprets the EBC driver on the card, and presto! the new hardware is working on whatever EFI platform you are running it on. And since EFI provides a standard way to interface the hardware, the OS could operate without the need for further device drivers.
By the way, if you want to know more about EFI, you can score the specs here:
http://www.intel.com/technology/efi/agree.
If you run ia64 (all 5 of us :) ) you already run EFI. For some of you out there who may not have actually seen EFI in action, I'd thought I provide some small examples of what it looks like.
EFI does a running check of the hardware that it understands, drivers for which were provided by the Motherboard maker.
Here's a snapshot of the EFI SCAN on my INTEL Tiger4 system.:
EFI version 1.10 [14.61] Build flags: EFI64 Running on Intel(R) Itanium(R) 2 processor EFI_DEBUG
EFI IA-64 SDV/FDK (BIOS CallBacks) [Wed Jan 1 23:33:30 2003] - INTEL
Cache Enabled. This image MainEntry is at address 000000007FA02000
Searching for EFI 1.1 SCSI driver....
Scsi(Pun0,Lun0) MAXTOR ATLASU320_18_SCAB120 (320 MBytes/sec)
Scsi(Pun1,Lun0) MAXTOR ATLASU320_73_SCAB120 (320 MBytes/sec)
Scsi(Pun2,Lun0) MAXTOR ATLASU320_73_SCAB120 (320 MBytes/sec)
Scsi(Pun6,Lun0) ESG-SHV
Invoking PxeDhcp4 protocol to obtain IP address.
At the end of this, I get a menu that I can manually select from (cursor up and down), or let it automatically try the options(which can be modified to suit the user's needs). Here's a snapsnot:
EFI Boot Manager ver 1.10 [14.61]
Please select a boot option
Network Boot/Pci(1|0|0)/Mac(0007E9D8147A)
Linux
Floppy/Pci(1F|1)/Ata(Primary,Slave)
CD/DVD ROM/Pci(1F|1)/Ata(Primary,Master)
EFI Shell [Built-in]
Boot option maintenance menu
Use ^ and v to change option(s). Use Enter to select an option
As you can see, EFI has detected the network card, a bootable linux partition, the floppy (LS240 in this case), and the cdrom drive. Anything you can detect, you can boot off from.
The EFI shell option brings you into a shell. Once in the shell, you can easily switch to another filesystem by executing a changefilesystem command, similar to msdos:
fs1:
The shell prompt (for filesystem 0, which is the first filesystem EFI finds, whether its on a floppy, a cdrom, a harddrive, usb key, whatever)
fs0:\>
The shell looks like a dos shell, but runs commands that the motherboard manufacturer includes, such as "edit" "ls" "cat" "cp" "mount" and others. These commands live in ROM.
EFI understands the FAT32 filesystem and can perform operations on files living there including editing. EFI can access any FAT32 on any device EFI has a built-in driver for, and any device that the user can obtain an EFI driver for.
Another nice feature is that you can create a partition on the disk that efi will use to hold more commands, or updated commands, or drivers for newer hardware. These extra commands when then be available to you at boot time.
To the user, EFI looks almost like an built-in mini OS that understands enough of the hardware to give you several boot options, as well as the ability to manipulate files on the devices it sees.
I've seen no evidence of DRM support, or OS lock-in, but that certainly doesn't rule out the possibility. The thing is, EFI is enough of a standard that the user might have the possibility of replacing the stock EFI with some other version to meet their personal needs. This would certainly put us ahead of where we are with current vendor lockin on motherboard bios.
The Internet has no garbage collection
IBM, Hitachi, Fujitsu and Siemens. IBM offers 32 bit systems based on EFI as well (I believe written by AMI).
I've been working with EFI based systems for three years now. Nicer than BIOS/MS-DOS for test weenies like me to develop code for.
Have a Happy New Year!
myke
Mimetics Inc. Twitter
If the OS isn't using BIOS, this is actually safe, with two caveats:
1) The OS shouldn't be making BIOS calls. Last thing you want is to be in the middle of a hard drive write operation when you yank the chip. (This risk is negligible for modern OSes)
2) Use a proper PLCC extractor for the chip. Shorting out contacts or breaking the socket with a screwdriver is bad. Pulling the chip properly is safe. You're just cutting/restoring power to the voltage, ground, and signal leads of the chip within milliseconds of each other -- the same way you are every time you power the machine up or down.
For the record, yes, YMMV, but yes, I've done this, and yes, it worked. (I was an I-Opener h4x0r; this was an PC masquerading as an embedded system that lacked a floppy, and for which later versions of the BIOS wouldn't boot from a hard drive. The "hot flash" was needed under those circumstances - boot a machine with a hard drive and a "good" BIOS, remove "good" chip while system powered up. Insert "bad" BIOS chip extracted from a nonbootable unit into empty socket of powered-up "good" machine. Reflash "bad" BIOS chip with data extracted from "good" BIOS chip. Power down. Insert "good" chip into your machine. Insert reflashed chip into formerly-nonbootable machine.)
I wouldn't recommend it as standard procedure, but if you don't have an EPROM/EEPROM burner, hot-swapping BIOS chips between live machines is a viable field expedient.
Those 'BIOS destroyer' viruses worked because of how Intel engineered a particular reference design, not due to a BIOS flaw.
... so they took the design with the flash reprogramming GPIO as-is.
The Intel reference design motherboard of the day used a software general purpose input/output (GPIO) pin to control if the flash was in read-ony or reprogramming mode. This was a departure from the normal designs of the time, which used a hardware jumper to protect the flash ROM.
At the time, everybody making boards in Taiwan did little more that copy the reference design
Somebody hacked/reverse-engineered/leaked the pin configuration from the Intel reference design. This lead to the virus. The fact the virus worked on so many systems is that the Intel chipset was very popular, hence the reference design got copied a lot.
Now it's much harder to pull this type of virus off. Different motherboard designers use different methods to protect against this. Intel's answer was to combine a hardware jumper with their own proprietary encryption system on their motherboards.
There are several ways EFI could discourage Linux use:
It's a subtle strategy. It's not going to be impossible to boot Linux, but it looks like it's about to become more difficult.
It will still be possible to build machines that run Linux, and there will be companies that do so and preload Linux. But they'll make up their own distribution, like the Thiz Linux you find at Wal-Mart. End user installation of Linux will decrease. Red Hat's air supply will be cut off.
Once you see the whole strategy, you realize just how clever Microsoft is being about this. It's not so blatant as to provoke screams from the industry, but it's enough to put a big dent in Linux installs.
RedHat & other distros already support EFI booting into IA64. The boot process isn't different from IA32 to IA64 (the spec is hardware-agnostic), and I know it's already been verified working on IA32 EFI systems.
XP has hibernation support (AFAIK most/all? versions of W2K don't) --- i.e. it can just dump the contents of the RAM to the disk and load it up again. The feature is reliable enough that usually instead of shutting down I just hibernate. Counting from the point that I press the power button, it takes only about 10-15 seconds to boot up.
Even if it's not directly an intentional attempt to "kill Linux" (why would the Intel engineers who designed it be interested in that!?), there can be no doubt that Microsoft is trying to do what they can to make sure that the next generation of pre-boot software for PCs will contain whatever is needed to make DRM work.
This will not stop you from running GNU/Linux or some other Free Software OS, but if a significant percentage of computer users ever get hooked on that DRM stuff, it will become hard to convince them to switch to a Free Software OS where they cannot legally access DRM'd content.
boots in a small fraction of the time
If by "boot" you mean "starts the GUI", then yes.
However you're completely ignoring the fact that even after giving you a UI, XP is still working its guts out trying to finish loading the other "less imperative" system drivers/services/what-have-you.
Yeah, to most "users" it "feels like" it's finished booting, but you know - some OSs have actually finished loading all services and system drivers by the time they load the UI, and the ONLY thing they're loading, are UI specific drivers/services/applications.
And they STILL beat the pants of Windows in a boot-race.
Visit CryptoGnome in his home.
I didn't read the article but I don't see anyone mentioning AMD in this other than that they are not involved in the design of this new BIOS. The question I have is why? Why wouldn't AMD want to be involved? I'm sure if 2 CPU manufacturers are involved it would help calm of the nerves of everyone on /. Maybe Intel and MS kicked AMD out of the discussion. It's hard to say. Maybe we should tell AMD to get involved?
this nation, under God, shall have a new birth of freedom. -- Lincoln, Gettysburg Address