Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Operating Systems Software Hardware Linux

Phoenix BIOSOS? 394

jhfry writes "In an interesting development by an unexpected source, Phoenix Technologies is releasing a Linux-based, virtualization-enabled, BIOS-based OS for computers. They implemented a full Linux distro right on the BIOS chips, and by using integrated virtualization technology, it 'allows PCs and laptops to hot-switch between the main operating system, such as Windows, and the HyperSpace environment.' So, essentially, they are 'trying to create a new market using the ideas of a fast-booting, safe platform that people can work in, but remain outside of Windows.'"
This discussion has been archived. No new comments can be posted.

Phoenix BIOSOS?

Comments Filter:
  • Hrm (Score:5, Insightful)

    by CSFFlame ( 761318 ) on Thursday May 14, 2009 @06:51PM (#27959463)
    The Geek in me says: "awesome" The Hacker in me says: "jackpot"
    • Re:Hrm (Score:5, Interesting)

      by umeboshi ( 196301 ) on Thursday May 14, 2009 @06:58PM (#27959535)

      The Paranoid Conspiracist in me says: "This is an essential step for the trusted computing platform, where a government or corporate owned rootkit could exist on your computer, with little to no ability to be replaced or removed by the owner of the machine."

      • Re: (Score:3, Informative)

        by Wingman 5 ( 551897 )
        There is so much FUD about Trusted computting. Go watch Security Now Ep. 99 [grc.com] It will change how you think about trusted computing. It will separate the truth from the FUD.
        • Re:Hrm (Score:5, Insightful)

          by Mr2001 ( 90979 ) on Thursday May 14, 2009 @07:54PM (#27960049) Homepage Journal

          He basically makes the argument that TPM is a dual-use technology: it can be used for good or evil. Problem is, the evil uses could easily be disabled without impairing the good uses... but that hasn't happened.

          "Remote attestation" is for DRM, plain and simple. It's evil. There is no reason I'd want my computer to produce a report of what software I'm running without giving me the ability to change that report before it's sent out. That feature is useless for me as a user; it's only useful to third parties that want to restrict the software I'm allowed to run (e.g. by refusing to send me a video stream unless they know I'm using their preferred player).

          If they removed remote attestation from the TPM spec, or simply put a switch on the side of the computer so the owner could forge attestations whenever he felt like it, it wouldn't be evil. So the question is, if Trusted Computing is such a boon for users, why does it still have features that only serve to undermine those very users?

          • Re:Hrm (Score:5, Insightful)

            by jmorris42 ( 1458 ) * <jmorris@[ ]u.org ['bea' in gap]> on Thursday May 14, 2009 @08:19PM (#27960281)

            > So the question is, if Trusted Computing is such a boon for users, why
            > does it still have features that only serve to undermine those very users?

            Or you might consider a slightly bigger world than your basement and uses for computers besides downloading porn and playing WoW. Remote attestation might not be something you care for, but if you were designing an ATM system you might feel differently about the ability to know, with a pretty high confidence, that the remote terminals are uncorrupted.

            You are stuck on the idea that it is YOUR computer and that will always be so, that the person in front of the display owns the machine. But that just isn't true in a great many scenarios. I'd really like a system that allowed me to know if one of the workstations around here had been compromised. All of our machines are 'mine' in the sense I'm the one responsible for them, the employees sitting in front of em just use em.

            Even remote attestation can be used for either good or evil. The key is to resist when big media tries to use it for evil. And it's evil because the machines aren't TimeWarner's yet they want to assert ownership over them just because they are displaying their precious IP.

            • Re:Hrm (Score:5, Insightful)

              by Mr2001 ( 90979 ) on Thursday May 14, 2009 @08:49PM (#27960567) Homepage Journal

              Remote attestation might not be something you care for, but if you were designing an ATM system you might feel differently about the ability to know, with a pretty high confidence, that the remote terminals are uncorrupted.

              Fair enough. But if I were designing an ATM (or a kiosk, or any other public-facing terminal where remote attestation might have a legitimate use), I could put whatever additional hardware in there I wanted. I'm already adding a keypad, card reader, touch screen, etc. so why not one more thing?

              Remote attestation isn't something that needs to be built into the average PC. On a typical user's desktop, remote attestation doesn't really have any legitimate uses, only evil ones.

              I'd really like a system that allowed me to know if one of the workstations around here had been compromised. All of our machines are 'mine' in the sense I'm the one responsible for them, the employees sitting in front of em just use em.

              If those workstations came with a switch on the side for forging attestations, and you didn't want users doing that, you could simply disable the switch. Just like you can already disable CD-ROM drives, USB ports, or whatever else users might use to compromise the workstations.

              • Re:Hrm (Score:4, Interesting)

                by Craig Ringer ( 302899 ) on Thursday May 14, 2009 @10:04PM (#27961105) Homepage Journal

                Remote attestation isn't something that needs to be built into the average PC. On a typical user's desktop, remote attestation doesn't really have any legitimate uses, only evil ones.

                As a system administrator, I disagree in the strongest possible terms. I'd love to be able to have the domain clients here restricted to an authorized software list. I could let users install things they needed or wanted instead of having to do everything for them, but I could restrict the list of available code to things I'd verified were safe and wouldn't cause system issues, security problems, etc. It'd also offer significant protection against resident malware. It'd be great.

                Even being able to detect when a machine had unauthorized software on it would be a huge plus.

                The parent poster's point is an excellent one - often the user of the computer isn't the owner, and/or isn't the person responsible for managing and maintaining it. In these cases remote attestation becomes highly attractive.

                • Re: (Score:3, Funny)

                  by Mr2001 ( 90979 )

                  As a system administrator, I disagree in the strongest possible terms [...] often the user of the computer isn't the owner, and/or isn't the person responsible for managing and maintaining it. In these cases remote attestation becomes highly attractive.

                  Hi, and thanks for reading the first two paragraphs of my comment!

                  Since you're a system administrator, I'd like to extend a special offer to you: click here [slashdot.org] to read the final paragraph of my comment, absolutely free! I think you'll find it specifically addresses your concerns.

            • You're both right, which is why the parent's point is valid. I administer a large number of workstations, and would love the capacity to know what's running on them, to recognize whether they're compromised, but on my home computer, I still don't want Big Media spying on me. Somebody owns every computer out there, and that somebody should have the right to determine what kind of data about the computer's operation and about what it is being used for is being shipped out, and to whom it's being shipped out

            • Re:Hrm (Score:4, Interesting)

              by Thaelon ( 250687 ) on Thursday May 14, 2009 @11:25PM (#27961635)

              I think you've got a skewed perspective.

              I'm assuming here that you're some sort of administrator or something. Based on that assumption I offer this perspective: Your job only exists to enable them to do theirs. You're a meta-worker, they're the workers. Certainly there is some allowance for pride in your work in that it's "your" network or "your" computers, but you're really only there to enable them. Without them, you wouldn't be necessary. As long as you keep that in mind, everyone benefits.

          • Re: (Score:3, Informative)

            by umeboshi ( 196301 )

            Thanks for point that out. :)

            I'm still listening to that darned episode, but they've only been babbling about ssl certificates and other items in their listeners mailbag.

            My point was that the os in bios was an essential component, as the tpm is also. I never tried to say that tpm == trusted computing, rather that it is just a component of it. Hardware virtualization is also an essential component (it's also dual use, and I run virtual machines very frequently). A builtin hypervisor (or rootkit, depending

          • Re: (Score:3, Insightful)

            by MrKaos ( 858439 )

            So the question is, if Trusted Computing is such a boon for users, why does it still have features that only serve to undermine those very users?

            Because it's about vendors trusting they have control of *your* machine, not about you *trusting* control of your machine.

    • Re:Hrm (Score:5, Interesting)

      by Wingman 5 ( 551897 ) on Thursday May 14, 2009 @07:12PM (#27959673)

      In the fourth case, the core security software grabs input and output from the network and disk to check the data for security threats. In that case, "you won't even really know you are using hyperspace," Hobbs says.

      Talk about the setup for the rootkit from hell.

      • by bit01 ( 644603 )

        Talk about the setup for the rootkit from hell.

        BIOS flash memory is simply mass storage that, just like the hard disk, retains its contents when switched off.

        They didn't talk about it in the article but I'd be surprised if there wasn't some way to recover if it gets corrupted, either deliberately (virus), or accidentally (buggy software). Maybe protected memory that does initial boot or provides a re-flashing mechanism.

        If there's no such hardware protected method for recovery then yes, root kit hell.

        ---

        D

  • SplashTop (Score:4, Interesting)

    by OrangeTide ( 124937 ) on Thursday May 14, 2009 @07:03PM (#27959579) Homepage Journal

    So is this fundamentally different from Asus putting SplashTop on some of their netbooks and motherboards?

    • Re: (Score:2, Informative)

      by DrPeper ( 249585 )

      Well the two are similar. It sounds like HyperSpace has some catching up to do with Splashtop...

      " and in June, the company plans a major update, which will add e-mail capabilities and instant messaging."

      Which Splashtop already has.

      Both are instant on (or at least more instant on than Window$ is currently, but M$ is working on that) OS's. With boot times in the under 5 seconds range.

      But HyperSpace is a bit ahead of the game with the inclusion of a Hypervisor. So SplashTop will need to scramble to include

    • Re:SplashTop (Score:5, Interesting)

      by jmorris42 ( 1458 ) * <jmorris@[ ]u.org ['bea' in gap]> on Thursday May 14, 2009 @07:17PM (#27959723)

      > So is this fundamentally different from Asus putting SplashTop on some of their netbooks and motherboards?

      Very different. What Phoenix is doing is pushing Windows into a VM, permanently. The machine boots Linux from the BIOS and loads Windows into a VM container in the background while you have a basic Linux desktop to browse the web, read email, etc. You can flip between Windows and Linux with a hotkey. But Windows stays in the VM. This offers a hope of eventually containing the menace from Redmond. The question is whether Phoenix will want to go there.

      Imagine a real firewall dropped between the virtual NIC in Windows and the real one. Even better, just forget the network in Windows for most uses, use the Firefox on the 'other' more safe system that is a hotkey away. Push this tech a bit more and have seamless Windows(tm) windows running rootless on the X side. Now we don't even need to worry about two different displays. Basically, this tech offers the potential to blur the line between Windows and a real Internet ready system in ways impossible to predict. This could erase enough of Windows' defects to keep it viable or it could remove enough of the reasons to run Windows it hurts it. But Pandora's box is open and it will be interesting.

      • switch between Linux (a full featured distro), Windows, and OS X, but with minimal (almost no) speed penalty, if I'm reading this correctly.

      • by fm6 ( 162816 )

        What Phoenix is doing is pushing Windows into a VM, permanently.

        Depending on what you mean by "permanently", you can do this now: run Windows from a VM under an ordinary Linux distro. The only difference here is that Linux is running out of the BIOS ROM.

        What's the point of running Linux this way? Besides making it harder to update.

        • Re: (Score:3, Informative)

          by jmorris42 ( 1458 ) *

          > What's the point of running Linux this way?

          You are asking the wrong question. Try "What is the point of running Windows this way?" Phoenix isn't trying to push "The Year of Linux on the Desktop" here.

          > you can do this now: run Windows from a VM under an ordinary Linux distro.

          In theory at least. What they hope is different is that is Phoenix doing it. They think they have the power to establish a standard here. If they succeed in pushing Windows on a large percentage of desktops into a secure sa

      • Once Windows is virtualized, it loses nearly all the security gripes I have against it. When you don't need to run antivirus on it, or any of the security updates, it boots and runs quickly. Here's how I imgaine it:
        All user docs are kept outside the VM.
        The VM is destroyed and replaced periodically with a standard image (every day, every hour, or at the whim of the user).

  • by Anonymous Coward on Thursday May 14, 2009 @07:03PM (#27959585)

    Imagine that, a mere 10 years after LinuxBIOS (now CoreBoot) first provided a full linux version on the BIOS (with near-instant booting into the OS of your choice), Phoenix gives us with this remarkable invention (complete with the standard idiotic fawning by Rob Enderle).

  • Boot time? (Score:5, Insightful)

    by Krneki ( 1192201 ) on Thursday May 14, 2009 @07:06PM (#27959613)
    Lately BIOS has become the slowest process of booting.

    I hope they won't increase bloat inside BIOS.
  • Cue jokes about chairs in 3..2..1....
  • If you got a web browser in your BIOS you will probably want to update it one day. Like, when there is a critical security fix to prevent site A from grabbing your private data from site B - something that will not be addressed by not mounting your hard drive. A flash drive, with a physically adjustable write-protect knob, would do nicely. Else you would just have to stop using this feature after a couple of years or the first hardware upgrade and set up your own dual boot.

  • by Eil ( 82413 ) on Thursday May 14, 2009 @07:19PM (#27959745) Homepage Journal

    Now they should put parted and KVM [linux-kvm.org] in there and we can finally be done with the whole concept of dual-booting.

    • Re: (Score:3, Insightful)

      by Eil ( 82413 )

      Oh, never mind. Apparently they did. I should really RTFA before commenting.

  • Wasn't there a similar innovation made by Phoenix or ASUS last year? I can't remember the name of it, but Slashdot covered it.
  • ... would be much better, and a lot safer. I would prefer it of BIOS writers just leave the BIOS as is but allow users to simply choose which drive to boot from so no dual booting is required.

    So you are able to disconnect/switch the other disc electronically via some solid state mechanism, rather then having to go into the bios, using jumpers and dinking around with settings, you should just be able to change the channels, and choose which drive to boot from externally, no virtualization software, no dinki

  • I hope that someone who is more familiar with this will fill in the details, but as I recall one of IBM's mainframe did this back in the 1970's. Basically, every user who logged onto the system got their own virtualized private OS.

  • by gillbates ( 106458 ) on Thursday May 14, 2009 @07:27PM (#27959821) Homepage Journal

    DOS was a BIOS based OS. It passed a large number of its calls directly to the BIOS. We all know how well that worked out.

    That said, I would rather have a read-only, default, fallback, usable OS in the system firmware. You know, something that could be used for:

    1. OS installation.
    2. Basic networking.
    3. Backup and recovery operations.
    4. Performing basic system utilities.

    The PC is one of the few platforms where the hardware is actually useless to the end user without an installed operating system. Reflashable BIOSes further compound the problem by allowing a software command to render the hardware unbootable and unrecoverable (that is, unless you happen to have a FLASH programmer and another computer lying around...). The PC has perhaps the worst architure and implementation of any major platform, and it's about time they did something to fix that.

    In fact, with the falling prices of flash, why not just flash a Linux kernel into the BIOS?

    1. A bootable, usable Linux system with BusyBox can fit into 4 MB of flash.
    2. A 64MB flash (possibly much less) could support the above, plus MicroWindows or similar.
    3. Why bother having a separate OS when the kernel could fit on the firmware?
    4. Let the rest of the system - libraries, apps, configuration, etc... reside on the disk, but keep the hardware related parts (i.e. drivers, etc...) on the firmware itself.
    5. With kernel drivers *in the hardware itself*, one would never have to worry about getting the correct driver, etc...
    • I have wanted that for years, but not just for basic tasks, I want everything from /boot /bin and /sbin at the least, and possibly /etc, /usr/lib, /usr/bin or paths under those. Give it a physical lock to switch between read only and read/write.

      I have fond memories of the acorn archemides machines at school that booted in seconds and ran some pretty cool full 3D graphics stuff in 1991. Even todays latest greatest PCs seem like a step backwards in some ways. They take longer to get to a state that's usable a

    • Atari TOS (Score:3, Informative)

      by tepples ( 727027 )
      What you describe was implemented in the Atari ST.

      Let the rest of the system - libraries, apps, configuration, etc... reside on the disk, but keep the hardware related parts (i.e. drivers, etc...) on the firmware itself.

      That would work for drivers for the chipset, integrated peripherals, and devices that have a class driver (e.g. USB HID, USB storage, SATA storage, SATAPI optical storage). But where would drivers for plug-in PCIe and USB devices go?

    • Re: (Score:3, Informative)

      You know nothing about computers or DOS. DOS didn't have virtual memory. DOS was not a BIOS-based OS; it passed a lot of calls to BIOS, but that can be done just fine, it's a little slower than direct access. Windows did the same, hence why it couldn't access more than 8 gigs of HDD on an old BIOS but when LBA32 showed up it magically could (i.e. Windows 98 first edition, on a non-LBA32 BIOS vs. LBA32 BIOS).
    • DOS was a BIOS based OS. It passed a large number of its calls directly to the BIOS. We all know how well that worked out.

      Let's just call this a gross oversimplification and be done with it, shall we?

      Why bother having a separate OS when the kernel could fit on the firmware?

      For security reasons. Your firmware OS might have exploitable privilege escalation bugs, so you don't want to run untrusted software under it directly, only in a protected virtual machine environment. That virtual machine environment must have its own OS, and that would be a disk-based OS which is easier (and safer) to update in the event that security holes are found. It's preferable if the whole boot environment is as near to possible as read-only, just to reduce the possibility of malicious exploit. It shouldn't even be possible to re-flash the system without physical intervention (such as changing a jumper).

      With kernel drivers *in the hardware itself*, one would never have to worry about getting the correct driver, etc...

      This is true for the flash-based OS and the built-in hardware, which is why you can boot into a usable system so long as enough of the hardware is integrated on the motherboard. Don't forget plug-in cards and external peripherals, though. There's no avoiding the need for those drivers, in general.

  • by 1729 ( 581437 ) <slashdot1729&gmail,com> on Thursday May 14, 2009 @07:39PM (#27959921)

    So, after searching around for the GPL'd components, I finally found a link in the FAQ to this page:

    http://www.hyperspace.com/HyperSpace/OpenSourceRequest.aspx [hyperspace.com]

  • by A beautiful mind ( 821714 ) on Thursday May 14, 2009 @07:45PM (#27959969)
    Why don't they just start to work on coreboot [coreboot.org]? The piece of code shipped currently as BIOS could be so much better. There is an excellent Google Talk about coreboot's improvements [youtube.com].

    It's high time the old unflexible piece of crap BIOS died.
    • Re: (Score:3, Informative)

      by Qubit ( 100461 )

      There are a number of boards and chipsets that work with coreboot, but there are many more that do not.

      My guess is that Phoenix is trying to jump on the it-runs-linux bandwagon, leverage a bit of the benefits of the kernel to make a shiny app, and not really contribute back to the FOSS community any more than they have to. I could be wrong here, and I'd be more than happy to have someone from Phoenix correct me, but that's what these new quick-to-boot environments sound like.

      One possible benefit from this w

  • remain outside of Windows.

    Yes, you said that already:

    'trying to create a new market using the ideas of a fast-booting, safe platform that people can work in

  • by catmistake ( 814204 ) on Thursday May 14, 2009 @08:00PM (#27960095) Journal

    He could boot your OS with a Swiss Army Knife, some duct tape and and old pop top, drawing the electricity needed from a box of old compasses. I guess he's retired from Phoenix by now, though...

  • Basic Input Output System Operating System...

    that's like Personal Identification Number number.

  • by Ungrounded Lightning ( 62228 ) on Thursday May 14, 2009 @08:18PM (#27960273) Journal

    Does this include Linux code in the BIOS itself, or only load it off disk and use it. If the former, did they publish the source?

  • by elronxenu ( 117773 ) on Thursday May 14, 2009 @09:05PM (#27960691) Homepage

    People will be able to distinguish between "my computer has crashed" and "Windows has crashed" because, when Windows dies, they will be able to hot-key to the still-running BIOS OS.

    That's a very nice innovation. I look forward to buying a mobo which can do this.

  • by HW_Hack ( 1031622 ) on Friday May 15, 2009 @01:24AM (#27962399)

    Or at least pee on it and create a wall of FUD. Their mighty and perfect OS usurped by lowly BIOS - and a BIOS running Linux. How totally non-elegant !

    Its a great idea and I would actually have a reason - a real reason - to upgrade my hardware. But I can see M$ telling Dell - HP - etc. if you want to put Windows a BIOSOS system ... no OS discount for you !

    However I would love to see the industry find a way to shove this down Balmers throat.

  • Reframed. (Score:3, Informative)

    by bored ( 40072 ) on Friday May 15, 2009 @02:55PM (#27971711)

    Most of these comments make me want to puke. I've worked on everything from OS and drive code to firmware/bios code. The one thing I've learned is that you _DONT_ want a heavyweight BIOS/firmware. There is a certain appeal to having a system which ships with a hypervisor, and a heavyweight BIOS that can do everything from configure your memory subsystem to allow remote web based console visualization. On the other hand, you have massively complicated and restricted your system. Everyone thinks that putting all this functionality on the motherboard is a good idea because you only have to flash your BIOS once in a while.

    If you want an example of where a heavyweight BIOS leads to, you only have to look at the EFI or OpenFirmware specification. They are so full of technical holes and complexity that nothing works right, and in the case of EFI you have to update the drivers in the BIOS as often as you have to update them in your OS. So, instead of one driver you have two.. Plus flashing cards, or upgrading firmware drivers is _NEVER_ as easy as installing a new OS driver. There is always some technical or human factor that kicks you in the rear.

    I've had this discussion with other people in the field, and basically aside from the zealots a lot of other people agree. The core concept of the PC BIOS is really close to the ultimate design. Of course its 25 years old, so its gained a lot of cruft and bugs, but if you were to start over the goal should be a modern version of the BIOS rather than some embedded OS, hypervisor, etc.

    What you want is fairly lightweight bootstrap and POST utility to get the machine far enough along that you can fetch the hypervisor, or OS from the disk. This means you have to standardize the API for functions like read sector, print text on screen, read data from keyboard etc. You also have to provide the ability to extend or override those functions from a firmware blob sitting on a SAS adapter, or video card.

    This is not an argument against service processors (an entirely separate topic, that people often get confused about), but rather an argument that I don't want my motherboard to try to standardize a hypervisor or OS. I want that decision left up to me. Generally the poor dumb customer doesn't want it either, they just want a machine that runs windows, linux, OSX or whatever, if they are even that detailed. The OS in the firmware people forget that firefox has been sending me weekly (daily?) patches lately, and its likely that over a few years timeframe the later versions of FF won't even run on some older firmware restricted OS without the original vendor providing upgrades. This puts the motherboard vendor in the position of being the support infrastructure for the _WHOLE_ computer. Something i'm sure the majority of them are unable to provide, even though they may have a couple people who can port corebios/linux/etc to run on their hardware.

Genius is ten percent inspiration and fifty percent capital gains.

Working...