Sulfur
Member
I'm not discounting them, and I agree.
I'm not missing the point, I disagree with it. I want the option on my future devices, but why should it be required?
Indeed, UEFI can be used in secure or unsecured mode and what I have read ensures standards when the options are available.
I have read no where that the option MUST be offered and I know from experience how these things can go awry. Couple this with the fact that according to one article, Microsoft is referring to unsecured as custom mode and I become quite a bit more uncomfortable. Custom, in the personal computer commercial lexicon, has a way of always meaning more expensive.
Link me to facts showing my error, and I'll stand down as sincerely, gratefully, corrected.
And speaking of implementation, the HP article I linked seems to explain the architecture in a clear and unbiased fashion.
It raises a simple question.
Why can't this security layer be implemented in software and stored on the hard disk?
In fact, it could. It could be placed on a read only, encrypted partition that bootstraps itself with sufficient encrypted key and encrypted function process returns that it could not be spoofed and would force shutdown if compromised. Said partition could then be re-installed from an optical install disk if compromised, the system booted into a restricted mode to allow sanitation and the rootkit problem would be a thing of the past.
All of this could be accomplished by the same brainpower that thought up the firmware scheme. And this isn't science fiction, it's a known technology. I have personally worked on an industrial software stack with a site license costing between US$1 AND 2 million, and that license system was protected with similar means.
So, this is why I have formed a personal opinion that the sales pitch on this approach being the only way and being primarily for rootkits is Kool Aide.
As for mobile devices, sorry. Were they to implement this on desktops as I suggest and then on mobile platforms as they plan, saying, apologies, no disk, must lock firmware, then I would be OK with that. Plenty of people buy locked Androids knowing that the vendors simply wanted lock-in, and what's good for the goose is good for the gander.
These are just my opinions, though. And as I indicated, I am open to all factual rebuttal. Aren't we all?
It says secure boot must be able to be disable by a physically present user on non-ARM systems in the very same paragraph that says it must be not be possible on ARM systems. Also, custom is a feature concerning "custom" mode, it is a feature to allow modification to the contents of the secure boot signature db's and the PK - also required for the cert on non-ARM devices.
Concerning the question "why can't it be implemented in software and stored on the hard disk"- it seems that it probably could. If you meant 'why isn't it implemented that way', I can't answer that, but increased speed, reliability, and security are the first things that come to my mind. Why would you want it to be, and how does the fact that it likely won't be make them liars about doing it for security and guilty of doing it to stop Linux?
As for the last part... I just don't understand what your problem is then. Manufacturers can and will make devices with whatever UEFI secure boot options they please. If they want their devices to be win8 hardware certified, on non-ARM devices it must be an option to disable it. Again, manufacturers can do as they wish. They are even free to make an x86 machine without the option, against the evil Microsoft's wishes.
Also don't forget, Intel is making a serious push for the mobile market, so expect many more Intel powered tablets in the future... which to be win8 hardware cert'ed must offer a means to disable secure boot in firmware setup.
Because if not, then there's evidence of truth to our side of the debate.
?
If secure boot is not required to have the option to be disabled on all devices in which its implemented, there's evidence of truth to your side of the debate?
