Windows 8 can block the BIOS ?

[area 66]

Someone told me this; Is this true ?

"Area 66, that was insightful but you also left out the issues with the DRM. The reason for the push to UEFI BIOS isn't to make it easier to set up the computer although that is a great point. but when Windows 8 launches one of the things installed ether via the installer or by first update is a UEFI code that will lock you into Windows 8 and Microsoft. If you go the Test Drive route after 30day's BIOS will lock down the computer and turn it into a very expensive Paperweight or if for any reason Windows thinks it's Pirated and I've even had that happen with a corrupted Hard Drive it will also Lock Bios down and once again you have a Very Large and Expensive Paperweight. Plus the other down side is once the UEFI Update is installed you can only install Windows 8 or later, no Linux or any other OS possible.

That's the worst part of Windows 8 as I see it at present and also one of the many reasons I refused to get the Crosshair V and purchased the Crosshair IV Formula. "​

 

[SIW2]

Initially, MS was proposing that oem's enable secure boot as part of the license agreement.

That effectively locks the machine to windows.

After an uproar from enthusiasts, MS changed those proposals so oem's would also need to provide a way to disable it.

There is one exception - ARM machines will still be locked to windows.

Hard to say if that was a double bluff all along.


I hadn't heard the bit about the machine locking down if windows isn't propely activated.

So I don't know the answer to that.

I wouldn't be in the least bit surprised if it was true.

 

[Jav]

Windows 8 can't lock BIOS per se.

UEFI Secure boot that can lock down system into signed OSs is not Windows 8 feature, but UEFI feature.

So, the power is mostly on the hands of OEM manufacturers. But in order to get Microsoft hardware certification, OEM have to comply with Windows Hardware Certification Requirements. (available here: Windows 8 Hardware Certification Requirements)

From the Document above:

2. MANDATORY. Secure Boot must ship enabled .....

...


17. MANDATORY: No in-line mechanism is provided whereby a user can bypass Secure Boot failures and boot anyway Signature verification override during boot when Secure Boot is enabled is not allowed. A physically present user override is not permitted for UEFI images that fail signature verification during boot. If a user wants to boot an image that does not pass signature verification, they must explicitly disable Secure Boot on the target system.

...

20. MANDATORY: On non-ARM systems, the platform MUST implement the ability for a physically present user to select between two Secure Boot modes in firmware setup: "Custom" and "Standard". Custom Mode allows for more flexibility as specified in the following:

a) It shall be possible for a physically present user to use the Custom Mode firmware setup option to modify the contents of the Secure Boot signature databases and the PK.
b) If the user ends up deleting the PK then, upon exiting the Custom Mode firmware setup, the system will be operating in Setup Mode with Secure Boot turned off.
c) The firmware setup shall indicate if Secure Boot is turned on, and if it is operated in Standard or Custom Mode. The firmware setup must provide an option to return from Custom to Standard Mode which restores the factory defaults.
On an ARM system, it is forbidden to enable Custom Mode. Only Standard Mode may be enable.

21. MANDATORY: Enable/Disable Secure Boot. On non-ARM systems, it is required to implement the ability to disable Secure Boot via firmware setup. A physically present user must be allowed to disable Secure Boot via firmware setup without possession of PKpriv. Programmatic disabling of Secure Boot either during Boot Services or after exiting EFI Boot Services MUST NOT be possible.
Disabling Secure MUST NOT be possible on ARM systems.

Technically, even with UEFI secure boot enable it is possible to boot signed Linux distributions, if signature trusted by UEFI (which probably won't happen). See: mjg59 | Why UEFI secure boot is difficult for Linux

Also, about myth that Secure Boot can be used as DRM

Secure Boot can be used to implement DRM
Untrue. The argument here is that Secure Boot can be used to restrict the software that a machine can run, and so can limit a system to running code that implements effective copy protection mechanisms. This isn't the case. For that to be true, there would need to be a mechanism for the OS to identify which code had been run in the pre-OS environment. There isn't. The only communication channel between the firmware and the OS is via a single UEFI variable called "SecureBoot", which may be either "1" or "0". Additionally, the firmware may provide a table to the OS containing a list of UEFI executables that failed to authenticate. It is not required to provide any information about the executables that authenticated correctly.

In both these cases, the OS is required to trust the firmware. If the firmware has been compromised in any way (such as the user turning off Secure Boot), the data provided by the firmware can be trivially modified and the OS told that everything is fine. As long as machines exist where users are permitted to disable Secure Boot, Secure Boot is not any kind of DRM scheme.
from: mjg59 | Some things you may have heard about Secure Boot which aren't entirely true

Re what you heard:

"Area 66, that was insightful but you also left out the issues with the DRM. The reason for the push to UEFI BIOS isn't to make it easier to set up the computer although that is a great point. but when Windows 8 launches one of the things installed ether via the installer or by first update is a UEFI code that will lock you into Windows 8 and Microsoft. If you go the Test Drive route after 30day's BIOS will lock down the computer and turn it into a very expensive Paperweight or if for any reason Windows thinks it's Pirated and I've even had that happen with a corrupted Hard Drive it will also Lock Bios down and once again you have a Very Large and Expensive Paperweight. Plus the other down side is once the UEFI Update is installed you can only install Windows 8 or later, no Linux or any other OS possible.

So called UEFI "Update" is not pushed by OS. It is impossible for OS to modify UEFI secure boot code. It should be enabled in UEFI firmware either by user or OEM. And it should be installed by OEM's.
Look at last quote regarding DRM. Also as long as it is non-ARM device OEMs are required to put Secure Boot switch, which mean you can just turn it off and it won't become "expensive Paperweight".

I hope it clarify some points.


More reading:
Protecting the pre-OS environment with UEFI - Building Windows 8 - Site Home - MSDN Blogs
Microsoft confirms UEFI fears, locks down ARM devices - SFLC Blog - Software Freedom Law Center
Microsoft: Don't blame us if Windows 8's secure boot requirement blocks Linux dual-boot | ZDNet

 

[Kat]

Well, unless it CAN be disabled, I don't want that sort of garbage anywhere NEAR my system.

Nor would I consider purchasing a system with this enabled/locked.

No-one should be able to control what I install on my system but ME.