gh-128605: Add branch protections for x86_64 in asm_trampoline.S #128606

stratakis · 2025-01-08T04:51:26Z

Issue: asm_trampoline.S misses branch protection flags for x86_64 and aarch64 #128605

stratakis · 2025-01-08T04:53:46Z

stratakis · 2025-01-08T04:55:37Z

In the current implementation the cf-protection test for x86_64 passes but not the branch-protection test for aarch64.

fweimer-rh · 2025-01-08T06:58:14Z

You should add PAC support at the same time, using hint 25 (paciasp, replaces bti c) and hint 29 (autiasp). These instructions are in the NOP space, but some CPUs have trouble executing them. This applies to bit c as well. So it's best to make this conditional on compiler flags, by checking the __ARM_FEATURE_BTI_DEFAULT preprocessor macro. Then you can change the flag at the end of the note from 1 to 3, and this should make annocheck happy.

stratakis · 2025-01-09T14:28:41Z

Rebased. The conditionals are a bit of a mess right now so I'll do some macros later on.

However annobin still reports:

Hardened: libpython3.12.so.1.0: FAIL: dynamic-tags test because the BTI_PLT flag is missing from the dynamic tags
Hardened: libpython3.12.so.1.0: FAIL: property-note test because properly formatted .note.gnu.property not found (it is needed for branch protection support)

Btw the arm blog proposes a different styled note than what the annobin docs mention: https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/p2-enabling-pac-and-bti-on-aarch64

Also regarding x86_64. Shouldn't the note be conditionalized in the case CET is active?

stratakis · 2025-01-12T18:16:19Z

cc'ing also @pablogsal as the original author of the file.

bedevere-bot · 2025-01-13T00:13:21Z

🤖 New build scheduled with the buildbot fleet by @pablogsal for commit 549b894 🤖

If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again.

pablogsal

This will break the DWARF mode as the debug information we are adding matches exactly with the current assembly instructions and positions:

cpython/Python/perf_jit_trampoline.c

Lines 452 to 489 in d0ecbdd

    
               /* Emit DWARF EH CIE. */ 
        
               DWRF_SECTION(CIE, DWRF_U32(0); /* Offset to CIE itself. */ 
        
                            DWRF_U8(DWRF_CIE_VERSION); 
        
                            DWRF_STR("zR"); /* Augmentation. */ 
        
                            DWRF_UV(1); /* Code alignment factor. */ 
        
                            DWRF_SV(-(int64_t)sizeof(uintptr_t)); /* Data alignment factor. */ 
        
                            DWRF_U8(DWRF_REG_RA); /* Return address register. */ 
        
                            DWRF_UV(1); 
        
                            DWRF_U8(DWRF_EH_PE_pcrel | DWRF_EH_PE_sdata4); /* Augmentation data. */ 
        
                            DWRF_U8(DWRF_CFA_def_cfa); DWRF_UV(DWRF_REG_SP); DWRF_UV(sizeof(uintptr_t)); 
        
                            DWRF_U8(DWRF_CFA_offset|DWRF_REG_RA); DWRF_UV(1); 
        
                            DWRF_ALIGNNOP(sizeof(uintptr_t)); 
        
               ) 
        
               ctx->eh_frame_p = p; 
        
               /* Emit DWARF EH FDE. */ 
        
               DWRF_SECTION(FDE, DWRF_U32((uint32_t)(p - framep)); /* Offset to CIE. */ 
        
                            DWRF_U32(-0x30); /* Machine code offset relative to .text. */ 
        
                            DWRF_U32(ctx->code_size); /* Machine code length. */ 
        
                            DWRF_U8(0); /* Augmentation data. */ 
        
               /* Registers saved in CFRAME. */ 
        
           #ifdef __x86_64__ 
        
                            DWRF_U8(DWRF_CFA_advance_loc | 4); 
        
                            DWRF_U8(DWRF_CFA_def_cfa_offset); DWRF_UV(16); 
        
                            DWRF_U8(DWRF_CFA_advance_loc | 6); 
        
                            DWRF_U8(DWRF_CFA_def_cfa_offset); DWRF_UV(8); 
        
               /* Extra registers saved for JIT-compiled code. */ 
        
           #elif defined(__aarch64__) && defined(__AARCH64EL__) && !defined(__ILP32__) 
        
                            DWRF_U8(DWRF_CFA_advance_loc | 1); 
        
                            DWRF_U8(DWRF_CFA_def_cfa_offset); DWRF_UV(16); 
        
                            DWRF_U8(DWRF_CFA_offset | 29); DWRF_UV(2); 
        
                            DWRF_U8(DWRF_CFA_offset | 30); DWRF_UV(1); 
        
                            DWRF_U8(DWRF_CFA_advance_loc | 3); 
        
                            DWRF_U8(DWRF_CFA_offset | -(64 - 29)); 
        
                            DWRF_U8(DWRF_CFA_offset | -(64 - 30)); 
        
                            DWRF_U8(DWRF_CFA_def_cfa_offset); 
        
                            DWRF_UV(0);

I am also not sure why this is needed other than make the annocheck tool happy so I am not sure we want to add this extra complexity.

bedevere-app · 2025-01-13T00:15:46Z

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

stratakis · 2025-01-13T14:17:27Z

I am also not sure why this is needed other than make the annocheck tool happy so I am not sure we want to add this extra complexity.

The justification for this change is provided at the linked issue.

pablogsal · 2025-01-13T15:17:48Z

I am also not sure why this is needed other than make the annocheck tool happy so I am not sure we want to add this extra complexity.

The justification for this change is provided at the linked issue.

I don't think that justification is enough. The only thing the issue mentioned is that we are not using a feature and that the annocheck is unhappy. Could you ellaborate what are the consequences of not adding these instructions?

In any case, we need to check if the DWARF needs to be updated to account for the new instructions and if GDB can still unwind across them.

stratakis · 2025-01-14T00:51:13Z

I don't think that justification is enough. The only thing the issue mentioned is that we are not using a feature and that the annocheck is unhappy. Could you ellaborate what are the consequences of not adding these instructions?

Of course. Both ubuntu and Fedora (and by extension RHEL) and I assume other distros, enable by default the -fcf-protection flag for x86_64 and -mbranch-protection=standard for aarch64. When these flags are applied, the compiler places those instructions at the appropriate places when the CPU supports them and a NOP when it doesn't.

Both are implemented to mitigate return-oriented programming (ROP) and Call or Jump Oriented Programming (COP/JOP) attacks.

Minimum supported CPU models are Intel's Tiger lake, AMD's Zen 3, Arm 8.3 (PAC) and Arm 8.5 (BTI).

With pure C code everything is fine by just using the compiler flag(s), however when an assembly file is added to the mix the instructions need to be added manually.

This feature is an all-or-nothing for the hardware functionality to work. All object files are checked for the note and if it's missing on any one, the linker does not place the note to the final executable and the hardening feature is disabled in the hardware. That essentially means that for Python 3.12+ these flags have no effect anymore.

pablogsal · 2025-01-14T13:01:57Z

Ok makes sense. Thanks a lot for the extra context.

We need to complement the DWARF information to ensure that the Perf JIT integration still works and we need to ensure gdb can still unwind through the trampolines when this information is active.

brandtbucher · 2025-01-14T19:03:56Z

This feature is an all-or-nothing for the hardware functionality to work. All object files are checked for the note and if it's missing on any one, the linker does not place the note to the final executable and the hardening feature is disabled in the hardware. That essentially means that for Python 3.12+ these flags have no effect anymore.

Are JIT compilers expected to implement this as well? Or no, since they aren't statically present in the executable?

pablogsal · 2025-01-14T23:29:26Z

This feature is an all-or-nothing for the hardware functionality to work. All object files are checked for the note and if it's missing on any one, the linker does not place the note to the final executable and the hardening feature is disabled in the hardware. That essentially means that for Python 3.12+ these flags have no effect anymore.

Are JIT compilers expected to implement this as well? Or no, since they aren't statically present in the executable?

Technically this code is also not present in the executable: we copy it from memory but the region itself where we copy it from is never executed. So if the answer is "no" then we shouldn't need this either

stratakis · 2025-01-15T01:04:32Z

Ok makes sense. Thanks a lot for the extra context.

We need to complement the DWARF information to ensure that the Perf JIT integration still works and we need to ensure gdb can still unwind through the trampolines when this information is active.

Providing also a more practical reproducer.

On Python 3.11 on x86_64:

$ ./configure && make -j10 CFLAGS=-fcf-protection
$ readelf -n python

Properties: x86 feature: IBT, SHSTK

Both of those flags indicate that CET protection is enabled. In Python 3.12+ they are not present.

Of course when building with --enable-shared libpython needs to be inspected instead.

I'll familiarize myself with the debug information and try to figure it out.

stratakis · 2025-01-15T01:43:01Z

This feature is an all-or-nothing for the hardware functionality to work. All object files are checked for the note and if it's missing on any one, the linker does not place the note to the final executable and the hardening feature is disabled in the hardware. That essentially means that for Python 3.12+ these flags have no effect anymore.

Are JIT compilers expected to implement this as well? Or no, since they aren't statically present in the executable?

The answer here would be possibly yes, assembly instructions emitted by JITs should implement that, however I am not familiar myself with JITs in general or the way CPython implements it to provide a definite answer. As JIT is still being developed I'd treat this as an afterthought and revisit it in the future.

fweimer-rh · 2025-01-15T07:37:49Z

Ok makes sense. Thanks a lot for the extra context.

We need to complement the DWARF information to ensure that the Perf JIT integration still works and we need to ensure gdb can still unwind through the trampolines when this information is active.

@pablogsal As the DWARF needs to be updated anyway, it may make sense to add the missing frame pointer to the x86-64 assembler (if Python's policy is to have frame pointers). Or is the goal to elide the calling frame from profiling backtraces? If the latter, there should really be a comment to this effect.

fweimer-rh · 2025-01-15T07:43:35Z

Are JIT compilers expected to implement this as well? Or no, since they aren't statically present in the executable?

@brandtbucher For JIT compilers to keep working unchanged, they need to be marked as incompatible for now. On x86-64, SHSTK is generally automatically compatible with JIT compilation unless stack unwinding code is generated. However, x86-64 IBT requires marker instructions at the target of indirect branches. On AArch64, BTI is similar (marker instructions), but PAC is not process-switched on Linux: it's determined at boot whether it is turned on or not. The presence of the extra instructions merely ensures that the JIT code does not contain any easy-to-use JOP/ROP gadgets.

Whether any of this matters is of course debatable, assuming that Python does not write-protect any of its bytecode in the process image.

pablogsal · 2025-01-15T08:28:20Z

Ok makes sense. Thanks a lot for the extra context.

We need to complement the DWARF information to ensure that the Perf JIT integration still works and we need to ensure gdb can still unwind through the trampolines when this information is active.

@pablogsal As the DWARF needs to be updated anyway, it may make sense to add the missing frame pointer to the x86-64 assembler (if Python's policy is to have frame pointers). Or is the goal to elide the calling frame from profiling backtraces? If the latter, there should really be a comment to this effect.

One of the problems is that if you add the frame pointer to the x86-64 assembler gdb cannot unwind through this when Python is compiled without frame pointers. The current version allows unwinding with and without frame pointers.

brandtbucher · 2025-01-16T00:30:51Z

@brandtbucher For JIT compilers to keep working unchanged, they need to be marked as incompatible for now. On x86-64, SHSTK is generally automatically compatible with JIT compilation unless stack unwinding code is generated. However, x86-64 IBT requires marker instructions at the target of indirect branches. On AArch64, BTI is similar (marker instructions), but PAC is not process-switched on Linux: it's determined at boot whether it is turned on or not. The presence of the extra instructions merely ensures that the JIT code does not contain any easy-to-use JOP/ROP gadgets.

Whether any of this matters is of course debatable, assuming that Python does not write-protect any of its bytecode in the process image.

I'm afraid this is a bit too jargon-heavy for me to follow without doing a bunch of self-guided research on the topic.

What does it mean for the JIT code to be "marked incompatible"? I take it that if the process/kernel has these hardware features enabled, JIT code that doesn't use it will probably crash? What's the typical performance overhead of enabling this, and who exactly is using it (Ubuntu and Fedora were mentioned above... is it all users of these distros who would be unable to use our JIT)?

stratakis · 2025-02-19T21:45:10Z

:

Took a shot at figuring this out, at least for x86_64.

This is what I followed:

typedef void *(py_evaluator)(void *ts, void *f, int t);

void *trampoline(void *ts, void *f, int throwflag, py_evaluator evaluator) {
  return evaluator(ts, f, throwflag);
}

Compiled with gcc -O1 -c -g file.c to verify the assembly and that the eh_frame corresponds to

cpython/Python/perf_jit_trampoline.c

Lines 452 to 489 in d0ecbdd

    
               /* Emit DWARF EH CIE. */ 
        
               DWRF_SECTION(CIE, DWRF_U32(0); /* Offset to CIE itself. */ 
        
                            DWRF_U8(DWRF_CIE_VERSION); 
        
                            DWRF_STR("zR"); /* Augmentation. */ 
        
                            DWRF_UV(1); /* Code alignment factor. */ 
        
                            DWRF_SV(-(int64_t)sizeof(uintptr_t)); /* Data alignment factor. */ 
        
                            DWRF_U8(DWRF_REG_RA); /* Return address register. */ 
        
                            DWRF_UV(1); 
        
                            DWRF_U8(DWRF_EH_PE_pcrel | DWRF_EH_PE_sdata4); /* Augmentation data. */ 
        
                            DWRF_U8(DWRF_CFA_def_cfa); DWRF_UV(DWRF_REG_SP); DWRF_UV(sizeof(uintptr_t)); 
        
                            DWRF_U8(DWRF_CFA_offset|DWRF_REG_RA); DWRF_UV(1); 
        
                            DWRF_ALIGNNOP(sizeof(uintptr_t)); 
        
               ) 
        
               ctx->eh_frame_p = p; 
        
               /* Emit DWARF EH FDE. */ 
        
               DWRF_SECTION(FDE, DWRF_U32((uint32_t)(p - framep)); /* Offset to CIE. */ 
        
                            DWRF_U32(-0x30); /* Machine code offset relative to .text. */ 
        
                            DWRF_U32(ctx->code_size); /* Machine code length. */ 
        
                            DWRF_U8(0); /* Augmentation data. */ 
        
               /* Registers saved in CFRAME. */ 
        
           #ifdef __x86_64__ 
        
                            DWRF_U8(DWRF_CFA_advance_loc | 4); 
        
                            DWRF_U8(DWRF_CFA_def_cfa_offset); DWRF_UV(16); 
        
                            DWRF_U8(DWRF_CFA_advance_loc | 6); 
        
                            DWRF_U8(DWRF_CFA_def_cfa_offset); DWRF_UV(8); 
        
               /* Extra registers saved for JIT-compiled code. */ 
        
           #elif defined(__aarch64__) && defined(__AARCH64EL__) && !defined(__ILP32__) 
        
                            DWRF_U8(DWRF_CFA_advance_loc | 1); 
        
                            DWRF_U8(DWRF_CFA_def_cfa_offset); DWRF_UV(16); 
        
                            DWRF_U8(DWRF_CFA_offset | 29); DWRF_UV(2); 
        
                            DWRF_U8(DWRF_CFA_offset | 30); DWRF_UV(1); 
        
                            DWRF_U8(DWRF_CFA_advance_loc | 3); 
        
                            DWRF_U8(DWRF_CFA_offset | -(64 - 29)); 
        
                            DWRF_U8(DWRF_CFA_offset | -(64 - 30)); 
        
                            DWRF_U8(DWRF_CFA_def_cfa_offset); 
        
                            DWRF_UV(0);

   0:	48 83 ec 08          	sub    $0x8,%rsp
   4:	ff d1                	call   *%rcx
   6:	48 83 c4 08          	add    $0x8,%rsp
   a:	c3                   	ret

And the eh_frame:

00000000 0000000000000014 00000000 CIE
  Version:               1
  Augmentation:          "zR"
  Code alignment factor: 1
  Data alignment factor: -8
  Return address column: 16
  Augmentation data:     1b
  DW_CFA_def_cfa: r7 (rsp) ofs 8
  DW_CFA_offset: r16 (rip) at cfa-8
  DW_CFA_nop
  DW_CFA_nop

00000018 0000000000000014 0000001c FDE cie=00000000 pc=0000000000000000..000000000000000b
  DW_CFA_advance_loc: 4 to 0000000000000004
  DW_CFA_def_cfa_offset: 16
  DW_CFA_advance_loc: 6 to 000000000000000a
  DW_CFA_def_cfa_offset: 8
  DW_CFA_nop

And then recompiling with gcc -O1 -c -g -fcf-protection file.c and verifying that the endbr64 command was injected:

   0:	f3 0f 1e fa          	endbr64
   4:	48 83 ec 08          	sub    $0x8,%rsp
   8:	ff d1                	call   *%rcx
   a:	48 83 c4 08          	add    $0x8,%rsp
   e:	c3                   	ret

00000000 0000000000000014 00000000 CIE
  Version:               1
  Augmentation:          "zR"
  Code alignment factor: 1
  Data alignment factor: -8
  Return address column: 16
  Augmentation data:     1b
  DW_CFA_def_cfa: r7 (rsp) ofs 8
  DW_CFA_offset: r16 (rip) at cfa-8
  DW_CFA_nop
  DW_CFA_nop

00000018 0000000000000014 0000001c FDE cie=00000000 pc=0000000000000000..000000000000000f
  DW_CFA_advance_loc: 8 to 0000000000000008
  DW_CFA_def_cfa_offset: 16
  DW_CFA_advance_loc: 6 to 000000000000000e
  DW_CFA_def_cfa_offset: 8
  DW_CFA_nop

Still need to verify that it actually works of course.

stratakis · 2025-02-20T01:41:19Z

And I believe it should make things easier if I split this PR for x86_64 and aarch64.

stratakis · 2025-03-05T03:03:45Z

The PR is ready. I've split it, so this is only for x86_64. Not entirely sure that a news entry is necessary here but I can add one if required.

I've also verified that gdb and perf work the same as before with and without -fcf-protection and annobin correctly verified that CET protection is present.

python3.12:

-O3, -O1, -O0, -Og:
Complete gdb stack trace.
-O2:
Incomplete gdb stack trace (stops at the unknown frames).

python3.13:

-O3, -O2, -O0, -Og:
Complete gdb stack trace.
-O1:
Incomplete gdb stack trace (stops at the unknown frames).

python3.14:

-O3, -O2, -Og:
Incomplete gdb stack trace (stops at the unknown frames).
-O1, -O0:
Complete gdb stack trace.

Python/asm_trampoline.S

Required for mitigation against return-oriented programming (ROP) and Call or Jump Oriented Programming (COP/JOP) attacks Manual application is required for the assembly files See also: https://sourceware.org/annobin/annobin.html/Test-cf-protection.html

vstinner · 2025-03-17T17:22:35Z

@pablogsal: @stratakis updated the DWARF information and explained why this change is needed. Would you mind to review it again?

bedevere-bot · 2025-03-17T17:36:51Z

🤖 New build scheduled with the buildbot fleet by @pablogsal for commit f6dcc96 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F128606%2Fmerge

If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again.

pablogsal · 2025-03-17T17:37:22Z

Will run the buildbots and I will do a pass and merge

stratakis · 2025-03-17T17:46:27Z

Btw this should be fine to backport to 3.13 and, without the perf_jit_trampoline.c changes, to 3.12.

vstinner · 2025-03-18T10:05:23Z

A single buildbot worker failed:

buildbot/AMD64 Arch Linux TraceRefs PR

But it's an unrelated failure:

_bootstrap_python: Objects/object.c:240: _PyRefchain_Remove: Assertion `value == REFCHAIN_VALUE' failed.
make: *** [Makefile:1787: Python/frozen_modules/abc.h] Aborted (core dumped)

There is the same error in the main branch: https://buildbot.python.org/#/builders/484/builds/6705

vstinner · 2025-03-18T10:12:21Z

There is the same error in the main branch: https://buildbot.python.org/#/builders/484/builds/6705

It's a regression introduced by commit fd545d7: issue #127705.

bedevere-app bot mentioned this pull request Jan 8, 2025

asm_trampoline.S misses branch protection flags for x86_64 and aarch64 #128605

Open

bedevere-app bot added the awaiting review label Jan 8, 2025

stratakis force-pushed the branch_protection branch from d97e78d to 6d86e0f Compare January 9, 2025 14:25

stratakis force-pushed the branch_protection branch from 6d86e0f to 549b894 Compare January 9, 2025 14:30

pablogsal added the 🔨 test-with-buildbots Test PR w/ buildbots; report in status section label Jan 13, 2025

bedevere-bot removed the 🔨 test-with-buildbots Test PR w/ buildbots; report in status section label Jan 13, 2025

pablogsal requested changes Jan 13, 2025

View reviewed changes

bedevere-app bot added awaiting changes and removed awaiting review labels Jan 13, 2025

stratakis force-pushed the branch_protection branch 2 times, most recently from a7408db to 6d2d4f7 Compare January 14, 2025 02:39

stratakis force-pushed the branch_protection branch from 6d2d4f7 to 0070169 Compare February 19, 2025 21:26

stratakis requested review from brandtbucher and savannahostrowski as code owners February 19, 2025 21:26

stratakis force-pushed the branch_protection branch from 0070169 to dcc714a Compare March 5, 2025 02:53

stratakis changed the title ~~[DRAFT]gh-128605: Add branch protections for asm_trampoline.S~~ gh-128605: Add branch protections for x86_64 in asm_trampoline.S Mar 5, 2025

stratakis force-pushed the branch_protection branch from dcc714a to 4b78b22 Compare March 5, 2025 02:59

stratakis mentioned this pull request Mar 5, 2025

[DRAFT]gh-128605: Add branch protections for aarch64 in asm_trampoline.S #130864

Open

vstinner reviewed Mar 6, 2025

View reviewed changes

Python/asm_trampoline.S Show resolved Hide resolved

stratakis force-pushed the branch_protection branch from 4b78b22 to f2dcd8c Compare March 6, 2025 16:53

stratakis requested a review from pablogsal March 6, 2025 16:54

vstinner reviewed Mar 6, 2025

View reviewed changes

Python/asm_trampoline.S Outdated Show resolved Hide resolved

stratakis force-pushed the branch_protection branch from f2dcd8c to f6dcc96 Compare March 6, 2025 18:39

vstinner added the skip news label Mar 17, 2025

pablogsal added the 🔨 test-with-buildbots Test PR w/ buildbots; report in status section label Mar 17, 2025

bedevere-bot removed the 🔨 test-with-buildbots Test PR w/ buildbots; report in status section label Mar 17, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

gh-128605: Add branch protections for x86_64 in asm_trampoline.S #128606

gh-128605: Add branch protections for x86_64 in asm_trampoline.S #128606

stratakis commented Jan 8, 2025 •

edited by bedevere-app bot

Loading

stratakis commented Jan 8, 2025

stratakis commented Jan 8, 2025

fweimer-rh commented Jan 8, 2025

stratakis commented Jan 9, 2025

stratakis commented Jan 12, 2025

bedevere-bot commented Jan 13, 2025

pablogsal left a comment •

edited

Loading

bedevere-app bot commented Jan 13, 2025

stratakis commented Jan 13, 2025

pablogsal commented Jan 13, 2025 •

edited

Loading

stratakis commented Jan 14, 2025

pablogsal commented Jan 14, 2025

brandtbucher commented Jan 14, 2025

pablogsal commented Jan 14, 2025 •

edited

Loading

stratakis commented Jan 15, 2025

stratakis commented Jan 15, 2025

fweimer-rh commented Jan 15, 2025

fweimer-rh commented Jan 15, 2025

pablogsal commented Jan 15, 2025

brandtbucher commented Jan 16, 2025

stratakis commented Feb 19, 2025

stratakis commented Feb 20, 2025

stratakis commented Mar 5, 2025

vstinner commented Mar 17, 2025

bedevere-bot commented Mar 17, 2025

pablogsal commented Mar 17, 2025

stratakis commented Mar 17, 2025

vstinner commented Mar 18, 2025

vstinner commented Mar 18, 2025

	/* Emit DWARF EH CIE. */
	DWRF_SECTION(CIE, DWRF_U32(0); /* Offset to CIE itself. */
	DWRF_U8(DWRF_CIE_VERSION);
	DWRF_STR("zR"); /* Augmentation. */
	DWRF_UV(1); /* Code alignment factor. */
	DWRF_SV(-(int64_t)sizeof(uintptr_t)); /* Data alignment factor. */
	DWRF_U8(DWRF_REG_RA); /* Return address register. */
	DWRF_UV(1);
	DWRF_U8(DWRF_EH_PE_pcrel \| DWRF_EH_PE_sdata4); /* Augmentation data. */
	DWRF_U8(DWRF_CFA_def_cfa); DWRF_UV(DWRF_REG_SP); DWRF_UV(sizeof(uintptr_t));
	DWRF_U8(DWRF_CFA_offset\|DWRF_REG_RA); DWRF_UV(1);
	DWRF_ALIGNNOP(sizeof(uintptr_t));
	)

	ctx->eh_frame_p = p;

	/* Emit DWARF EH FDE. */
	DWRF_SECTION(FDE, DWRF_U32((uint32_t)(p - framep)); /* Offset to CIE. */
	DWRF_U32(-0x30); /* Machine code offset relative to .text. */
	DWRF_U32(ctx->code_size); /* Machine code length. */
	DWRF_U8(0); /* Augmentation data. */
	/* Registers saved in CFRAME. */
	#ifdef __x86_64__
	DWRF_U8(DWRF_CFA_advance_loc \| 4);
	DWRF_U8(DWRF_CFA_def_cfa_offset); DWRF_UV(16);
	DWRF_U8(DWRF_CFA_advance_loc \| 6);
	DWRF_U8(DWRF_CFA_def_cfa_offset); DWRF_UV(8);
	/* Extra registers saved for JIT-compiled code. */
	#elif defined(__aarch64__) && defined(__AARCH64EL__) && !defined(__ILP32__)
	DWRF_U8(DWRF_CFA_advance_loc \| 1);
	DWRF_U8(DWRF_CFA_def_cfa_offset); DWRF_UV(16);
	DWRF_U8(DWRF_CFA_offset \| 29); DWRF_UV(2);
	DWRF_U8(DWRF_CFA_offset \| 30); DWRF_UV(1);
	DWRF_U8(DWRF_CFA_advance_loc \| 3);
	DWRF_U8(DWRF_CFA_offset \| -(64 - 29));
	DWRF_U8(DWRF_CFA_offset \| -(64 - 30));
	DWRF_U8(DWRF_CFA_def_cfa_offset);
	DWRF_UV(0);

gh-128605: Add branch protections for x86_64 in asm_trampoline.S #128606

Are you sure you want to change the base?

gh-128605: Add branch protections for x86_64 in asm_trampoline.S #128606

Conversation

stratakis commented Jan 8, 2025 • edited by bedevere-app bot Loading

stratakis commented Jan 8, 2025

stratakis commented Jan 8, 2025

fweimer-rh commented Jan 8, 2025

stratakis commented Jan 9, 2025

stratakis commented Jan 12, 2025

bedevere-bot commented Jan 13, 2025

pablogsal left a comment • edited Loading

Choose a reason for hiding this comment

bedevere-app bot commented Jan 13, 2025

stratakis commented Jan 13, 2025

pablogsal commented Jan 13, 2025 • edited Loading

stratakis commented Jan 14, 2025

pablogsal commented Jan 14, 2025

brandtbucher commented Jan 14, 2025

pablogsal commented Jan 14, 2025 • edited Loading

stratakis commented Jan 15, 2025

stratakis commented Jan 15, 2025

fweimer-rh commented Jan 15, 2025

fweimer-rh commented Jan 15, 2025

pablogsal commented Jan 15, 2025

brandtbucher commented Jan 16, 2025

stratakis commented Feb 19, 2025

stratakis commented Feb 20, 2025

stratakis commented Mar 5, 2025

vstinner commented Mar 17, 2025

bedevere-bot commented Mar 17, 2025

pablogsal commented Mar 17, 2025

stratakis commented Mar 17, 2025

vstinner commented Mar 18, 2025

vstinner commented Mar 18, 2025

stratakis commented Jan 8, 2025 •

edited by bedevere-app bot

Loading

pablogsal left a comment •

edited

Loading

pablogsal commented Jan 13, 2025 •

edited

Loading

pablogsal commented Jan 14, 2025 •

edited

Loading