Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A few questions regarding the design #2

Open
andreiw opened this issue Jan 26, 2025 · 1 comment
Open

A few questions regarding the design #2

andreiw opened this issue Jan 26, 2025 · 1 comment

Comments

@andreiw
Copy link
Owner

andreiw commented Jan 26, 2025

@wtdcode said (in intel#7):

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:

9fab897
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.

a381c07
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 unicorn-engine/unicorn#1839 ?

eb94735
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!

@andreiw
Copy link
Owner Author

andreiw commented Jan 26, 2025

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/andreiw/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/andreiw/MultiArchUefiPkg is the current known user of unicorn-for-efi.

  2. https://github.com/andreiw/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 6be64eb

  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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant