@Yen the first assumption I had made was that secure boot could be optional and Windows 8 would still activate via OEM_SLP. the second assumption was that something like a SLIC would be stored in the TMP, judging buy the info posted buy Daz Microsoft really trust's that TMP. There is no reason that a SLIC has to be stored in the ACPI tables. This makes sense from a user experience stand point because going into the BIOS every time someone wants to boot another operating system will piss people off and alienate customers. I know if I had to find the manual for my laptop and look up which key I had to press to get into the bios I may stop using Windows just out of laziness. So with these assumptions the obvious attack would be TPM cloning/hacking, reverse engineering the TPM and writing UEFI runtime drivers to emulate a TPM or black market TPM's that can be flashed with firmware that could be downloaded. Reverse engineering a TPM would not be a trivial task but any company that managed it would make a lot of money before Microsoft shut them down and would change the playing field from Microsoft vs. poor anonymous hackers fiddling with ACPI tables. to Microsoft vs. a company deliberately and willfully violating the DMCA and then can sue them out of existence, so this approach also makes sense from a strategic standpoint. It does not annoy the customers too much and Microsoft can stomp on anyone that that sells black market TPM's.
OK, no problem. Yes this is all new to us and I take this to reflect my thoughts with the MDL members, actually to have fun talking about. What I want to avoid is that somebody uses one of my post and posts it somewhere as a tweet or something like that. My posts aren't more the truth than others. I am no insider and I have no insider infos at all. I only try to put the things together and to figure what seems probable. But this thread is the most important w8 thread (to me). It sure will become interesting again to read here what all has been posted after w8 has become RTM.
Good and interesting points. Even if a cloned TPM chip were available, not too many would have the ability or willingness to install the chip. Not to mention the possible costs to Joe Public if he borked his mobo installing it.
At mainboards which aren't prepared for OEM_SLP there probably won't be a place for it at all. The effort to create an add on hardware for it would be too much.
I thought a bit about it, and this is where I got. Please tell me if something is wrong, that can correct my way of thinking a bit if it's not 100% ok. Say UEFI loads a signed bootloader, so far so good. That bootloader chainloads an unsigned bootloader. Does UEFI still have the power or right now to stop the unsigned loader from loading? I mean, it trusts the signature, and therefore trusts the signed loader. But if the signed loader chainloads a "malicious" loader and UEFI doesn't complain about it, this can still be a loader that does something. If windows checks the loader's sig, then some driver or the unsigned bootloader itself must trick windows into thinking it was loaded by the signed one. Windows will then check the sig of the signed one and conclude it's all OK. Another posibility is that windows asks UEFI if the loader's cert was valid instead of checking the cert itself. In this case UEFI either returns an ALL OK (which is good), or an INVALID SIG. Then IF it returns invalid, there can be made a driver that replaces the driver windows uses to talk to UEFI, one that always returns ALL OK. But now the problem arises that UEFI will prevent that driver from loading, because it will be an AM driver. There is however a solution to that problem. UEFI can't disable drivers I think! If I write my custom OS and get a key to sign it, how on earth does UEFI knows how to disable my drivers??? I think the OS must ask UEFI "hey UEFI, is this driver ok to load?", and either loads or does something else depending on the answer. Now if that is the case, we're back into file patching cause forcing windows not to ask that can't be done in any other way. BUT whe're forgetting one big thing, no-one knows how OA3.0 works. We know it's 99% sure that windows will go non-genuine if it detects the bootchain is not clean (I mean UEFI disables drivers, the sig of the bootloader doesn't match etc.) but that can't be everything. If that was everything that would mean that windows would be automatically activated on systems where the boot chain is intact, what of course can't be the case cause windows would autoactivate on every machine with UEFI 2.3.1 that has secure boot enabled. So as long as we have no clue about how OA3.0 will work we can't do anything. It's not even sure we need to go through all the hassle of enabling an unsigned "somethingloader" to load, maybe nothing has to be "loaded" at all. Ooooh yes, I've not even spoken about TPM. This makes it all even more complicated.
@B8 OA3.0 is not even signed off I guess. Well, the OA always has been either a string found at a special memory range to be verified, or a complete ACPITable, called SLIC to be found at ACPI namespace and some OEMIDs that has to match at the RSDT / XSDT tables. And a certificate easily installed at tokens.dat via command plus the serial. A loader is used to patch the IDs and to add the SLIC by following the RSDP-->RSDT /XSDT, or to relocate the RSDP which then allows to relocate the entire acpi tables. What if they use simply a piece of code / data to be verified at the UEFI image itself? Alternatively stored at the TPM chip. Simply sign that area / placeholder at the UEFI image. You would need to alter the UEFI image and it becomes invalid. Also any loader that loads 'activation code' will be detected to be unsigned. We should not forget OA should remain to be easy to license machines for the OEMs. Also I guess OA3.0 will remain a offline activation method.
Okay, so the TPM is required for the "measured boot" part of "trusted boot", good point. What I believe it is that MS calls "trusted boot" is a Windows OS loader that provides a log of all boot-related drivers/executables in the TPM in the case of measured boot, the loading of ELAM drivers, and giving them control about whether other drivers may be prevented from being loaded. With secure boot disabled, the OS loader will still be able do its trusted boot thing because it's not a UEFI implementation, but it will be possible to use a different OS loader or to modify it. UEFI secure boot can't know whatever it's executing actually does or whether it's even "secure", only if it's allowed to be executed or not. These are two different implementations, and they should be considered as two separate parts of the boot process. ELAM is also a third-party component, so we'll have to see if it's even going to be present on OEM systems.
That's the reason why I think secure boot must be enabled as a part of OA. UEFI secure boot only allows to run signed bootloaders. It simply could skip the unsigned bootboader and jump to the w8 bootloader. After executing it and the OS loads, the UEFI secure boot protocol will be told that its job is finished.
If only McAfee didn't suck... I don't look forward to any hardware solution (or pseudo hardware) that is built on anything related to McAfee...
Agreed. I can't count the number of times I've rescued people from McAfee's failings as related to computer security. But, then, many might say the same about AVG, which I really like.
WDP has reg entries for ELAM. In group policy editor, theres option/placeholder to specify whether elam allows good/bad/unknown drivers. How would that fit into the scheme of things?
Good point. How many times have you installed a piece of software and had Win 7 display a message saying the publisher of the driver could not be verified. ELAM would have to account for that. Surely that would leave a loop hole of some variety ?
The FSF is spreading some FUD. Their concern might be real, but surely some manufacturers will make UEFI with the option of disabling Secure Boot. One might wonder more why they and some other Linux-companies, like Red Hat, are not a member of the UEFI Forum. If even one of them would be member, then they would have more influence on the descisions made by the UEFI Forum.