public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
* Is Xcode5ExceptionHandlerAsm.nasm still needed?
@ 2023-03-30 10:16 Ni, Ray
  2023-03-30 10:48 ` [edk2-devel] " Ard Biesheuvel
  2023-03-30 15:30 ` Michael D Kinney
  0 siblings, 2 replies; 10+ messages in thread
From: Ni, Ray @ 2023-03-30 10:16 UTC (permalink / raw)
  To: Andrew Fish; +Cc: Kinney, Michael D, devel@edk2.groups.io, Liu, Zhiguang

[-- Attachment #1: Type: text/plain, Size: 668 bytes --]

Andrew,
In UefiCpuPkg\Library\CpuExceptionHandlerLib\X64\, there are two nasm files: ExceptionHandlerAsm.nasm and the other XCODE version.

The major diff between the two is the second operand in "mov rax, ASM_PFX(CommonInterruptEntry)" is patched at runtime by code, instead of relying on linker/loader to fix it.
Can I know more background why it's needed for XCODE?

Given Apple is switching away from X86 CPU, is the XCODE version still needed?

+ Mike because I found another commit by you for bug: 565 - Fix X64 XCODE5/NASM compatibility issue in UefiCpuPkg MpInitLib (tianocore.org)<https://bugzilla.tianocore.org/show_bug.cgi?id=565>.

Thanks,
Ray

[-- Attachment #2: Type: text/html, Size: 4225 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [edk2-devel] Is Xcode5ExceptionHandlerAsm.nasm still needed?
  2023-03-30 10:16 Is Xcode5ExceptionHandlerAsm.nasm still needed? Ni, Ray
@ 2023-03-30 10:48 ` Ard Biesheuvel
  2023-03-30 11:47   ` Ard Biesheuvel
  2023-03-30 15:30 ` Michael D Kinney
  1 sibling, 1 reply; 10+ messages in thread
From: Ard Biesheuvel @ 2023-03-30 10:48 UTC (permalink / raw)
  To: devel, ray.ni; +Cc: Andrew Fish, Kinney, Michael D, Liu, Zhiguang

On Thu, 30 Mar 2023 at 12:16, Ni, Ray <ray.ni@intel.com> wrote:
>
> Andrew,
>
> In UefiCpuPkg\Library\CpuExceptionHandlerLib\X64\, there are two nasm files: ExceptionHandlerAsm.nasm and the other XCODE version.
>
>
>
> The major diff between the two is the second operand in “mov rax, ASM_PFX(CommonInterruptEntry)” is patched at runtime by code, instead of relying on linker/loader to fix it.
>
> Can I know more background why it’s needed for XCODE?
>
>
>
> Given Apple is switching away from X86 CPU, is the XCODE version still needed?
>
>
>
> + Mike because I found another commit by you for bug: 565 – Fix X64 XCODE5/NASM compatibility issue in UefiCpuPkg MpInitLib (tianocore.org).
>
>


Yes, we still need it, also for non-Xcode clang + lld

The problem is that the little code templates use absolute addressing
to refer to the jump targets. This is necessary because these
templates are copied into the vector table, and so they are moved
independently from the code they refer to, and so relative addressing
is not an option here.

One thing I haven't tried yet is to emit the template code into .data
instead of .text, which /should/ be fine given that the template code
is never executed directly, only the copied versions are executed.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [edk2-devel] Is Xcode5ExceptionHandlerAsm.nasm still needed?
  2023-03-30 10:48 ` [edk2-devel] " Ard Biesheuvel
@ 2023-03-30 11:47   ` Ard Biesheuvel
  2023-03-30 14:25     ` Ni, Ray
  0 siblings, 1 reply; 10+ messages in thread
From: Ard Biesheuvel @ 2023-03-30 11:47 UTC (permalink / raw)
  To: devel, ray.ni, Rebecca Cran; +Cc: Andrew Fish, Kinney, Michael D, Liu, Zhiguang

(cc Rebecca)

On Thu, 30 Mar 2023 at 12:48, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Thu, 30 Mar 2023 at 12:16, Ni, Ray <ray.ni@intel.com> wrote:
> >
> > Andrew,
> >
> > In UefiCpuPkg\Library\CpuExceptionHandlerLib\X64\, there are two nasm files: ExceptionHandlerAsm.nasm and the other XCODE version.
> >
> >
> >
> > The major diff between the two is the second operand in “mov rax, ASM_PFX(CommonInterruptEntry)” is patched at runtime by code, instead of relying on linker/loader to fix it.
> >
> > Can I know more background why it’s needed for XCODE?
> >
> >
> >
> > Given Apple is switching away from X86 CPU, is the XCODE version still needed?
> >
> >
> >
> > + Mike because I found another commit by you for bug: 565 – Fix X64 XCODE5/NASM compatibility issue in UefiCpuPkg MpInitLib (tianocore.org).
> >
> >
>
>
> Yes, we still need it, also for non-Xcode clang + lld
>
> The problem is that the little code templates use absolute addressing
> to refer to the jump targets. This is necessary because these
> templates are copied into the vector table, and so they are moved
> independently from the code they refer to, and so relative addressing
> is not an option here.
>
> One thing I haven't tried yet is to emit the template code into .data
> instead of .text, which /should/ be fine given that the template code
> is never executed directly, only the copied versions are executed.

I had a quick go at this, and the change below appears to work: it
moves the template code into .data, and changes the absolute
references to relative ones in the code that executes from where it
gets loaded.

I'm not sure how to test this, though.



--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.nasm
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.nasm
@@ -27,7 +27,6 @@ extern ASM_PFX(CommonExceptionHandler)
 SECTION .data

 DEFAULT REL
-SECTION .text

 ALIGN   8

@@ -51,6 +50,9 @@ HookAfterStubHeaderBegin:
     push    rax
     mov     rax, HookAfterStubHeaderEnd
     jmp     rax
+
+SECTION .text
+
 HookAfterStubHeaderEnd:
     mov     rax, rsp
     and     sp,  0xfff0        ; make sure 16-byte aligned for
exception context
@@ -276,8 +278,7 @@ DrFinish:
     ; and make sure RSP is 16-byte aligned
     ;
     sub     rsp, 4 * 8 + 8
-    mov     rax, ASM_PFX(CommonExceptionHandler)
-    call    rax
+    call    ASM_PFX(CommonExceptionHandler)
     add     rsp, 4 * 8 + 8

     cli
@@ -384,10 +385,10 @@ DoIret:
 ; comments here for definition of address map
 global ASM_PFX(AsmGetTemplateAddressMap)
 ASM_PFX(AsmGetTemplateAddressMap):
-    mov     rax, AsmIdtVectorBegin
+    lea     rax, AsmIdtVectorBegin
     mov     qword [rcx], rax
     mov     qword [rcx + 0x8],  (AsmIdtVectorEnd - AsmIdtVectorBegin) / 32
-    mov     rax, HookAfterStubHeaderBegin
+    lea     rax, HookAfterStubHeaderBegin
     mov     qword [rcx + 0x10], rax
     ret

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [edk2-devel] Is Xcode5ExceptionHandlerAsm.nasm still needed?
  2023-03-30 11:47   ` Ard Biesheuvel
@ 2023-03-30 14:25     ` Ni, Ray
  2023-03-30 15:04       ` Ard Biesheuvel
  0 siblings, 1 reply; 10+ messages in thread
From: Ni, Ray @ 2023-03-30 14:25 UTC (permalink / raw)
  To: Ard Biesheuvel, devel@edk2.groups.io, Rebecca Cran
  Cc: Andrew Fish, Kinney, Michael D, Liu, Zhiguang

[-- Attachment #1: Type: text/plain, Size: 3557 bytes --]

I am afraid they are not template code.
That means if nx is set for data section, they can not be executed.


thanks,
ray
________________________________
From: Ard Biesheuvel <ardb@kernel.org>
Sent: Thursday, March 30, 2023 7:47:03 PM
To: devel@edk2.groups.io <devel@edk2.groups.io>; Ni, Ray <ray.ni@intel.com>; Rebecca Cran <rebecca@bsdio.com>
Cc: Andrew Fish <afish@apple.com>; Kinney, Michael D <michael.d.kinney@intel.com>; Liu, Zhiguang <zhiguang.liu@intel.com>
Subject: Re: [edk2-devel] Is Xcode5ExceptionHandlerAsm.nasm still needed?

(cc Rebecca)

On Thu, 30 Mar 2023 at 12:48, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Thu, 30 Mar 2023 at 12:16, Ni, Ray <ray.ni@intel.com> wrote:
> >
> > Andrew,
> >
> > In UefiCpuPkg\Library\CpuExceptionHandlerLib\X64\, there are two nasm files: ExceptionHandlerAsm.nasm and the other XCODE version.
> >
> >
> >
> > The major diff between the two is the second operand in “mov rax, ASM_PFX(CommonInterruptEntry)” is patched at runtime by code, instead of relying on linker/loader to fix it.
> >
> > Can I know more background why it’s needed for XCODE?
> >
> >
> >
> > Given Apple is switching away from X86 CPU, is the XCODE version still needed?
> >
> >
> >
> > + Mike because I found another commit by you for bug: 565 – Fix X64 XCODE5/NASM compatibility issue in UefiCpuPkg MpInitLib (tianocore.org).
> >
> >
>
>
> Yes, we still need it, also for non-Xcode clang + lld
>
> The problem is that the little code templates use absolute addressing
> to refer to the jump targets. This is necessary because these
> templates are copied into the vector table, and so they are moved
> independently from the code they refer to, and so relative addressing
> is not an option here.
>
> One thing I haven't tried yet is to emit the template code into .data
> instead of .text, which /should/ be fine given that the template code
> is never executed directly, only the copied versions are executed.

I had a quick go at this, and the change below appears to work: it
moves the template code into .data, and changes the absolute
references to relative ones in the code that executes from where it
gets loaded.

I'm not sure how to test this, though.



--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.nasm
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.nasm
@@ -27,7 +27,6 @@ extern ASM_PFX(CommonExceptionHandler)
 SECTION .data

 DEFAULT REL
-SECTION .text

 ALIGN   8

@@ -51,6 +50,9 @@ HookAfterStubHeaderBegin:
     push    rax
     mov     rax, HookAfterStubHeaderEnd
     jmp     rax
+
+SECTION .text
+
 HookAfterStubHeaderEnd:
     mov     rax, rsp
     and     sp,  0xfff0        ; make sure 16-byte aligned for
exception context
@@ -276,8 +278,7 @@ DrFinish:
     ; and make sure RSP is 16-byte aligned
     ;
     sub     rsp, 4 * 8 + 8
-    mov     rax, ASM_PFX(CommonExceptionHandler)
-    call    rax
+    call    ASM_PFX(CommonExceptionHandler)
     add     rsp, 4 * 8 + 8

     cli
@@ -384,10 +385,10 @@ DoIret:
 ; comments here for definition of address map
 global ASM_PFX(AsmGetTemplateAddressMap)
 ASM_PFX(AsmGetTemplateAddressMap):
-    mov     rax, AsmIdtVectorBegin
+    lea     rax, AsmIdtVectorBegin
     mov     qword [rcx], rax
     mov     qword [rcx + 0x8],  (AsmIdtVectorEnd - AsmIdtVectorBegin) / 32
-    mov     rax, HookAfterStubHeaderBegin
+    lea     rax, HookAfterStubHeaderBegin
     mov     qword [rcx + 0x10], rax
     ret

[-- Attachment #2: Type: text/html, Size: 5666 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [edk2-devel] Is Xcode5ExceptionHandlerAsm.nasm still needed?
  2023-03-30 14:25     ` Ni, Ray
@ 2023-03-30 15:04       ` Ard Biesheuvel
  2023-03-30 16:33         ` Ard Biesheuvel
  0 siblings, 1 reply; 10+ messages in thread
From: Ard Biesheuvel @ 2023-03-30 15:04 UTC (permalink / raw)
  To: Ni, Ray
  Cc: devel@edk2.groups.io, Rebecca Cran, Andrew Fish,
	Kinney, Michael D, Liu, Zhiguang

On Thu, 30 Mar 2023 at 16:25, Ni, Ray <ray.ni@intel.com> wrote:
>
> I am afraid they are not template code.
> That means if nx is set for data section, they can not be executed.
>

Currently, we fix up the entries by writing to the .text section at
runtime, so NX seems out of scope in any case.

Someone should check Xcode5, but for LLD, adding  -Wl,-z,notext is
sufficient to work around the error.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Is Xcode5ExceptionHandlerAsm.nasm still needed?
  2023-03-30 10:16 Is Xcode5ExceptionHandlerAsm.nasm still needed? Ni, Ray
  2023-03-30 10:48 ` [edk2-devel] " Ard Biesheuvel
@ 2023-03-30 15:30 ` Michael D Kinney
  1 sibling, 0 replies; 10+ messages in thread
From: Michael D Kinney @ 2023-03-30 15:30 UTC (permalink / raw)
  To: Ni, Ray, Andrew Fish
  Cc: devel@edk2.groups.io, Liu, Zhiguang, Kinney, Michael D

[-- Attachment #1: Type: text/plain, Size: 1466 bytes --]

Hi Ray,

No sure if I recall all the details.  Andrew may know them much better than me.

The code gen for XCODE uses PIE and RIP relative addressing, which does not require the same number/type of relocation fixups.

Whenever there is a need to access a data element at an absolute address and the code is copied to
a new location the RIP relative address will not work.

And if you try to use absolute addressing, you will get an error from XCODE linker for an unsupported fixup type.

Mike

From: Ni, Ray <ray.ni@intel.com>
Sent: Thursday, March 30, 2023 3:16 AM
To: Andrew Fish <afish@apple.com>
Cc: Kinney, Michael D <michael.d.kinney@intel.com>; devel@edk2.groups.io; Liu, Zhiguang <zhiguang.liu@intel.com>
Subject: Is Xcode5ExceptionHandlerAsm.nasm still needed?

Andrew,
In UefiCpuPkg\Library\CpuExceptionHandlerLib\X64\, there are two nasm files: ExceptionHandlerAsm.nasm and the other XCODE version.

The major diff between the two is the second operand in “mov rax, ASM_PFX(CommonInterruptEntry)” is patched at runtime by code, instead of relying on linker/loader to fix it.
Can I know more background why it’s needed for XCODE?

Given Apple is switching away from X86 CPU, is the XCODE version still needed?

+ Mike because I found another commit by you for bug: 565 – Fix X64 XCODE5/NASM compatibility issue in UefiCpuPkg MpInitLib (tianocore.org)<https://bugzilla.tianocore.org/show_bug.cgi?id=565>.

Thanks,
Ray

[-- Attachment #2: Type: text/html, Size: 42038 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [edk2-devel] Is Xcode5ExceptionHandlerAsm.nasm still needed?
  2023-03-30 15:04       ` Ard Biesheuvel
@ 2023-03-30 16:33         ` Ard Biesheuvel
  2023-03-30 16:47           ` Ard Biesheuvel
  2023-03-30 16:54           ` Rebecca Cran
  0 siblings, 2 replies; 10+ messages in thread
From: Ard Biesheuvel @ 2023-03-30 16:33 UTC (permalink / raw)
  To: Ni, Ray
  Cc: devel@edk2.groups.io, Rebecca Cran, Andrew Fish,
	Kinney, Michael D, Liu, Zhiguang

On Thu, 30 Mar 2023 at 17:04, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Thu, 30 Mar 2023 at 16:25, Ni, Ray <ray.ni@intel.com> wrote:
> >
> > I am afraid they are not template code.
> > That means if nx is set for data section, they can not be executed.
> >
>
> Currently, we fix up the entries by writing to the .text section at
> runtime, so NX seems out of scope in any case.
>
> Someone should check Xcode5, but for LLD, adding  -Wl,-z,notext is
> sufficient to work around the error.

As far as I could figure out, '-read_only_relocs suppress' does the
same thing as '-z notext' on the GNU linker, and permits the code to
be built with the absolute relocations in the .text section.

AFAICT, this means we don't need the runtime fixups, nor do we need to
move that code out of .text

i'll respin the series I sent out earlier today with that if I manage
to build a working OVMF.fd with XCODE5

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [edk2-devel] Is Xcode5ExceptionHandlerAsm.nasm still needed?
  2023-03-30 16:33         ` Ard Biesheuvel
@ 2023-03-30 16:47           ` Ard Biesheuvel
  2023-03-30 16:54           ` Rebecca Cran
  1 sibling, 0 replies; 10+ messages in thread
From: Ard Biesheuvel @ 2023-03-30 16:47 UTC (permalink / raw)
  To: Ni, Ray
  Cc: devel@edk2.groups.io, Rebecca Cran, Andrew Fish,
	Kinney, Michael D, Liu, Zhiguang

On Thu, 30 Mar 2023 at 18:33, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Thu, 30 Mar 2023 at 17:04, Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > On Thu, 30 Mar 2023 at 16:25, Ni, Ray <ray.ni@intel.com> wrote:
> > >
> > > I am afraid they are not template code.
> > > That means if nx is set for data section, they can not be executed.
> > >
> >
> > Currently, we fix up the entries by writing to the .text section at
> > runtime, so NX seems out of scope in any case.
> >
> > Someone should check Xcode5, but for LLD, adding  -Wl,-z,notext is
> > sufficient to work around the error.
>
> As far as I could figure out, '-read_only_relocs suppress' does the
> same thing as '-z notext' on the GNU linker, and permits the code to
> be built with the absolute relocations in the .text section.
>
> AFAICT, this means we don't need the runtime fixups, nor do we need to
> move that code out of .text
>
> i'll respin the series I sent out earlier today with that if I manage
> to build a working OVMF.fd with XCODE5

Hmm seems we are already using that for XCODE5.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [edk2-devel] Is Xcode5ExceptionHandlerAsm.nasm still needed?
  2023-03-30 16:33         ` Ard Biesheuvel
  2023-03-30 16:47           ` Ard Biesheuvel
@ 2023-03-30 16:54           ` Rebecca Cran
  2023-03-30 17:03             ` Ard Biesheuvel
  1 sibling, 1 reply; 10+ messages in thread
From: Rebecca Cran @ 2023-03-30 16:54 UTC (permalink / raw)
  To: Ard Biesheuvel, Ni, Ray
  Cc: devel@edk2.groups.io, Andrew Fish, Kinney, Michael D,
	Liu, Zhiguang

On 3/30/23 10:33 AM, Ard Biesheuvel wrote:
> i'll respin the series I sent out earlier today with that if I manage
> to build a working OVMF.fd with XCODE5

Let me know if you'd like any help test building/running anything with 
XCODE5 on an Intel or ARM Mac.

I have both a 2012 era Intel Mac Pro and an M1 MacBook Pro.


-- 
Rebecca Cran


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [edk2-devel] Is Xcode5ExceptionHandlerAsm.nasm still needed?
  2023-03-30 16:54           ` Rebecca Cran
@ 2023-03-30 17:03             ` Ard Biesheuvel
  0 siblings, 0 replies; 10+ messages in thread
From: Ard Biesheuvel @ 2023-03-30 17:03 UTC (permalink / raw)
  To: Rebecca Cran
  Cc: Ni, Ray, devel@edk2.groups.io, Andrew Fish, Kinney, Michael D,
	Liu, Zhiguang

On Thu, 30 Mar 2023 at 18:54, Rebecca Cran <rebecca@bsdio.com> wrote:
>
> On 3/30/23 10:33 AM, Ard Biesheuvel wrote:
> > i'll respin the series I sent out earlier today with that if I manage
> > to build a working OVMF.fd with XCODE5
>
> Let me know if you'd like any help test building/running anything with
> XCODE5 on an Intel or ARM Mac.
>
> I have both a 2012 era Intel Mac Pro and an M1 MacBook Pro.
>

Ah excellent - thanks.

Once I make a bit more progress, I'll cc you [again] on my v2 series,
and I'd appreciate it if you could give that a spin.

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2023-03-30 17:03 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-03-30 10:16 Is Xcode5ExceptionHandlerAsm.nasm still needed? Ni, Ray
2023-03-30 10:48 ` [edk2-devel] " Ard Biesheuvel
2023-03-30 11:47   ` Ard Biesheuvel
2023-03-30 14:25     ` Ni, Ray
2023-03-30 15:04       ` Ard Biesheuvel
2023-03-30 16:33         ` Ard Biesheuvel
2023-03-30 16:47           ` Ard Biesheuvel
2023-03-30 16:54           ` Rebecca Cran
2023-03-30 17:03             ` Ard Biesheuvel
2023-03-30 15:30 ` Michael D Kinney

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox