I've always been very annoyed by the firmware initialize -> kernel reinitialize delay. If only we had open source standardized firmware on x86 there could be a common data structure to pass through validated firmware and its associated memory ranges to the payload. Maybe even an OS could write its device initialization library to ROM so the firmware could do diagnostic checks on all the present hardware before trying to do dangerous disk reads (hey coreboot).
Secure Boot isn't the only problem facing Linux on Windows 8 hardware
131–140 of 178 posts
Re: Secure Boot isn't the only problem facing Linux on Windows 8 hardware
#132Earlier quoted context omitted.
Surely a physically present user (mentioned by the requirement of point 18) can disconnect the boot device in order to prevent Windows from booting. The firmware then has ample time to set up USB and allow the user to enter firmware setup. Alternatively, as a workaround, find someone who has already accepted said agreement elsewhere and have them accept it on your device, disable secure boot and wipe the boot device.
> a physically present user (mentioned by the requirement of point 18) can disconnect the boot device in order to prevent Windows from booting. I believe that would void most warranties.
In the case of a general purpose computer, I'm willing to bet you'd be wrong. We're not talking about a Surface tablet here.
Re: Secure Boot isn't the only problem facing Linux on Windows 8 hardware
#133Earlier quoted context omitted.
> a physically present user (mentioned by the requirement of point 18) can disconnect the boot device in order to prevent Windows from booting. I believe that would void most warranties.
In the case of a general purpose computer, I'm willing to bet you'd be wrong. We're not talking about a Surface tablet here.
Have you looked at an Ultrabook? Getting at the hard drive involves disassembling the entire machine, something that's almost impossible to do without either specialised tools or a willingness to inflict some amount of cosmetic damage.
Re: Secure Boot isn't the only problem facing Linux on Windows 8 hardware
#134FWIW, As a lawyer, I have a lot of trouble believing that assent to a contract you can't avoid, done specifically for the purpose of removing the contracted software, would ever be held to bind you to the terms and conditions of that contract. In fact, i'd go so far as to say that if Microsoft ever actually tried to enforce, it would run them into serious regulatory trouble. If push came to shove, i'm sure they would…
Thanks for that. That leaves just one legal issue that really needs to be raised: How is it legal to _deny_ me full access (defined by the removal of all Microsoft software, something the European Commission has repeatedly upheld) until I have completed some Microsoft-controlled procedure? I don't want Windows on the machine. Assuming I buy from the 3 largest vendors, excluding Apple, is it not anti-competitive to _l…
You seem to be under the impression that this setup was created for the express purpose of denying you access to the hardware until you have agreed to the EULA.
However that is a direct contradiction of the person you are responding to, who mentions that this is a vestige of a certain set of configuration options that are common on Windows 8 machines.
This is not intended, and will likely be patched if enough complaints are heard. Remember they are just requiring that you accept their EULA to boot their OS, denying you access to the firmware was never their intent.
Re: Secure Boot isn't the only problem facing Linux on Windows 8 hardware
#135Earlier quoted context omitted.
From System.Fundamentals.Firmware.FirmwareSupportsUSBDevices: The USB controller and USB devices must be fully enumerated when: * Anything other than the Windows Boot Manager is at the top of the system boot order. * A boot next variable has been set to boot to something other than the Windows Boot Manager. * On a system where the Windows Boot Manager is at the top of the list, an error case has been hit, such that t…
Does this mean that the hardware is pretty much guaranteed to boot slower if not booting Windows too, in order to do USB initialisation, even when not going to the boot screen?
I wouldn't have thought so - I'd think that Linux would be perfectly capable of utilizing the same 'fast boot' logic as Windows has.
I think it only applies to "getting into a USB boot / install environment".
Re: Secure Boot isn't the only problem facing Linux on Windows 8 hardware
#136Earlier quoted context omitted.
Dell probably couldn't sell the computer for a lower price with no OS or a free OS without losing money I find this hard to believe, even when considering all the mechanisms you mentioned. Do you have any evidence for this very counter-intuitive hypothesis? IOW: Citation needed
Perhaps you need to change the way you think about the PC industry and the way it produces integrated machines? Even if you skip the huge cost of qualifying parts for a different operating system, and sell PCs without any hardware or software support, there are still extra tracking and stock-keeping costs, and probably extra marketing costs. These will be high, in unit terms, because of the small number of units ship…
Plenty of machines have shipped with buggy drivers, poor OS support for the hardware and similar problems. I've never heard of a consumer PC manufacturer having legal liability for issues like that, and can't imagine it would be different with no preloaded OS or an explicitly unsupported preloaded OS.
The Windows 8 EULA says:
The manufacturer or installer and Microsoft exclude all implied warranties, including those of merchantability, fitness for a particular purpose, and non-infringement.
It's my understanding (IANAL) that laws in the US and most other developed countries attach a warranty to all products sold that they're suitable for sale (merchantability) and for use the way a reasonable person would expect (fitness for a particular purpose). I believe software usually gets around that requirement by being licensed with such terms included rather than sold.
I think there's a good counterargument here to the claim I often see on HN that a PC with Windows preloaded is an integrated product rather than two independent products sold as a bundle. The license terms very clearly state that the Windows part is not guaranteed to work as expected, or indeed to do anything at all. The hardware, on the other hand generally comes with a written warranty stating that it will work, or the manufacturer will repair or replace it.
Re: Secure Boot isn't the only problem facing Linux on Windows 8 hardware
#137Earlier quoted context omitted.
With Windows 8 it no longer is.
'PC' ('personal computer') is a general purpose computing device, based on the original IBM architecture. The point is, it was never tied to any particular operating system. Any attempt to 'tie' the hardware to a proprietary OS can be met with a legal challenge on these grounds. So, regardless of what manufacturers would like customers to think, it is possible to obtain an OS-free computer, even if it entails refusin…
You appear to be entirely unaware that Microsoft has spent the best part of a decade responding and working with a Justice Department who was acting on behalf of frustrated or outraged consumers and competitors who believed exactly that. They came to a partial agreement with your position, whilst dismissing other claims entirely.
Re: Secure Boot isn't the only problem facing Linux on Windows 8 hardware
#138Earlier quoted context omitted.
Does this mean that the hardware is pretty much guaranteed to boot slower if not booting Windows too, in order to do USB initialisation, even when not going to the boot screen?
I wouldn't have thought so - I'd think that Linux would be perfectly capable of utilizing the same 'fast boot' logic as Windows has. I think it only applies to "getting into a USB boot / install environment".
The spec says that the feature should be disabled if any UEFI boot entry other than "Windows Boot Manager" is chosen. Whether that's actually implemented, I don't know.
Re: Secure Boot isn't the only problem facing Linux on Windows 8 hardware
#139Earlier quoted context omitted.
Perhaps you need to change the way you think about the PC industry and the way it produces integrated machines? Even if you skip the huge cost of qualifying parts for a different operating system, and sell PCs without any hardware or software support, there are still extra tracking and stock-keeping costs, and probably extra marketing costs. These will be high, in unit terms, because of the small number of units ship…
Plenty of machines have shipped with buggy drivers, poor OS support for the hardware and similar problems. I've never heard of a consumer PC manufacturer having legal liability for issues like that, and can't imagine it would be different with no preloaded OS or an explicitly unsupported preloaded OS. The Windows 8 EULA says: The manufacturer or installer and Microsoft exclude all implied warranties, including those…
> The Windows 8 EULA says:
Which is absolutely irrelevant for example in Germany, as customers (a) buy the computer/license before agreeing to the EULA and (b) most of the statements in the EULA (no warranties, e.g.) cannot be legally included in any contract with a customer/end-user.
Re: Secure Boot isn't the only problem facing Linux on Windows 8 hardware
#140Earlier quoted context omitted.
I wouldn't have thought so - I'd think that Linux would be perfectly capable of utilizing the same 'fast boot' logic as Windows has. I think it only applies to "getting into a USB boot / install environment".
The spec says that the feature should be disabled if any UEFI boot entry other than "Windows Boot Manager" is chosen. Whether that's actually implemented, I don't know.
Regardless, it should be possible for the third party loader to claim to be "Windows Boot Manager".
I can't imagine that there would be any cryptographic verification that the boot loader is actually "Windows Boot Manager". This is because the crypto logic is essential to check that the binary is signed by a trusted key. This process would happen before the UEFI thinks about entering the boot loader. It would also not make sense for the crypto section to make any associations between the keys and who signed them (apart from giving the user information).
Still, it seems like a bad spec to create special cases for named hardware. Hopefully, we will arrive at a standard where the OS can signal if the feature should be disabled, or make it a toggleable setting (which, from what I understand of UEFI, the OS can toggle). Unfourtuantly, depending on how strict MS is with their certification standards, this would prevent the computers from being certified.