Slashdot Mirror
Phoenix BIOSOS?
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.'"
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).
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 one before June. Otherwise HyperSpace will essentially be SplashTop (which made it to market first) on Steroids. Which should make it much more appealing to geeks and non-geeks alike.
If I understand it correctly HyperSpace would have the added nicety of being able to switch somewhat instantaneously between two OS's. I don't remember reading anything on the Splashtop site that it was able to do that.
Hyperspace is also subscription-based software. Screw paying yearly to use this! I'd rather kill a few bios chips or get an Asus board (*shudder* so many bad ones) than be paying yearly
There is so much FUD about Trusted computting. Go watch Security Now Ep. 99 It will change how you think about trusted computing. It will separate the truth from the FUD.
Yes, IBM used a similar, but more comprehensive approach in the System/38 - AS/400 - iSeries. Strictly speaking, the SLIC encompased this and loaded a "virtual machine" (similar to the JVM in Java) which provided the instruction set and support for the higher-level operating system.
This idea of putting Linux itself into the BIOS is okay if and only if the chip containing the BIOS is replaceable. In other words, the chip should not be soldered to the board.
You're joking, right? Right????
Because if not, read this then flagellate yourself 20 times with an RS232 cable.
"I don't know, therefore Aliens" Wafflebox1
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
Virtually? It's called a hypervisor. How do you think any VM works?
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 work is that Phoenix will probably need to release the underlying kernel code that they use to talk to all of the hardware. Even if they don't want to make all of their toys Free Software, if we can at least get enough information from the Phoenix kernel improvements to make coreboot talk to the hardware, then we're in pretty handy shape.
coding is life
Correct me if I am wrong, but I don't think Coreboot supports using the onboard Linux OS even after you boot Windows or another OS while this does.
Even the absolute worst flash memory can be written hundreds of times without any issues.
At a reasonable update schedule of once a month, that would be no less than 10 years. You would almoste certainly be able to update once a week for 3-4 years. And this is worst case...I would be surprised if you would really even want to use the computer anymore (due to performance issues) by the time the flash wore out 15-20 years down the road.
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?
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 on who's controlling it) is able to restrict access to the tpm, allowing only "trusted entities" to configure it. If you own the machine, but don't have full access and control of the hypervisor, this is bad. If you don't own the machine, and don't have that access and control, this is good.
> 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 sandbox it changes the game. You or me running Windows in VMWare doesn't.
For them to pull it off they are going to have to provide a seamless experience. That means no noticable performance hit, full DX10 support by somehow virtualizing the video such that whichever OS is visible gets almost full hardware access, yet can somehow be flipped to a virtual device when the other OS gets activated. WHen an average user flips to Windows they can't realize it is a VM. All of their games, video stuff, USB devices, etc. have to work normally. I'm guessing a buttload of custom Windows drivers are going to be needed. And I'd also guess you won't be able to put any ol video card in and have it work, especially the first year or two.
Democrat delenda est
Comment removed based on user account deletion
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).
Support my political activism on Patreon.
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.
proof, n. A demonstration that a conclusion is implied by certain premises and axioms.
Its a tool, and can be used for good/ill. I actively build/buy servers and laptops with TPM functionality because it allows me to enable encryption with BitLocker, save the recovery key someplace secure (safe deposit box), and from there on out, the encryption is completely forgotten about. On laptops, I enable the PIN functionality so an intruder would have to have the tech of a chip fab to coax the information needed to grab the HD contents. Even though TPM chips are not hardened against physical attack, few thieves outside of intel agencies have the tech to rip open a chip's package and attach probes to the chip's microscopic pads.
Either way, servers can reboot unattended while the data is encrypted, and laptops are protected against brute force password attacks. If an intruder tries to repeatedly guess a PIN, the TPM will just keep forcing longer and longer delays, if not permanently locking.
All a TPM is, is a cryptographic token that is on the hardware, with two pieces of additional functionality: The ability to validate that the MBR and booting parts of the hard disk have not been tampered with, and remote attestation.
The ability to check for tampering is important because in theory, someone can put a keylogger on the boot sector, then pass the info onto the real preboot authentication system (PGP or TrueCrypt) while saving the boot passphrase for an attacker in some safe area. If someone tries to tamper with the BitLocker subsystem, the TPM won't allow the machine to boot and it will be obvious that something is fishy.
Remote attestation is controversial, but you don't have to turn it on in BIOS. Same with Intel's vPro stuff.
Finally, by the TPM spec, all TPM chips are shipped turned off and disabled by default, so a software maker can't depend on one for DRM reasons.
Not really, all decent systems have two separate BIOS flash areas and will only update the second one after a successful startup from the primary. Heck some systems have that AND a minimal BIOS in ROM so they can always recover even if the flash is scambled (HP workstations and servers do this, stick a floppy in and hit a special key during powerup or flip a DIP and they will read the flash file from the floppy and write it to BIOS flash).
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
OSS is a panacea for people that actually own the device and are geeks.
***Sane supports most of the more common brands of scanner, provided they don't rely on funky things like parallel ports.*** No, unfortunately, it doesn't. It supports some devices well, many after a fashion, and many not at all. The list of supported devices is here: http://www3.sane-project.org/sane-supported-devices.html I use Linux almost exclusively because a decade of supporting Windows PCs left me with a deep and abiding disgust with that once promising OS gone sour. In my experience, most peripherals are fairly well supported under Linux although it takes the miracle of ndiswrapper (a wrapper around the Windows drivers) to use some wireless interfaces. Scanners are an exception I think. If the problems aren't too bad, being able to run in Linux and switch painlessly to Windows for rarely used peripherals and jobs like US income tax preparation that are iffy under Wine, could be a viable alternative for many of us.
You can't see ANYTHING from a car, You've got to get out of the goddamned contraption and walk...Edward Abbey
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.