public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Rebecca Cran via groups.io" <rebecca=os.amperecomputing.com@groups.io>
To: devel@edk2.groups.io, andrei.warkentin@intel.com,
	Ard Biesheuvel <ardb@kernel.org>,
	Rebecca Cran <rebecca@bsdio.com>
Cc: "quic_llindhol@quicinc.com" <quic_llindhol@quicinc.com>,
	"Kinney, Michael D" <michael.d.kinney@intel.com>
Subject: Re: [edk2-devel] [PATCH] Emulator/X86EmulatorDxe: Replace with MultiArchUefiPkg build
Date: Fri, 6 Sep 2024 08:22:37 -0600	[thread overview]
Message-ID: <1b111e7f-7153-474b-8656-53ce289abb2a@os.amperecomputing.com> (raw)
In-Reply-To: <PH8PR11MB68561EE1BBECD9806B37944D839E2@PH8PR11MB6856.namprd11.prod.outlook.com>

Hi Andrei,


I've been talking to a few people about X86EmulatorPkg and their 
experience with it hasn't been positive: apparently there are lots of 
cases where it's failed to work (i.e. caused crashes) which is why it's 
not been more widely used.

Since suggesting they try MultiArchUefiPkg they've said it's working 
much better, and in fact some people have proceeded with enabling it in 
their firmware.


I'm a bit confused about the licensing of MultiArchUefiPkg given the 
license file says it's LGPL while it uses the GPL-licensed Unicorn library.

Does that mean the overall licensing for it will be GPL?


-- 

Rebecca


On 9/5/2024 11:32 PM, Andrei Warkentin via groups.io wrote:
> Hey folks,
>
> Sorry for the late response.
>
> - My suggestion is not to replace, but augment. MultiArchUefiPkg is fairly new, not particularly well adopted, surely with some flaws lurking here and there and for certain with no guarantee of fitness or proof that it will work 100% or 100% better than X86EmulatorPkg for every single use case of X86EmulatorPkg in the wild. X86EmulatorPkg has been around for a lot longer than its rewrite, and I think the people actively using X86EmulatorPkg should continue to have the option to continue using it.
>
> - Unicorn has been a blessing and a curse, although abstracting the emulator with an API seems like a winner. An API-compatible emulator or JIT is something I've been thinking about, but not really doing anything about it for the moment. So yes, actual licensing of binaries is cursed.
>
> - All memory but the zero page is visible to the emulator. See CpuNullReadCb/CpuNullWriteCb. See also TestNullDeref in Application/EmulatorTest. I don't remember if I added the behavior because this is what the original did, or because I actively tripped on the NULL accesses from some x86 code I was testing...
>
> A
>
>> -----Original Message-----
>> From: Ard Biesheuvel <ardb@kernel.org>
>> Sent: Sunday, September 1, 2024 3:05 AM
>> To: Rebecca Cran <rebecca@bsdio.com>; Warkentin, Andrei
>> <andrei.warkentin@intel.com>
>> Cc: devel@edk2.groups.io; quic_llindhol@quicinc.com; Kinney, Michael D
>> <michael.d.kinney@intel.com>
>> Subject: Re: [PATCH] Emulator/X86EmulatorDxe: Replace with
>> MultiArchUefiPkg build
>>
>> Hi Rebecca,
>>
>> On Sun, 1 Sept 2024 at 00:33, Rebecca Cran <rebecca@bsdio.com> wrote:
>>> Replace the old X86EmulatorDxe with one built from
>>> https://github.com/intel/MultiArchUefiPkg. This is a much more modern,
>>> recent implementation that's more reliable and is actively maintained.
>>>
>>> Add driver binaries for both AArch64 and RISCV64, along with the
>>> LoadOpRom application.
>>>
>>> Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
>>> ---
>>>   Emulator/X86EmulatorDxe/AArch64/EmulatorDxe.depex | Bin 0 -> 54
>> bytes
>>>   Emulator/X86EmulatorDxe/AArch64/EmulatorDxe.efi   | Bin 0 -> 573440
>> bytes
>>>   Emulator/X86EmulatorDxe/AArch64/LoadOpRom.efi     | Bin 0 -> 28672
>> bytes
>>>   Emulator/X86EmulatorDxe/README.md                 |  11 +++++++----
>>>   Emulator/X86EmulatorDxe/RISCV64/EmulatorDxe.depex | Bin 0 -> 54
>> bytes
>>>   Emulator/X86EmulatorDxe/RISCV64/EmulatorDxe.efi   | Bin 0 -> 561216
>> bytes
>>>   Emulator/X86EmulatorDxe/RISCV64/LoadOpRom.efi     | Bin 0 -> 30848
>> bytes
>>>   Emulator/X86EmulatorDxe/X86EmulatorDxe.depex      | Bin 36 -> 0 bytes
>>>   Emulator/X86EmulatorDxe/X86EmulatorDxe.efi        | Bin 913408 -> 0
>> bytes
>>>   Emulator/X86EmulatorDxe/X86EmulatorDxe.inf        |  10 +++++++---
>>>   10 files changed, 14 insertions(+), 7 deletions(-)
>>>
>> Happy to see that this work has been absorbed into a project that will
>> improve and maintain it going forward.
>>
>> However, according to the github.com repo Readme of
>> MultiArchUefiCpuPkg, these binaries include statically linked UniCorn builds,
>> which are a mix of LPGL and GPLv2, so you will need to update the LICENSE
>> file accordingly.
>>
>> Also, glancing over the code, it seems like it removes the NULL pointer
>> dereference handling that the original X86EmulatorPkg has - this code was
>> added for a purpose, as some Nvidia option ROMs will happily dereference
>> NULL pointers, which happens to work on most older
>> X64 firmware because page 0x0 happens to be mapped. Perhaps Andrei can
>> comment on this point?
>
> 
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#120521): https://edk2.groups.io/g/devel/message/120521
Mute This Topic: https://groups.io/mt/108202804/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



  reply	other threads:[~2024-09-06 14:22 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-31 22:32 [edk2-devel] [PATCH] Emulator/X86EmulatorDxe: Replace with MultiArchUefiPkg build Rebecca Cran
2024-09-01  8:05 ` Ard Biesheuvel via groups.io
2024-09-02  2:49   ` Chao Li
2024-09-06  5:41     ` Andrei Warkentin
2024-09-06  8:44       ` Chao Li
2024-09-06  5:32   ` Andrei Warkentin
2024-09-06 14:22     ` Rebecca Cran via groups.io [this message]
2024-09-06 15:25       ` Ard Biesheuvel via groups.io
2024-09-06 15:39         ` Rebecca Cran via groups.io
2024-09-02 16:45 ` Michael D Kinney
2024-09-02 21:21   ` Rebecca Cran

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1b111e7f-7153-474b-8656-53ce289abb2a@os.amperecomputing.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox