Jump to content











Photo
* * * * * 1 votes

Boot into 3rd-party EFI application via BCD?

efi uefi chainloader grub2 bcd bcdedit

  • Please log in to reply
53 replies to this topic

#51 Wonko the Insane

Wonko the Insane

    Frequent Member

  • Advanced user
  • 426 posts
  • Location:The Inside of the Asylum (gate is wide open)
  • Interests:That's for me to know and you to not find out.
  •  
    United States

Posted A week ago

If you're such a computer guru, as your name implies, then maybe you should answer your own question.



#52 Computer Guru

Computer Guru

    Newbie

  • Members
  • 17 posts
  •  
    United States

Posted A week ago

If you're such a computer guru, as your name implies, then maybe you should answer your own question.

 

Sorry, did I say something to offend you? Anyway, the current question was raised by mihi; if you have nothing to contribute to the topic at hand, perhaps it is best to leave this discussion for those looking to contribute?



#53 Computer Guru

Computer Guru

    Newbie

  • Members
  • 17 posts
  •  
    United States

Posted A week ago



Sorry for hijacking this old thread, but I'd like to shed some light about what works and what does not (and ask if you have any ideas to improve it).

 

....

 

 

In case anyone has any more information, please share :-)

 

mihi

 

Hello @mihi! I had quite forgotten about this thread; it's been many years! I never did go down the route of launching 3rd party EFI applications via BCD, I just supplanted bootmgr entirely.

 

I think your problem stems from the fact that you're running a BOOT_APPLICATION. If you consider for a moment how the boot manager is working, it has exclusive control over the hardware (in many ways, it is the OS at that point). BOOT_APPLICATION is a Microsoft-specific subsystem used to run code at boot-time, but that code doesn't need to re-initialize the hardware, it can use the initialization already carried out by the bootloader. I presume since BOOTMGR didn't initialize/isn't using the serial console, you can use it OK (does it work if you have serial console debugging enabled?) but it has exclusive access to the video output and hasn't handed that off to you.

 

As I mentioned before, winload.efi is of subsystem type 0x10 (for which I cannot find a friendly name at the moment) - whereas BOOT_APPLICATION (0x6) actually predates all the EFI business entirely. The behavior of bootmgr when launching each of these different types differs, and I don't think it's possible to hand off control of the hardware to a BOOT_APPLICATION.

 

Try compiling as /SUBSYSTEM:0x10 or /SUBSYSTEM:16 and see if that is even allowed?

 

The only way I know of to run an EFI somewhat within the framework of the BCD/BOOTMGR is to load your application instead of bootmgr, which bcdedit can do

 

bcdedit /set {bootmgr} path /path/to/your/efi/file

 

But that's not really worth much. You can use that to install GRUB2 as the default system bootloader by specifying the path to grub.efi there, but it's not going to get Windows to give you a nice dual-boot menu between multiple EFI applications.



#54 mihi

mihi

    Newbie

  • Members
  • 22 posts
  •  
    Germany

Posted A week ago

Hello @ComputerGuru,
 
 
Thank you very much for your reply.
 
 

I think your problem stems from the fact that you're running a BOOT_APPLICATION. If you consider for a moment how the boot manager is working, it has exclusive control over the hardware (in many ways, it is the OS at that point). BOOT_APPLICATION is a Microsoft-specific subsystem used to run code at boot-time, but that code doesn't need to re-initialize the hardware, it can use the initialization already carried out by the bootloader. I presume since BOOTMGR didn't initialize/isn't using the serial console, you can use it OK (does it work if you have serial console debugging enabled?) but it has exclusive access to the video output and hasn't handed that off to you.


Yes, I'm aware that what I am doing is unsupported (and subject to break in the next Windows 10 Insider Build even), but I still tried to ask here, since it seems more people here are trying that kind of stuff, and perhaps somebody has reverse engineered already how the graphics initialization is passed down to the boot application (at least in the offsets that are passed in that structure I did not find any framebuffer offset or similar) or how to uninitialize the hardware. (I know it is possible since you can load the bootmanager from e. g. GRUB or EFI shell and then return back to it, and the graphics works again, so the information on how to get back is somewhere, unlike old Linux kernels which overwrote BIOS information in RAM so there was no way to get it back except reboot).
 
Yes, serial console even works if I enabled serial debugging for BCDEDIT (then I can see the serial output in Windbg, similar to what I see when invoking memtest.efi). And ConIn also works and I'm pretty sure that the boot manager also initialized it before, so I assume it does something special with graphics (and not rely on the standard EFI_GOP graphics) while it relies on EFI services for serial console and input.
 

As I mentioned before, winload.efi is of subsystem type 0x10 (for which I cannot find a friendly name at the moment) - whereas BOOT_APPLICATION (0x6) actually predates all the EFI business entirely.


According to https://msdn.microso...339(VS.85).aspx, 16 is IMAGE_SUBSYSTEM_WINDOWS_BOOT_APPLICATION, and when I compile 64-bit with /SUBSYSTEM:BOOT_APPLICATION, I get 16 in dependency walker (the same as winload.efi was), so at least the subsystem type was correct.

 

The behavior of bootmgr when launching each of these different types differs, and I don't think it's possible to hand off control of the hardware to a BOOT_APPLICATION.
 
Try compiling as /SUBSYSTEM:0x10 or /SUBSYSTEM:16 and see if that is even allowed?


I think with /SUBSYSTEM:BOOT_APPLICATION (in 64-bit architecture) I'm fine.
 

The only way I know of to run an EFI somewhat within the framework of the BCD/BOOTMGR is to load your application instead of bootmgr, which bcdedit can do
 
bcdedit /set {bootmgr} path /path/to/your/efi/file
 
But that's not really worth much. You can use that to install GRUB2 as the default system bootloader by specifying the path to grub.efi there, but it's not going to get Windows to give you a nice dual-boot menu between multiple EFI applications.


In my scenario, the Windows boot manager resides on a USB key anyway (/efi/boot/bootx64.efi) and not in firmware variables, so I could achieve the same by just overwriting that file. :)

 

Best regards,

 

mihi







Also tagged with one or more of these keywords: efi, uefi, chainloader, grub2, bcd, bcdedit

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users