unicorn-for-efi icon indicating copy to clipboard operation
unicorn-for-efi copied to clipboard

Published 20 hours ago • verified publisher icon intel

A few questions regarding the design

Open wtdcode opened this issue 1 year ago • 2 comments

Hello!

I'm the maintainer from the Unicorn Engine and find this repo accidentally. I can see a few interesting designs & implementations here, and I'm happy you also plan to merge them upstream by following our convention. I have a few questions to discuss here:

  • https://github.com/intel/unicorn-for-efi/commit/9fab8970291471c4e9f4c0974005070429689bd4

This commit enables Unicorn to build in EFI environment. I'm totally new to EFI development and may I know if it's possible to do this with cmake? I think we want a single build system to handle everything.

  • https://github.com/intel/unicorn-for-efi/commit/a381c075469c7eac4603ee57ef298046a1dbd745

If I understand it correctly, this API tricks tcg to call any given native code. Could you illustrate its usage and motivation?

btw, is it related to https://github.com/unicorn-engine/unicorn/pull/1839 ?

  • https://github.com/intel/unicorn-for-efi/commit/eb947357e894b311ac2cc8bcd7abd5bb5f60674e

Why do you need to hook for "hooks"?

  • LTO

I see many commits are related to LTO, why LTO is desired with EFI?

Thanks for your efforts and patience!

wtdcode avatar Apr 12 '24 05:04 wtdcode

Hello!

  1. TianoCore EFI has its own build system, which is used to build all the drivers/apps and mold them into a "firmware image". It takes care of dealing with dependencies (e.g. Libs.. https://github.com/intel/unicorn-for-efi/blob/main/efi/UnicornEngineLib.inf#L80). While it's possible to build with Tiano headers outside of this build environment - https://github.com/vmware/esx-boot is a good example), this won't allow you to build things that depend on components built by the TianoCore build environment. And even if you built something (e.g. an ar archive), later consumption of that within the Tiano environment would be extra painful. https://github.com/intel/MultiArchUefiPkg is the current known user of unicorn-for-efi.

  2. https://github.com/intel/MultiArchUefiPkg was the original motivator. Emulated x86 driver code needs to be able to call native services. But the good news is that this functionality cannot be used by MultiArchUefiPkg, because UC is not really reentrant (emulated -> native -> emulated causes corruption in the library). So, this change would not be upstreamed.

The notdirty_write fix refers to https://github.com/intel/unicorn-for-efi/commit/6be64eb2d3a30095782d55daac951ef7cb59dd37

  1. This was just code cleanup I've done as part of trying to understand the UC code. The use of a global (hook_insert), I saw as being extra ugly so I refactored the code, producing uc_hook_add_first. See the call-site for uc_hook_add_first in uc.c. It probably doesn't need to be exported outside of the UC lib, though. It also doesn't need to be upstreamed and the cleanup was done as part of my own separate efforts around improving reentrance.

  2. LTO is desired to produce smaller binaries. Small binaries are desired because MultiArchUefiPkg would get embedded in flash rom images.

andreiw avatar May 03 '24 17:05 andreiw

Thanks for the detailed answers! I will also look into how to port these changes upstream.

wtdcode avatar May 07 '24 04:05 wtdcode