Page MenuHomePhabricator

xiangzhangllvm (Xiang Zhang)
User

Projects

User does not belong to any projects.

User Details

User Since
Dec 25 2018, 11:14 PM (65 w, 6 d)

Recent Activity

Today

xiangzhangllvm created D77124: Handle CET for -exception-model sjlj.
Tue, Mar 31, 2:42 AM · Restricted Project

Yesterday

xiangzhangllvm updated the diff for D76900: Enable IBT(Indirect Branch Tracking) in JIT with CET(Control-flow Enforcement Technology).

@efriedma Put the https://bugs.llvm.org/show_bug.cgi?id=45364 test into X86/indirect-branch-tracking.ll @test5

Mon, Mar 30, 10:55 PM · Restricted Project
xiangzhangllvm added a comment to D76900: Enable IBT(Indirect Branch Tracking) in JIT with CET(Control-flow Enforcement Technology).

Yes, please add that as a test.

The current patch works, but it's emitting endbrs for small code model examples where they shouldn't be necessary. Maybe someone else can chime in on how important that is in practice.

Mon, Mar 30, 7:41 PM · Restricted Project
xiangzhangllvm added a comment to D76900: Enable IBT(Indirect Branch Tracking) in JIT with CET(Control-flow Enforcement Technology).
Mon, Mar 30, 6:02 PM · Restricted Project
xiangzhangllvm updated the diff for D76900: Enable IBT(Indirect Branch Tracking) in JIT with CET(Control-flow Enforcement Technology).

Let me first update the patch self.

Mon, Mar 30, 5:55 AM · Restricted Project
xiangzhangllvm added a comment to D76900: Enable IBT(Indirect Branch Tracking) in JIT with CET(Control-flow Enforcement Technology).

It will be very nice to extract a testcase from Mesa. This bug may be harmless without CET,
but it is fatal with CET.

Mon, Mar 30, 5:22 AM · Restricted Project
xiangzhangllvm added a comment to D76900: Enable IBT(Indirect Branch Tracking) in JIT with CET(Control-flow Enforcement Technology).

If "1 Check CET in JIT instead of checking -fcf-protection-branch" can't let VNC passed. The crash must happen at "Take address of a internal function."

Mon, Mar 30, 1:35 AM · Restricted Project

Sun, Mar 29

xiangzhangllvm updated the summary of D76900: Enable IBT(Indirect Branch Tracking) in JIT with CET(Control-flow Enforcement Technology).
Sun, Mar 29, 8:20 PM · Restricted Project
xiangzhangllvm added a comment to D76900: Enable IBT(Indirect Branch Tracking) in JIT with CET(Control-flow Enforcement Technology).

2, Do you mean here we need add JIT test for this patch ? Check endbr in JIT generated code?

My changes fixed the VNC crash. But there is no testcase to show why my patches are needed.

Sun, Mar 29, 7:48 PM · Restricted Project
xiangzhangllvm added a comment to D76900: Enable IBT(Indirect Branch Tracking) in JIT with CET(Control-flow Enforcement Technology).

Please take a look at

https://gitlab.freedesktop.org/mesa/mesa

to see how LLVM JIT is used and extract a testcase from it.

1, Does it in your commits? I find 2 your commits without the JIT tests.

Sun, Mar 29, 6:43 PM · Restricted Project

Sat, Mar 28

xiangzhangllvm added inline comments to D76900: Enable IBT(Indirect Branch Tracking) in JIT with CET(Control-flow Enforcement Technology).
Sat, Mar 28, 10:00 PM · Restricted Project
xiangzhangllvm updated the diff for D76900: Enable IBT(Indirect Branch Tracking) in JIT with CET(Control-flow Enforcement Technology).
Sat, Mar 28, 1:35 AM · Restricted Project
xiangzhangllvm added inline comments to D76900: Enable IBT(Indirect Branch Tracking) in JIT with CET(Control-flow Enforcement Technology).
Sat, Mar 28, 1:35 AM · Restricted Project

Thu, Mar 26

xiangzhangllvm added inline comments to D76900: Enable IBT(Indirect Branch Tracking) in JIT with CET(Control-flow Enforcement Technology).
Thu, Mar 26, 11:20 PM · Restricted Project
xiangzhangllvm updated the diff for D76900: Enable IBT(Indirect Branch Tracking) in JIT with CET(Control-flow Enforcement Technology).
Thu, Mar 26, 8:40 PM · Restricted Project
xiangzhangllvm added inline comments to D76900: Enable IBT(Indirect Branch Tracking) in JIT with CET(Control-flow Enforcement Technology).
Thu, Mar 26, 8:40 PM · Restricted Project
xiangzhangllvm added inline comments to D76900: Enable IBT(Indirect Branch Tracking) in JIT with CET(Control-flow Enforcement Technology).
Thu, Mar 26, 8:07 PM · Restricted Project
xiangzhangllvm created D76900: Enable IBT(Indirect Branch Tracking) in JIT with CET(Control-flow Enforcement Technology).
Thu, Mar 26, 7:02 PM · Restricted Project
xiangzhangllvm retitled D76900: Enable IBT(Indirect Branch Tracking) in JIT with CET(Control-flow Enforcement Technology) from Enable IBT(Indirect Branch Tracking) in JIT with CET to Enable IBT(Indirect Branch Tracking) in JIT with CET(Control-flow Enforcement Technology).
Thu, Mar 26, 7:02 PM · Restricted Project

Mon, Mar 16

xiangzhangllvm updated the diff for D76190: CET for Exception Handle.
Mon, Mar 16, 8:12 PM · Restricted Project

Sun, Mar 15

xiangzhangllvm updated the diff for D76190: CET for Exception Handle.
Sun, Mar 15, 11:08 PM · Restricted Project
xiangzhangllvm added inline comments to D76190: CET for Exception Handle.
Sun, Mar 15, 6:15 PM · Restricted Project
xiangzhangllvm created D76190: CET for Exception Handle.
Sun, Mar 15, 3:11 AM · Restricted Project

Feb 10 2020

xiangzhangllvm added a comment to D72197: [MC][ELF] Emit a relocation if target is defined in the same section and is non-local.

Thanks for so detailed information, I am happy to push this thing go ahead.
But except the failed case, I feel let "protected symbol refer in same section" to directly calculate the symbol Vaule is better.
Does it will affected "symbol interposition"? I just know IFUN will use "symbol interposition".

Feb 10 2020, 12:50 AM · Restricted Project

Feb 8 2020

xiangzhangllvm added a comment to D72197: [MC][ELF] Emit a relocation if target is defined in the same section and is non-local.

I wonder if is this really a bug or intentional. Clang and LLVM seem to ignore the possibility of symbol interposition (see: -fno-semantic-interposition). What is the LLVM policy for this?

Also, this code is missing a case for STB_GLOBAL and visibility != STV_DEFAULT. Actually, I have noticed before that this case is missing in various places in MC. As it stands this patch may cause a performance regression on platforms that use -fvisibility=hidden.

Visibility is irrelevant here. For a symbol defined in the same section as the instruction, the relocation record will reference a non-SECTION symbol instead of a STT_SECTION after this change. If the symbol is STV_HIDDEN, the linker will think the symbol is non-preemptible. So, no performance regression.

There are many ways to make a symbol non-preemptible: binding (STB_LOCAL), visibility (STV_INTERNAL, STV_PROTECTED or STV_HIDDEN), --dynamic-list, VER_NDX_LOCAL, -Bsymbolic, -Bsymbolic-functions, etc. I have made enough refactorings to lld Symbol::isPreemptible and I am confident with these things :)

GCC r212049 (first included in GCC 5) introduced -fsemantic-interposition. Yes, current Clang/LLVM behavior is like -fno-semantic-interposition. Our behavior is not ideal and @hfinkel had an RFC https://lists.llvm.org/pipermail/llvm-dev/2016-November/107625.html . This change should help -fsemantic-interposition if we decide to move towards that goal.

