On Wed, Aug 21, 2013 at 03:47:21AM -0000, Cory Smelosky wrote: I'd love to hear what you find anyway, if I could apply it to the stand-alone (self-booting) version of Ersatz-11. So that is, sort of, related to classic computing. I recently got my first UEFI-enabled motherboard but have given up on it for now for other reasons -- it's one of the few ISA mobos still available (iEi IMBA-G412ISA-R20) but it has no FDC and the PnP BIOS uses IRQ6 for the onboard PCI stuff and doesn't include it in the setup menus to reserve for ISA, so you can't add a standard FDC either (iEi says they'll fix it for $500 which would be very reasonable if I were buying 10 mobos and if it weren't their bug in the first place -- well it beats being told to drop dead which was what I expected). But anyway I don't know enough about secure booting to know what I'd need to do even *if* MS is serious that $99 makes all your problems go away. They couldn't afford to seriously review my code for even 10x that price so I don't believe it. But if they care only about accountability then that's different... John Wilson D Bit

On 8/20/2013 8:49 PM, Cory Smelosky wrote: Secure computing on intel starts in the hardware. You have to have the correct signature to run out of reset. There is no horse out of the barn, so you can probe the memory. However they go out of the way to have secure signed blocks that come from whatever area necessary into internal registers which are decrypted to have correct execution privilege masks for any change that requires access. You have a number of execution states in the intel system, and some may or may not have secured enabled. For instance the normal problem execution state (including system privilege execution) would of course be secured, but perhaps the SM state that is executed might not be. Also of these states, probe mode is like a normal citizen of this space and at one time did not have to have security. My understanding is now that you probably will have to even have keys in probe mode to do much but enter probe mode and look at some few MSR's and memory. I would imagine you can run and stop the processor but not much else w/o the correct keys. You know they have to have keys that are in the code you boot in, and of course reverse engineering would show the locations that the key blocks come from as you debug or disassemble. But these blocks are securely locked with code that will not allow you to figure them out. The controversy is that Intel essentially handed the bios signing to microsoft. If you sub in your own bios or efi, you will have your own set of secure keys and can run anything you like, but not a MS signed os. I don't know the reason for this, since the idea behind uefi was that you could run different bios type layers or just have your OS boot and run on top of uefi (this would mean there would be some machine specific layers w/o the bios layers to provide apis, but still doable). I suspect they screwed something up and still want to obsucure some bios details so they had to give out control of that and the control of the secure execution over to their biggest client (or in the eyes of MS they are the biggest).

On Thu, 23 Aug 2013, Liam Proven wrote: Errrr, yeah. I confused the API with the ARM build. ;) I wonder which ARM devices. I'm curious as to if MSDN provides Windows RT...none of my ARM devices support UEFI. ;) Thus it needing to be circumvented to run a different OS. -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects