why should intelligence people without nativity accept a MASTER-SPY-TOOL AGAINST YOUR SELF in there own hardware?
its the same with FLAME trojan with official microsoft signature if UEFI-Secureboot for linux do have a microsoft key microsoft just give away the KEY to the CIA and the CIA write FLAME2.0 to attack your linux system over the MASTER-KEY in UEFI-Secureboot!
and i'm "german" this means the CIA are allowed to attack ME just because i'm not US-Citizen!
only naive stupid people sell there soul to he devil and then they think they come to heaven instead of hell.
Someone having the UEFI boot key doesn't make the system any less secure than it is RIGHT NOW without ANY keys.
Even if the CIA got their hands on the MS key, and for that matter, even if the key got leaked out to the public, it wouldn't be of any use since what the key is protecting is just MS's ability to block competition!
and if you use "coreboot" there is no master-spy back-door in it no one can tunneling your security system in linux by BIOS or UEFI programms running outside of the Linux system!
no security hole is needet becaue UEFI do have full access to your network card!
Whoa, what a double standards! Unless they would state than it's possible to boot your own, completely open-sourced firmware on this ARM CPU, it have to be considered as just some kind of backdoor and/or anti-user countermeasure. And I seriously doubt they will allow user to enter secured ARM mode with his code."more secure computing experiences"
So basically you're forced to trust some unknown binary firmware just because... because has AMD decided so.
Feel free to trust your security to anyone who forces you to do so.
But when doing so, remember: "They who can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin
1) In UEFI it's possible that some drivers/services would run together with OS. If they're binary-only there is no good way to check if they don't have undesired "(mis)features". Bios has been better in this regard as all 32/64 bit OSes simply disregard it and do not use it to deal with hardware. So it mostly can't have control most of time. Sure, there are some nasty tricks like "ring -1" aka SMM-mode, but it's hard to (ab)use in arbitrary way for most attackers (though not completely impossible) and for example Linux goes Kernel Panic if SMM handler takes too long. But UEFI is worse than that in this regard. It can do all this the same abusive ways + can run potentially unwanted drivers/services together with OS. As an extra bonus it will restrict us with "secure" boot where you're forced to "trust" to someone by hardware. I have to admit that if pushing this approach a bit further, the best hardware to enforce trust is a gun. It's far more convincing than any backdoored code/hardware.
2) Intel now haves their very own small secondary CPU in recent chip sets. It's required for vPro/AMT, to control FAN speeds and do advanced power management in notebooks, etc. It's management firmware is binary-only. CPU instruction set is not documented. It's mentioned in datasheets but no exact details given for this part of chipset, unlike it's x86 counterpart. It haves network access through chipset's ethernet connection even when main CPU is completely powered off. You also can't firewall this little cpu for same reasons. And this small CPU could mess with memory of main CPU if desired. It also what performs wake on lan and remote management on AMT/vPro machines. So it can do much more than that - in principle, you can overtake remote computer which is "looks like switched off". And who knows what lurks in firmware internals? Are there any valid reasons to trust to this code? It would not even shut down if you disable it in bios setup. Because at least some very basic things like fan speed controls are also handled by this CPU. So it just tells as if it switched off. But in fact it is not. It only shut downs official part of remote management "API", etc. But you can't easily check if there is any unwanted features left. So if someone would want to place a backdoor - it's a really nice place. This CPU firmware stored in same BIOS IC as all other BIOS parts but chipset ensures this code is unavailable to x86 CPU. So you can't even detect backdoor from x86 CPU, should be there any. So you would have quite hard times when just trying to learn "what this thing really does".
3) Now AMD comes to this road. And I guess their approach will be just as nasty and potentially troublemaking. I seriously doubt this ARM core would run open firmware which you can actually check for absence of unwanted misfeatures. I seriously doubt they will allow user to enter secured ARM mode and check which code is actually executed here. So it would be nice place to store backdoors and unwanted misfeatures once more.
Btw, DRM restrictions are kind of backdoor/unwanted misfeatures too. In absolutely best case it does nothing. If you're less lucky, it f...s you up.
Last edited by 0xBADCODE; 06-15-2012 at 12:31 PM.