Feb 8 2020, 11:18 PM · Restricted Project

Jan 14 2020

xiangzhangllvm added a comment to D59780: Support Intel Control-flow Enforcement Technology.

Thank you again!!

Jan 14 2020, 12:07 AM · Restricted Project

Jan 13 2020

xiangzhangllvm added a comment to D59780: Support Intel Control-flow Enforcement Technology.

LGTM

Jan 13 2020, 10:53 PM · Restricted Project
xiangzhangllvm added a comment to D59780: Support Intel Control-flow Enforcement Technology.

ping @ruiu Hi, Do you have time to review? Thanks!

Jan 13 2020, 5:27 PM · Restricted Project

Jan 10 2020

xiangzhangllvm added inline comments to D59780: Support Intel Control-flow Enforcement Technology.
Jan 10 2020, 3:22 AM · Restricted Project

Jan 9 2020

xiangzhangllvm added inline comments to D59780: Support Intel Control-flow Enforcement Technology.
Jan 9 2020, 6:40 PM · Restricted Project

Jan 1 2020

xiangzhangllvm added a comment to D71917: [X86] Optimization of inserting vxi1 sub vector into vXi1 vector .

update the patch, and I tested in my local performance test, it really have a little small improvement.

Jan 1 2020, 5:51 PM · Restricted Project
xiangzhangllvm updated the diff for D71917: [X86] Optimization of inserting vxi1 sub vector into vXi1 vector .
Jan 1 2020, 5:43 PM · Restricted Project

Dec 29 2019

xiangzhangllvm updated the diff for D71917: [X86] Optimization of inserting vxi1 sub vector into vXi1 vector .
Dec 29 2019, 5:51 PM · Restricted Project
xiangzhangllvm added inline comments to D71917: [X86] Optimization of inserting vxi1 sub vector into vXi1 vector .
Dec 29 2019, 5:33 PM · Restricted Project

Dec 26 2019

xiangzhangllvm created D71917: [X86] Optimization of inserting vxi1 sub vector into vXi1 vector .
Dec 26 2019, 6:05 PM · Restricted Project

Dec 12 2019

xiangzhangllvm added a comment to D59780: Support Intel Control-flow Enforcement Technology.

For MPX prefix:
GCC have not supported the MPX from GCC 9. And intel will not support MPX code too. So we don’t consider MPX for CET in LLD.

I know that GCC has removed MPX and the Linux kernel is removing MPX (user-visible APIs and self-tests have been removed). I asked because I haven't seen a change on binutils-gdb side that will support a .plt.sec scheme without the BND prefix. So, I wonder what kind of changes are considered divergence from x86-64 psABI. After the removal of the BND prefix, the .plt entry will get the leeway of 2 bytes. If, say, in the future, a new security enhanced feature is proposed which requires a new instruction that will take more than 2 bytes, the 16-byte .plt entry no longer works, and toolchains will have to migrate a third PLT scheme, different from traditional PLT and the .plt.sec scheme.

As to the option name question, are you happy with -z force-ibt and -z shstk? (My understanding is that they should be very similar to -z force-bti and -z pac-plt, respectively.)

Dec 12 2019, 6:43 PM · Restricted Project

Dec 11 2019

xiangzhangllvm added a comment to D59780: Support Intel Control-flow Enforcement Technology.

For MPX prefix:
GCC have not supported the MPX from GCC 9. And intel will not support MPX code too. So we don’t consider MPX for CET in LLD.

Dec 11 2019, 11:48 PM · Restricted Project
xiangzhangllvm added a comment to D59780: Support Intel Control-flow Enforcement Technology.

Apply two patches

-  uint64_t Plt = In.Plt->getVA();
+  uint64_t Plt = In.IBTPlt ? In.IBTPlt->getVA() : In.Plt->getVA();
--- i/lld/ELF/Driver.cpp
+++ w/lld/ELF/Driver.cpp
@@ -1705,2 +1705,4 @@ template <class ELFT> static uint32_t getAndFeatures() {
-    } else if (!features && config->requireCET)
-      error(toString(f) + ": --require-cet: file is not compatible with CET");
+    } else if (config->requireCET && !(features & GNU_PROPERTY_X86_FEATURE_1_IBT)) {
+      warn(toString(f) + ": --require-cet: file is not compatible with CET");
+      features |= GNU_PROPERTY_X86_FEATURE_1_IBT;
+    }

@xiangzhangllvm The previous version I uploaded definitely did not work. I just applied a fix. Both i386 and x86_64 seem to work now, but there are still problems with the tests.

You need either arc patch D59780 or curl -L 'https://reviews.llvm.org/D59780?download=true' | patch -p1 to apply the latest diff in your local repository.

I have a separate patch to rename lld --force-bti to -z force-bti. I think --force-ibt or -z force-ibt may make more sense than --require-cet.

Dec 11 2019, 6:07 PM · Restricted Project

Dec 10 2019

xiangzhangllvm added a comment to D59780: Support Intel Control-flow Enforcement Technology.

Remove the "-plugin xxx", also work.

Dec 10 2019, 11:37 PM · Restricted Project
xiangzhangllvm added a comment to D59780: Support Intel Control-flow Enforcement Technology.
> gcc -fcf-protection=full -c a.c
> gcc -fcf-protection=full a.c -o a '-###'   # Retrieve linker command line, replace ld with
Dec 10 2019, 11:28 PM · Restricted Project
xiangzhangllvm added inline comments to D59780: Support Intel Control-flow Enforcement Technology.
Dec 10 2019, 9:47 PM · Restricted Project
xiangzhangllvm added a comment to D59780: Support Intel Control-flow Enforcement Technology.

This patch is outdated and needs rebasing. I'll rebase, upload it again and then submit.

Hi ruiu, just remind, if you have no time, I can rebase it.

I can do that, too, and cleaning the test.

Dec 10 2019, 5:23 PM · Restricted Project
xiangzhangllvm added a comment to D59780: Support Intel Control-flow Enforcement Technology.

This patch is outdated and needs rebasing. I'll rebase, upload it again and then submit.

Dec 10 2019, 4:46 PM · Restricted Project

Nov 14 2019

xiangzhangllvm added a comment to D70157: Align branches within 32-Byte boundary(NOP padding).

On x86, the preferred function alignment is 16 (https://github.com/llvm/llvm-project/blob/arcpatch-D70157/llvm/lib/Target/X86/X86ISelLowering.cpp#L1893), which is the default function alignment in text sections. If the cross-boundary decision is made with alignment=32 (--x86-align-branch-boundary=32) in mind, and the section alignment is still 16 (not increased to 32 or higher), the linker may place the section at an address which equals 16 modulo 32, the section contents will thus shift by 16. The instructions that do not cross the boundary in the object files may cross the boundary in the linker output. Have you considered increasing the section alignment to 32?

Shall we default to -mbranches-within-32B-boundaries if the specified -march= or -mtune= may be affected by the erratum?

Nov 14 2019, 5:49 PM · Restricted Project, Restricted Project

Nov 12 2019

xiangzhangllvm added inline comments to D70157: Align branches within 32-Byte boundary(NOP padding).
Nov 12 2019, 7:35 PM · Restricted Project, Restricted Project
xiangzhangllvm added inline comments to D70157: Align branches within 32-Byte boundary(NOP padding).
Nov 12 2019, 7:25 PM · Restricted Project, Restricted Project

Aug 10 2019

xiangzhangllvm updated the diff for D65840: [X86] Support -march=tigerlake.
Aug 10 2019, 1:20 AM · Restricted Project
xiangzhangllvm added inline comments to D65840: [X86] Support -march=tigerlake.
Aug 10 2019, 1:19 AM · Restricted Project
xiangzhangllvm updated the diff for D65840: [X86] Support -march=tigerlake.
Aug 10 2019, 12:08 AM · Restricted Project
xiangzhangllvm added a comment to D65840: [X86] Support -march=tigerlake.

Done again, thank you again!!

Aug 10 2019, 12:08 AM · Restricted Project
xiangzhangllvm added inline comments to D65840: [X86] Support -march=tigerlake.
Aug 10 2019, 12:00 AM · Restricted Project

Aug 9 2019

xiangzhangllvm added a comment to D65840: [X86] Support -march=tigerlake.

All changed, Thank you very much!

Aug 9 2019, 2:04 AM · Restricted Project
xiangzhangllvm updated the diff for D65840: [X86] Support -march=tigerlake.
Aug 9 2019, 2:03 AM · Restricted Project

Aug 8 2019

xiangzhangllvm added inline comments to D65840: [X86] Support -march=tigerlake.
Aug 8 2019, 7:40 PM · Restricted Project

Aug 6 2019

xiangzhangllvm retitled D65840: [X86] Support -march=tigerlake from Tigerlake to [X86] Support -march=tigerlake.
Aug 6 2019, 6:22 PM · Restricted Project
xiangzhangllvm created D65840: [X86] Support -march=tigerlake.
Aug 6 2019, 6:11 PM · Restricted Project

May 30 2019

xiangzhangllvm added a comment to D62367: [X86] VP2INTERSECT clang.

Done, Thank you very much!

May 30 2019, 8:02 PM · Restricted Project, Restricted Project
xiangzhangllvm updated the diff for D62367: [X86] VP2INTERSECT clang.
May 30 2019, 7:57 PM · Restricted Project, Restricted Project
xiangzhangllvm added a reviewer for D62367: [X86] VP2INTERSECT clang: smaslov.
May 30 2019, 6:38 PM · Restricted Project, Restricted Project
xiangzhangllvm added a reviewer for D62366: [X86] VP2INTERSECT llvm: smaslov.
May 30 2019, 6:36 PM · Restricted Project
xiangzhangllvm added a comment to D62366: [X86] VP2INTERSECT llvm.

Hi Dear friends, could you help merge this patch? Thank you very much!

May 30 2019, 6:31 PM · Restricted Project
xiangzhangllvm added a comment to D62367: [X86] VP2INTERSECT clang.

Hi Dear friends, could you help merge this patch? Thank you very much!

May 30 2019, 6:31 PM · Restricted Project, Restricted Project
xiangzhangllvm updated the diff for D62366: [X86] VP2INTERSECT llvm.

rebase

May 30 2019, 6:28 PM · Restricted Project
xiangzhangllvm updated the diff for D62367: [X86] VP2INTERSECT clang.

rebase

May 30 2019, 6:28 PM · Restricted Project, Restricted Project

May 28 2019

xiangzhangllvm added a comment to D59780: Support Intel Control-flow Enforcement Technology.

I'm sorry, I reflect the problem to some leaders and experts, but the PLT ABI is still undecided. The most concern come from the unknow risk of difference with GNU.

@xiangzhangllvm If it is still undecided, then there is still opportunity to fix :) IMHO tooling is still immature and currently very few tools understand .plt.sec.

I'd really like to see more discussions about this, e.g. https://groups.google.com/forum/#!topic/x86-64-abi/Z6GqQDy_NaI
If PLT entries should be aligned by 16 to maximize performance, shall we switch to 32-byte PLT entry? Xiang, can you raise a topic on https://sourceware.org/ml/gnu-gabi/2019-q2 or https://sourceware.org/ml/binutils/2019-05/

May 28 2019, 8:09 PM · Restricted Project
xiangzhangllvm added a comment to D59780: Support Intel Control-flow Enforcement Technology.

I'm sorry, I reflect the problem to some leaders and experts, but the PLT ABI is still undecided. The most concern come from the unknow risk of difference with GNU.

May 28 2019, 7:01 PM · Restricted Project
xiangzhangllvm updated the diff for D62367: [X86] VP2INTERSECT clang.

rebase

May 28 2019, 6:26 PM · Restricted Project, Restricted Project
xiangzhangllvm updated the diff for D62366: [X86] VP2INTERSECT llvm.

rebase

May 28 2019, 6:22 PM · Restricted Project
xiangzhangllvm added inline comments to D62367: [X86] VP2INTERSECT clang.
May 28 2019, 4:41 AM · Restricted Project, Restricted Project

May 27 2019

xiangzhangllvm updated the diff for D62366: [X86] VP2INTERSECT llvm.
May 27 2019, 11:59 PM · Restricted Project
xiangzhangllvm updated the diff for D62367: [X86] VP2INTERSECT clang.
May 27 2019, 11:59 PM · Restricted Project, Restricted Project
xiangzhangllvm added inline comments to D62367: [X86] VP2INTERSECT clang.
May 27 2019, 10:40 PM · Restricted Project, Restricted Project
xiangzhangllvm updated the diff for D62367: [X86] VP2INTERSECT clang.
May 27 2019, 9:54 PM · Restricted Project, Restricted Project
xiangzhangllvm updated the diff for D62366: [X86] VP2INTERSECT llvm.
May 27 2019, 9:52 PM · Restricted Project

May 24 2019

xiangzhangllvm updated the diff for D62366: [X86] VP2INTERSECT llvm.

Rename tests in test/CodeGen/X86

May 24 2019, 1:40 AM · Restricted Project
xiangzhangllvm updated the diff for D62366: [X86] VP2INTERSECT llvm.

rebase

May 24 2019, 1:12 AM · Restricted Project
xiangzhangllvm updated the diff for D62367: [X86] VP2INTERSECT clang.

rebase

May 24 2019, 1:11 AM · Restricted Project, Restricted Project

May 23 2019

xiangzhangllvm created D62367: [X86] VP2INTERSECT clang.
May 23 2019, 11:55 PM · Restricted Project, Restricted Project
xiangzhangllvm created D62366: [X86] VP2INTERSECT llvm.
May 23 2019, 11:54 PM · Restricted Project

May 21 2019

xiangzhangllvm added a reviewer for D61881: Deal with return-twice function such as vfork, setjmp when CET-IBT enabled: pengfei.
May 21 2019, 5:20 PM · Restricted Project

May 20 2019

xiangzhangllvm added inline comments to D62115: fix a issue that clang is incompatible with gcc with -H option..
May 20 2019, 12:14 AM · Restricted Project

May 16 2019

xiangzhangllvm updated the diff for D61881: Deal with return-twice function such as vfork, setjmp when CET-IBT enabled.
May 16 2019, 7:14 PM · Restricted Project
xiangzhangllvm added inline comments to D61881: Deal with return-twice function such as vfork, setjmp when CET-IBT enabled.
May 16 2019, 6:28 PM · Restricted Project
xiangzhangllvm added inline comments to D61881: Deal with return-twice function such as vfork, setjmp when CET-IBT enabled.
May 16 2019, 6:22 PM · Restricted Project

May 15 2019

xiangzhangllvm updated the diff for D61881: Deal with return-twice function such as vfork, setjmp when CET-IBT enabled.
May 15 2019, 7:36 PM · Restricted Project
xiangzhangllvm added inline comments to D61881: Deal with return-twice function such as vfork, setjmp when CET-IBT enabled.
May 15 2019, 6:42 PM · Restricted Project

May 14 2019

xiangzhangllvm added a comment to D61881: Deal with return-twice function such as vfork, setjmp when CET-IBT enabled.

Thank You very much! Fangrui

May 14 2019, 7:58 PM · Restricted Project
xiangzhangllvm updated the diff for D61881: Deal with return-twice function such as vfork, setjmp when CET-IBT enabled.
May 14 2019, 7:55 PM · Restricted Project
xiangzhangllvm added inline comments to D61881: Deal with return-twice function such as vfork, setjmp when CET-IBT enabled.
May 14 2019, 6:02 PM · Restricted Project

May 13 2019

xiangzhangllvm created D61881: Deal with return-twice function such as vfork, setjmp when CET-IBT enabled.
May 13 2019, 11:00 PM · Restricted Project

Apr 18 2019

xiangzhangllvm added a comment to D59780: Support Intel Control-flow Enforcement Technology.

Hi friends, I write a simple test to test the performance:
To simply test the performance affect I changed the PLT size from 16 Bytes to 24Bytes in LLVM 8.0.0.

[xiangzh1@scels74 /export/iusers/xiangzh1/LLVM/LLVMORG]$diff llvm800/tools/lld/ELF/Arch/X86_64.cpp llvm800-PLT24/tools/lld/ELF/Arch/X86_64.cpp
67c67
<   PltEntrySize = 16;
---
>   PltEntrySize = 24; //16-->24
157a158,159
>       0x66, 0x90,                   //nop
>       0x66, 0x0f, 0x1f, 0x44, 0, 0, // nop
[xiangzh1@scels74 /export/iusers/xiangzh1/LLVM/LLVMORG]$

Then I write a simple case like following:

Apr 18 2019, 8:20 PM · Restricted Project

Apr 17 2019

xiangzhangllvm added a comment to D59780: Support Intel Control-flow Enforcement Technology.

We are Ok with with the 2-PLT scheme.

Apr 17 2019, 6:20 PM · Restricted Project

Apr 16 2019

xiangzhangllvm added a comment to D59780: Support Intel Control-flow Enforcement Technology.

Hi Ruiu & Fangrui
Your idea is also make sense, but It is really too too late to change ABI now.
I wish we can reach a consensus as soon as possible.
Thank you all, very much!

Apr 16 2019, 1:11 AM · Restricted Project

Apr 2 2019

xiangzhangllvm added a comment to D59780: Support Intel Control-flow Enforcement Technology.

Hi MaskRay, I tested your idea by changing the patch:

Apr 2 2019, 7:48 PM · Restricted Project

Apr 1 2019

xiangzhangllvm added inline comments to D59780: Support Intel Control-flow Enforcement Technology.
Apr 1 2019, 4:22 AM · Restricted Project
xiangzhangllvm added inline comments to D59780: Support Intel Control-flow Enforcement Technology.
Apr 1 2019, 1:09 AM · Restricted Project

Mar 31 2019

xiangzhangllvm added inline comments to D59780: Support Intel Control-flow Enforcement Technology.
Mar 31 2019, 8:35 PM · Restricted Project

Mar 28 2019

xiangzhangllvm added inline comments to D59780: Support Intel Control-flow Enforcement Technology.
Mar 28 2019, 10:09 PM · Restricted Project

Mar 26 2019

xiangzhangllvm added inline comments to D59780: Support Intel Control-flow Enforcement Technology.
Mar 26 2019, 7:16 PM · Restricted Project
xiangzhangllvm added a comment to D59780: Support Intel Control-flow Enforcement Technology.

So on the compiler driver side, -fcf-protection is the single option end users are concerned. I believe this option hasn't been assigned linker option semantics in either GCC or clang. If assigning it the linker option semantics is favorable, we should make it compatible in GCC/clang and ideally use the same options in lld/ld.bfd/gold.

The current form of this patch just implements --force-cet, thus I believe the use cases are:

gcc a.o -o a # create `.splt` (or `.plt.sec`) if all of a.o and other stdlib have IBT bit set
             # I worry that someone may not want .splt for this case
  ld.lld a.o ... -o a

If all the files contain IBT, it means all the files compiled with -fcf-protection(=branch) ,there is no reason for user not to enable the IBT.

Mar 26 2019, 6:53 PM · Restricted Project