I don't see why linux can't adapt to these boot protection schemes. Self-signed or vendor signed, as long as there's a way to import your key information, what's the issue?
Ah, I see you are utterly oblivious to the topic being discussed. Linux could easily adapt. The problem is that MS is using their position in the industry to bias this security measure entirely in their favor and against any and all Linux platforms. All the vendors will have Microsoft's keys. They are unlikely to have any keys for any Linux vendors, possibly aside from Redhat and SuSE. On top of that, they are extremely unlikely to add key management capabilities into consumer hardware so if you make a custom build of GRUB, LILO, or whatever the *BSDs use, you're shit out of luck.
MS (and partners) would be opening themselves up to swift antitrust action again if they were to engage in industrywide attempts to lock out OtherOS.
Well, it'll just be more subtle than that. MS leaves it open to the whims of vendors, with a helpful nudge into the locked state. And the vendors oblige. No provable conspiracy, just "market forces" at work.
there are deployments out there where people WOULD like systems where you CAN'T disable secure boot
Then, obviously, they should be able to install their own keys and lock out free access to the BIOS.
It is unlikely that this type of configuration is one that would be used in the general consumer market; there's too much of a need for boot media and utility software. Imagine not being able to run memcheck or a recovery tool, ever.
Well, that's why you send it back to the manufacturer or buy a new one. You aren't supposed to understand computers, after all. They're the New TV and the Internet is the new Cable.
everybody needs to be on the same page
And from the looks of things, all the OEMs and system vendors are on the same page. Microsoft's.
Windows 7 already supports UEFI boot and I'm sure the bootloader and kernel are already signed. I imagine what they don't have is the tight integration between the boot verification and the DRM subsystems/Bitlocker.
Even if your link showed that there was an incredible concerted effort to cram DRM down the throats of unwilling consumers everywhere
And yet, in the face of DRM system after DRM system being introduced, you deny that the industry isn't explicitly taking this route? HDCP was created by Intel, this boot lockout method was developed by a consortium including Apple, Microsoft, and Intel as the biggest players. Virtually every ARM chip includes such system-crippling capabilities and it is regularly deployed. Microsoft has created and unleashed multiple DRM systems, Apple continues to use DRM on virtually everything except Music and OS X. Ebooks are plagued out the gate with DRM.
They have been trying for a long time now to ram DRM down our throats. Here is the perfect chance to take yet another possible avenue of piracy away.
it doesn't provide evidence that PC manufacturers are going to disable the ability to change the secure boot parameter
No, but it's a pretty easy conjecture. Consoles, tablets, and smartphones have shown that so long as you don't unduly hinder people's ability to tune out and consume, they generally won't put up a fuss. And as a bonus, you can recruit them to shout down those who disagree with your actions.
locking the OS down to Windows doesn't do any good unless you ensure that your media could only be played on Windows... but that step alone fulfills the requirements, because simply installing an alternative OS won't circumvent that restriction
Well, they don't need to worry about ensuring it doesn't play on other platforms because you won't be able to boot other platforms. And if they are truly concerned, they could always store the keys in a TPM module, and ensure it goes from the TPM module to the CPU's cache for decryption and ensure it never hits system memory.
The primary benefits come in when you're a major system buyer needing to administer many machines, possibly before the OS comes up. But it's better than the BIOS as a whole due to not being limited to the 16-bit modes of the CPU, instead switching rapidly into the 64-bit environment immediately, far easier to develop option ROMs for, and if set up properly, and with properly written option roms (a.k.a. drivers) can boot much faster.
Of course, all of this could have been had with OpenFirmware but Intel decided they were too good for that.
EFI is what happens when Intel (rightly) concludes that switching to a new architecture, IA64, would allow them to abandon all the problems of x86 and thus eliminate the then 20 year old BIOS in favor of something more capable. It is also what happens when Intel goes hugely NIH and decides to create something almost, but not quite, like OpenFirmware.
large enough to possess every vice of an operating system and leave implementation to the capable hands of the PC OEMs, whose dedication to software quality is legendar[y]...
No joke. I'm working with a vendor that is implementing one now, and it's quite chaotic. Also the "browser" system used by UEFI for creating GUI dialogs for the platform is probably one of the worst ways to do a GUI, definitely showing its Intel state machine roots rather than something more apt like Qt or even WinForms.
How many people will actually remove iOS or Android to get Ubuntu?
If I could remove Android and install more standard Linux platform and not lose any functionality, I'd do so.
It's one of those things that I hoped would have come with this massive advancement in mobile technology. Unfortunately I am seeing the opposite, with phones being deliberately abandoned with old OSes that are incompatible with revisions in its own line, much less the wider Linux world, and set up in such ways as to fight you.
And when it comes down to it, the Raspberry Pi was not designed to target the developing world, but students. The goal is to replace the BBC Micro and other easily accessible PCs with something cheap enough for the student to buy (or purchased in quantity with minor outlay.)
If governments or charities in developing nations wish to supply these, they will undoubtedly be made aware of the peripheral requirements. Of course, when the PC costs a mere $25, the entire landscape changes regardless.
I know, it's so terrible getting regular security updates.
new GUI every 6 weeks
Funny, after I installed FF4 I reset the UI to FF3.5 style. Now I'm on Nightly 10 and it looks the same.
I want long term stability in my browser. Not this crap.
Fortunately it's javascript, so it won't impact the browser itself at all.
I'll install the plugins I need.
Enjoy your Adobe-introduced security holes.
Oh. About:plugins. Stop breaking them every 3 months.
The single biggest problem is addon developers not bothering to keep pace with FF development. That is to say, they don't bother to update it while it's in Beta and people are upset their addons break on release. Whereas well maintained plugins like NoScript work great even on the bleeding edge, hell even some that haven't been updated for anything past 5 work fine if the version number is ticked upwards.
Personally, I think they should be forced to offer sim-only plans with no contract that are discounted to account for the lack of a subsidized handset. And they should all use the same radio protocol so I can move my handset freely between them and force them to compete on price and features.
When the design cycle started for the N1, the only suitable SoC options needed a NAND flash and an 8GB or 16GB eMMC with the reliability needed for fixed storage were prohibitive.
And yet it was designed and released later than the N900, which included a 32GB eMMC and cost only a hair more than an unlocked Nexus One. They could totally have included an 8GB eMMC. Moot argument at this point though.
Newer phones that will supposedly support ICS have embedded MMC (eMMC) which comes in much larger capacities, making this a non-issue.
The sad thing here is how the iPhone and my N900 both came with large eMMC chips back in 2009, while so many Android devices are just now getting around to it. This was a problem ages ago on the G1 and they never pushed for a resolution.
Most if not all ARM devices have a bootloader (kinda similar to BIOS) - it provides less kernel compatibility provisions than a BIOS, but, at least on Samsungs, you can't brick unless you accidentally torch the bootloader - and it's pretty hard to do that.
Some provide security for this, yes. Depends on how capable the loader is or if they're the kind that just jumps straight to whatever u-boot is on the NAND.
I've "softbricked" with bad kernels many times (I maintain a custom kernel for the Infuse and AT&T S2...). Took 30 seconds to enter download mode, fire up Heimdall, and flash a known good kernel.
And most people have no trouble recovering their PC after a failed boot. This is just a tiny part of the problem that just happens to be riskier on ARM than PC and is more likely to kill the device in a way that most people can't recover from (and recovery methods vary between device.)
Because every ARM board is unique, and there is no universal means for an OS to determine hardware capabilities and peripherals.
On the PC we have the BIOS, PCI, ACPI, and a number of other facilities that work well enough that the OS can automatically enumerate the hardware and configure itself to operate on the platform. With ARM devices, even between two boards with the same SoC you'll have peripherals connected via different GPIOs, interrupts on different pins, a wide array of voltage regulators (some more, some less, all connected differently.)
And since everything is stored in a flash chip at a custom location, working with the kernel and bootloader is a lot like working with the BIOS on your pc- if you mess it up, your device is screwed (unless it can cold flash, has a hard ROM for flashing, or accessible JTAG, all of which are extremely rare on consumer level devices.)
But even if you have all of the above taken care of, the complete lack of effort on behalf of Google and the hardware vendors to getting their changes upstream in the kernel generally means that porting newer versions of Android to older devices is a pain in the ass due to needing to rework or sometimes rewrite the drivers. Normally they would be updated and tested by people as the kernel moved forward, but instead they rot in tarballs and zip files out on vendor websites.
Never mind Google's wacky reworking of the file system. I'm sure devices like the Nexus One have plenty of space to store ICS. But their broken layout and insistence on storing applications on that NAND instead of having a higher capacity internal NAND or only storing applications on the SD card is a large part of this problem as well.
Good luck doing so on an ARM device. It sounds easy, but in reality it's a bitch due to the complete lack of all the plug and play support available now on x86 platforms.
Microsoft is explicitly not supporting Win32 on ARM. For Windows 8 on ARM the only available APIs will be WinRT and Metro.
Windows 8 on ARM will ship with the full desktop.
Again, minus Win32 support. Disable IE10, your system will break. Never mind the intensely anti-competitive slant of barring the distribution of WinRT/Metro applications except by Microsoft's store.
They aren't hurting, but we've had some 10 years during which MS was under the watchful eye of the DoJ. I expect that had they not been under such "surveillance" then the last 10 years, and the current state of the industry, would be very different.
Microsoft is retreating to patent suits, as they noted in 1998, to attack Linux now so we're not remotely safe from future anti-competitive acts.
Slashdot Mirror
Ah, I see you are utterly oblivious to the topic being discussed. Linux could easily adapt. The problem is that MS is using their position in the industry to bias this security measure entirely in their favor and against any and all Linux platforms. All the vendors will have Microsoft's keys. They are unlikely to have any keys for any Linux vendors, possibly aside from Redhat and SuSE. On top of that, they are extremely unlikely to add key management capabilities into consumer hardware so if you make a custom build of GRUB, LILO, or whatever the *BSDs use, you're shit out of luck.
Well, it'll just be more subtle than that. MS leaves it open to the whims of vendors, with a helpful nudge into the locked state. And the vendors oblige. No provable conspiracy, just "market forces" at work.
Then, obviously, they should be able to install their own keys and lock out free access to the BIOS.
Well, that's why you send it back to the manufacturer or buy a new one. You aren't supposed to understand computers, after all. They're the New TV and the Internet is the new Cable.
And from the looks of things, all the OEMs and system vendors are on the same page. Microsoft's.
Windows 7 already supports UEFI boot and I'm sure the bootloader and kernel are already signed. I imagine what they don't have is the tight integration between the boot verification and the DRM subsystems/Bitlocker.
And yet, in the face of DRM system after DRM system being introduced, you deny that the industry isn't explicitly taking this route? HDCP was created by Intel, this boot lockout method was developed by a consortium including Apple, Microsoft, and Intel as the biggest players. Virtually every ARM chip includes such system-crippling capabilities and it is regularly deployed. Microsoft has created and unleashed multiple DRM systems, Apple continues to use DRM on virtually everything except Music and OS X. Ebooks are plagued out the gate with DRM.
They have been trying for a long time now to ram DRM down our throats. Here is the perfect chance to take yet another possible avenue of piracy away.
No, but it's a pretty easy conjecture. Consoles, tablets, and smartphones have shown that so long as you don't unduly hinder people's ability to tune out and consume, they generally won't put up a fuss. And as a bonus, you can recruit them to shout down those who disagree with your actions.
Well, they don't need to worry about ensuring it doesn't play on other platforms because you won't be able to boot other platforms. And if they are truly concerned, they could always store the keys in a TPM module, and ensure it goes from the TPM module to the CPU's cache for decryption and ensure it never hits system memory.
It will be true, but not the fault of the OS (rather, an unfair and untrustworthy means of key distribution.)
The primary benefits come in when you're a major system buyer needing to administer many machines, possibly before the OS comes up. But it's better than the BIOS as a whole due to not being limited to the 16-bit modes of the CPU, instead switching rapidly into the 64-bit environment immediately, far easier to develop option ROMs for, and if set up properly, and with properly written option roms (a.k.a. drivers) can boot much faster.
Of course, all of this could have been had with OpenFirmware but Intel decided they were too good for that.
EFI is what happens when Intel (rightly) concludes that switching to a new architecture, IA64, would allow them to abandon all the problems of x86 and thus eliminate the then 20 year old BIOS in favor of something more capable. It is also what happens when Intel goes hugely NIH and decides to create something almost, but not quite, like OpenFirmware.
No joke. I'm working with a vendor that is implementing one now, and it's quite chaotic. Also the "browser" system used by UEFI for creating GUI dialogs for the platform is probably one of the worst ways to do a GUI, definitely showing its Intel state machine roots rather than something more apt like Qt or even WinForms.
Damnit. Posting to clear bad mod :(
If I could remove Android and install more standard Linux platform and not lose any functionality, I'd do so.
It's one of those things that I hoped would have come with this massive advancement in mobile technology. Unfortunately I am seeing the opposite, with phones being deliberately abandoned with old OSes that are incompatible with revisions in its own line, much less the wider Linux world, and set up in such ways as to fight you.
Or it's the mark of an anti-FOSS troll, and looking at hairyfeet's posting history, he certainly comes across as one.
And when it comes down to it, the Raspberry Pi was not designed to target the developing world, but students. The goal is to replace the BBC Micro and other easily accessible PCs with something cheap enough for the student to buy (or purchased in quantity with minor outlay.)
If governments or charities in developing nations wish to supply these, they will undoubtedly be made aware of the peripheral requirements. Of course, when the PC costs a mere $25, the entire landscape changes regardless.
I know, it's so terrible getting regular security updates.
Funny, after I installed FF4 I reset the UI to FF3.5 style. Now I'm on Nightly 10 and it looks the same.
Fortunately it's javascript, so it won't impact the browser itself at all.
Enjoy your Adobe-introduced security holes.
The single biggest problem is addon developers not bothering to keep pace with FF development. That is to say, they don't bother to update it while it's in Beta and people are upset their addons break on release. Whereas well maintained plugins like NoScript work great even on the bleeding edge, hell even some that haven't been updated for anything past 5 work fine if the version number is ticked upwards.
Just like how they fixed Motorola's secure boot process, right? Oh, wait. Those are still locked and the kernel can't be replaced.
Personally, I think they should be forced to offer sim-only plans with no contract that are discounted to account for the lack of a subsidized handset. And they should all use the same radio protocol so I can move my handset freely between them and force them to compete on price and features.
In most cases, all but the video drivers are open source. The problem is they sit and rot in an old kernel and no one cares to port them forward.
Let alone shit Chinese tablets that don't release their kernel at all, in complete violation of the GPL.
More effort than it is worth. No one should have to dance with a security system that is working against them to do as they wish on their own devices.
When the design cycle started for the N1, the only suitable SoC options needed a NAND flash and an 8GB or 16GB eMMC with the reliability needed for fixed storage were prohibitive.
And yet it was designed and released later than the N900, which included a 32GB eMMC and cost only a hair more than an unlocked Nexus One. They could totally have included an 8GB eMMC. Moot argument at this point though.
Newer phones that will supposedly support ICS have embedded MMC (eMMC) which comes in much larger capacities, making this a non-issue.
The sad thing here is how the iPhone and my N900 both came with large eMMC chips back in 2009, while so many Android devices are just now getting around to it. This was a problem ages ago on the G1 and they never pushed for a resolution.
Most if not all ARM devices have a bootloader (kinda similar to BIOS) - it provides less kernel compatibility provisions than a BIOS, but, at least on Samsungs, you can't brick unless you accidentally torch the bootloader - and it's pretty hard to do that.
Some provide security for this, yes. Depends on how capable the loader is or if they're the kind that just jumps straight to whatever u-boot is on the NAND.
I've "softbricked" with bad kernels many times (I maintain a custom kernel for the Infuse and AT&T S2...). Took 30 seconds to enter download mode, fire up Heimdall, and flash a known good kernel.
And most people have no trouble recovering their PC after a failed boot. This is just a tiny part of the problem that just happens to be riskier on ARM than PC and is more likely to kill the device in a way that most people can't recover from (and recovery methods vary between device.)
With iOS there's also the $99 per year tax to run applications from outside the App Store.
Don't forget the 90 day limit before you have to repackage and re-upload the application!
Because every ARM board is unique, and there is no universal means for an OS to determine hardware capabilities and peripherals.
On the PC we have the BIOS, PCI, ACPI, and a number of other facilities that work well enough that the OS can automatically enumerate the hardware and configure itself to operate on the platform. With ARM devices, even between two boards with the same SoC you'll have peripherals connected via different GPIOs, interrupts on different pins, a wide array of voltage regulators (some more, some less, all connected differently.)
And since everything is stored in a flash chip at a custom location, working with the kernel and bootloader is a lot like working with the BIOS on your pc- if you mess it up, your device is screwed (unless it can cold flash, has a hard ROM for flashing, or accessible JTAG, all of which are extremely rare on consumer level devices.)
But even if you have all of the above taken care of, the complete lack of effort on behalf of Google and the hardware vendors to getting their changes upstream in the kernel generally means that porting newer versions of Android to older devices is a pain in the ass due to needing to rework or sometimes rewrite the drivers. Normally they would be updated and tested by people as the kernel moved forward, but instead they rot in tarballs and zip files out on vendor websites.
Never mind Google's wacky reworking of the file system. I'm sure devices like the Nexus One have plenty of space to store ICS. But their broken layout and insistence on storing applications on that NAND instead of having a higher capacity internal NAND or only storing applications on the SD card is a large part of this problem as well.
Good luck doing so on an ARM device. It sounds easy, but in reality it's a bitch due to the complete lack of all the plug and play support available now on x86 platforms.
Microsoft is explicitly not supporting Win32 on ARM. For Windows 8 on ARM the only available APIs will be WinRT and Metro.
Windows 8 on ARM will ship with the full desktop.
Again, minus Win32 support. Disable IE10, your system will break. Never mind the intensely anti-competitive slant of barring the distribution of WinRT/Metro applications except by Microsoft's store.
Because you may end up with an ARM tablet somehow. Or maybe they'll move in that direction with consumer hardware.
Unless you're on ARM, in which case you won't be able to use anything but Metro apps.
They aren't hurting, but we've had some 10 years during which MS was under the watchful eye of the DoJ. I expect that had they not been under such "surveillance" then the last 10 years, and the current state of the industry, would be very different.
Microsoft is retreating to patent suits, as they noted in 1998, to attack Linux now so we're not remotely safe from future anti-competitive acts.