I'm currently learning more about UEFI (havn't used it before UDOO X86). UEFI stores many important variables in NVRAM (e.g. relating to booting order) and at least some motherboards can be permanently bricked if these variables are modified in a wrong way. A quote from slashdot discussion: "The problem is UEFI is so complex that many manufacturers make a lousy implementation with a lot of copy-paste code ... Their QA process seems to be something like, "Does Windows boot? If it does, then it must be ok."" Now since this seems to describe UDOO X86 developers (they didn't even bother testing if Arduino side works as advertised), I wonder if UDOO X86 is one of those systems which can't handle broken NVRAM variables. So in short: Is there any way to fix broken NVRAM variables, e.g. to restore them to a known working stage?
this is the flaw in uefi bios implementation: the firmware compiler/signature maker have to check theses value at compile time (but can fail), then the bios does it too, using a firmware function. if you insert a malicious (or use a boged one) firmware function in there, you can make cpu run shellcode inserted at boot time even when OS runs in "protected mode", if it stills exist
