Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Operating Systems Software

More Power To The Firmware 226

An anonymous reader writes "In More Power To The Firmware Amit Singh talks about technical details of EFI, the next-gen BIOS replacement standard Intel, Microsoft and others are pushing. This is a very informative piece where he talks of issues with legacy BIOS, how it affects those who develop in the firmware environment and how EFI plans to solve these problems. EFI usage examples are included, including a programming example. He contrasts EFI with Open Firmware as well. IMO the second half of the article is even more interesting, where sample FORTH code is provided for displaying a window/mouse pointer GUI inside the Apple/Mac firmware! And of course, there's code for a new 'Towers of Hanoi' animation using the Mac firmware (remember Hanoimania?). Aspiring Mac Firmware Hackers could also check out the suggested projects ;-)"
This discussion has been archived. No new comments can be posted.

More Power To The Firmware

Comments Filter:
  • by Oddly_Drac ( 625066 ) on Thursday June 17, 2004 @11:36AM (#9452982)
    "but can you imagine any sort of Windows-dependent BIOS?"

    No. Luckily, the article didn't mention one.

  • by Anonymous Coward on Thursday June 17, 2004 @11:39AM (#9453013)
    i had an amd 486dx4/100 motherboard back in the mid 90s that had a full gui windowing system to configure the bios that relied on the mouse (tabs were used, too). i think it was 640x480 or something very similar.

  • by eddy ( 18759 ) on Thursday June 17, 2004 @11:40AM (#9453026) Homepage Journal

    Here's a link to an older KT entry; "Status And Discussion Of EFI (Extensible Firmware Interface) Support [kerneltraffic.org]"

    Explains some history, rationale and technical details.

  • by maxwell demon ( 590494 ) on Thursday June 17, 2004 @11:41AM (#9453033) Journal
    ...but can you imagine [...] a Windows-based BIOS of some type where the OS actually IS the BIOS?

    Well, given that there's LinuxBIOS [linuxbios.org] ...
  • by Anonymous Coward on Thursday June 17, 2004 @11:47AM (#9453078)
    Ans what about Amiga OS. THe OS was the BIOS. at least for A1200 and before

    just wait until the 1st BIOS virus
  • pocket pc (Score:2, Informative)

    by minus_273 ( 174041 ) <aaaaaNO@SPAMSPAM.yahoo.com> on Thursday June 17, 2004 @11:49AM (#9453111) Journal
    heh reminds me of a pocket pc where the Windows OS is in the ROM
  • by x0n ( 120596 ) on Thursday June 17, 2004 @11:51AM (#9453126) Homepage Journal
    The OS is the BIOS? Either you're trolling [but given your subject disclaimer, perhaps not], or you misunderstand the concept of abstraction layers, and their ordering. The BIOS cannot be dependent on Windows, it sits beneath the OS. The OS is dependent on it. Drivers, in effect, are mini-BIOSs in themselves. They abstract out the different hardware devices to a standard windows API. The BIOS that comes with your machine abstracts out the out-of-the-box components of your motherboard among other things. Sometimes windows drivers talk to the bios, but mostly they skip it altogether.

    - Oisin
  • by drinkypoo ( 153816 ) <drink@hyperlogos.org> on Thursday June 17, 2004 @12:13PM (#9453318) Homepage Journal
    The complexity has to be somewhere. If the BIOS gets simpler the devices have to be more complicated to take up the slack. You can't rely on the OS handling the hardware until it boots, after all, so you have to get there somehow. The BIOS doesn't need to talk to the sound card or anything like that, because autoconfiguration of the basic parameters of devices are handled by plug and play, which is an integral part of the PCI specification (though perhaps not by that name, I've never actually read the specification.) Adapter cards and onboard peripherals get IRQs, IOports, and memory ranges from the PCI system controlled by the BIOS. But, what do you do after that? Currently in the PC world the BIOS jumps (JMPs, even) into the adapter BIOS and executes some of its code from ROM, optionally caching that ROM into "shadow" memory and executing it from there for speed, but once the OS loads the driver takes over and the BIOS isn't really used. AFAIK Linux only communicates with the BIOS at boot time, while loading assorted drivers, to find out what kind of parameters they should use, but many drivers go straight to the hardware and don't even bother with it.

    Anyone know how often Windows currently jumps into the BIOS today? However often it is, it will become moreso when DRM becomes a BIOS function...

  • PC's like the xbox (Score:3, Informative)

    by Stevyn ( 691306 ) on Thursday June 17, 2004 @12:21PM (#9453390)
    I hope this doesn't mean that PCs will be sold like Xboxes. I don't want to have to intall a mod chip on my laptop to run linux. I like the idea of the BIOS having more function and power, but I want it to do more than just prevent code from being executed. This should definately be an open standard otherwise Microsoft or Intel will have too much control. It's one thing to boot into windows and have that muck up your computer, but it's different when microsoft code is running on a linux box.

    Since microsoft doesn't seem to like to innovate anymore, I wonder why they are pushing for this. Linux has shown that you don't need security at the hardware level to prevent viruses from taking down your computer.

    So far I don't see many benefits the user will notice and enjoy. I'm not trying to spread DRM FUD because this article doesn't talk about it, I'm just asking why Microsoft cares so much to push this.
  • by linuxislandsucks ( 461335 ) on Thursday June 17, 2004 @12:31PM (#9453482) Homepage Journal
    You mean after ten years of proven success in both SUN AND APPLE SYSTEMS Intel finally gets PCI religon?

    That is right folsk intle is finally enacting the last part of the PCI psec.. should we jump and cheer for it after ten years of foot dragging?
  • by Gothmolly ( 148874 ) on Thursday June 17, 2004 @12:51PM (#9453657)
    CALL -151
  • Rom Based OS != BIOS (Score:4, Informative)

    by nurb432 ( 527695 ) on Thursday June 17, 2004 @12:56PM (#9453712) Homepage Journal
    While the OS may have been in ROM, Like the Atari ST's, that doesnt make it the actual BIOS.

    By its very definition, the BIOS is a much lower level block of code. the true hardware abstraction layer, that the OS rides on top of..

    Sure its also in a ROM of some sort, perhaps even the same chips.. but that still doesnt really make a ROM based OS a 'BIOS'..
  • Re:pocket pc (Score:2, Informative)

    by minus_273 ( 174041 ) <aaaaaNO@SPAMSPAM.yahoo.com> on Thursday June 17, 2004 @01:05PM (#9453816) Journal
    "Sleek, expandable, and wireless-enabled, the Compaq iPAQ 3835 Pocket PC offers a powerful mobile computing tool that fits in the palm of your hand. It comes with 64 MB RAM and 32 MB ROM, a fast 206 MHz Intel StrongArm processor, and a bright LCD screen that displays 65,000 colors."
    no it is defiently in the 32mb of ROM. When you changed your OS you probably overwrote windows and put linux (im assuming thats what it is) on it.
  • by Alsee ( 515537 ) on Thursday June 17, 2004 @01:15PM (#9453935) Homepage
    Developers (that means you) will have to be able to sign their own software, or the system would be pointless. This would be an extra command in the makefile, no biggie.

    You don't understand Trusted Computing. It's not about signing software. There's no need to sign at all. What happens is if you change the software at all - even a single instruction - that that software no longer works with and existing data and can no longer communicate with other programs on the internet.

    The Trust chip generates a hash of the software. The hash is linked to an encryption key. If you change the software you lose the hash and can no longer get the the decryption key at all. Nothing works anymore. Very biggie.

    -
  • by Mr. Neutron ( 3115 ) on Thursday June 17, 2004 @01:29PM (#9454092) Homepage Journal
    Just because DRM is there doesn't mean software will be DRM-protected. And just because software vendors aren't DRMing their products doesn't mean TPTB won't impose DRM on all electronic components.

    It's like Macrovision. About 90% of commercial VHS tapes are not Macrovisioned. But 100% of VCRs are Macrovision-compliant by law. Sure, you can purchase deMacrovision boxes for legal use, but most people aren't going to go through the trouble. The same thing will happen with computer hardware. All computer components manufactured for sale in the US will be "trusted." The enterprising and resourceful geek will get all of his components direct from Asia and either run Linux or a dusty old copy of XP/Longhorn, but for all practical purposes, DRM will be everywhere. It may not be taken advantage of by everyone, but it will be everywhere.
  • by DeathPenguin ( 449875 ) * on Thursday June 17, 2004 @01:40PM (#9454229)
    >>just wait until the 1st BIOS virus

    There have already been several, that was one problem with using DOS.
  • by Alsee ( 515537 ) on Thursday June 17, 2004 @03:41PM (#9455831) Homepage
    Anyway, there will have to be a mechinism to upload your own hashes or the system will be useless for anything but tivos and xboxes.

    That's what I'm saying - there is NO way to "upload hashes". And there is no need to attach any signature to the EXE at all.

    When you run the program the Trust chip generates a hash value for the program. There is no hash attached to the program. There is no signature attached to the program. The chip generates a hash of the software on the fly, and uses that to generate or access an encryption key. Any data that program wants to read or send goes through that encryption key.

    YOU HAVE NO CONTROL over the hash.
    YOU HAVE NO CONTROL over the encryption key.

    The system does not verify that the software is has a "good" signature. It allows absolutely any software to run. The only thing it does is see if the software has changed. If the software is changed then it will still run, but it won't work. It won't be able to read any existing data and it won't be able to talk to other programs it's supposed to talk to.

    There is a whole big elaborate system built on top of this. But fundamentally it is designed to deny you control over your own computer. Trusted computing is about the owner not being trusted, instead other people can Trust that your computer will enforce rules against you, and that you will be powerless to tell your computer to do something different.

    When you run Trusted DRM music software, that software has a certain hash. That hash produces a specific encryption key. All of your DRM music files are encrypted with that key. With that key the chip then decrypts the DRM files for the player and it can play your music.

    However you are forbidden to ever know that encryption key. If you change the DRM music player in any way - perhaps some sort of change that would break the DRM protection - then the chip generates generates a different for the changes software. With a different hash you can no longer get the decryption key. So even if you broke the player's DRM system, the player can no longer read the music files.

    The RIAA can then Trust that your computer will not allow you to do anything except exactly what the RIAA decide to allow you to do. Exactly no more and no less than what the program they gave you will let you do or force you to do.

    -
  • Nope (Score:2, Informative)

    by Anonymous Coward on Thursday June 17, 2004 @05:00PM (#9456766)
    The Amiga is kind-of unique. The OS _is_ the BIOS, as well as everything else.

    Turn the Amiga on, the 680x0 reset vector runs. Through board logic, the Kickstart ROM is mapped to 0x00000000 as well as its usual location, and the lowest points of the ROM point out the jump address for the reset vector. The 68000 goes there, it's the INIT code of exec.library. Exec performs a self test on the board logic, the memory and the custom chips. It then searches for expansion cards (creates expansion.library), attached disk drives (trackdisk.device) and HDs (scsi.device (regardless of whether you have an IDE or SCSI hardware interface)), PCMCIA card disks (carddisk.device), etc.

    The graphics.library writes direct to Amiga hardware. The audio.device, in ROM, writes direct to Amiga hardware. potgo.resource, cia[a|b].resource, misc.resource, disk.resource, etc, are all arbitration mechanisms for custom chip registers. Sure, dos.library can load filesystems from disk once it's initialised by a HD or disk standard bootblock, but the basic 6 Amiga filesystems are in ROM. intuition.library and its high level BOOPSI stuff like loadable gadgets, images, datatypes are built on top of layers.library, which is built on top of hardware-hitting graphics.library.

    So there is tight integration between the hardware and the OS. There's no low-level code offering a hardware independent API to AmigaOS... that's AmigaOS itself. You can't put another OS there without adding in half of what AmigaOS did, in order to maintain the Amiga hardware. There's a lot of stuff that came after the Amiga designs (such as MMUs), and there's no official OS interface to it. They're not initialised by the OS. Random application programs fought over them with no OS supervision.
  • Re:Mac Firmware (Score:3, Informative)

    by Graff ( 532189 ) on Thursday June 17, 2004 @06:37PM (#9457659)
    I suppose it's possible since you can update the firmware, but does Apple keep information about how to program the firmware proprietary, or is it open for people to tinker with?

    Apple provides plenty of information and links to information on the Apple Open Firmware Home Page. [apple.com] They even have a good sense of humor. The machine that the site is running on is located at "bananajr6000.apple.com"! [rwth-aachen.de]

He has not acquired a fortune; the fortune has acquired him. -- Bion

Working...