[PATCH] D88194: [X86] CET endbr enhance

Sanjay Patel via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Oct 9 10:51:04 PDT 2020


spatel added a comment.

In D88194#2322158 <https://reviews.llvm.org/D88194#2322158>, @craig.topper wrote:

> In D88194#2321872 <https://reviews.llvm.org/D88194#2321872>, @spatel wrote:
>
>> In D88194#2318848 <https://reviews.llvm.org/D88194#2318848>, @xiangzhangllvm wrote:
>>
>>> CET adds an Indirect Branch Tracking capability (by inserting Endbr instruction at the destination of the indirect branch) to provide software the ability to restrict COP/JOP attacks.
>>
>> Ok, I understand that much. But it is still not clear to me why this patch is re-using the "-x86-indirect-branch-tracking" option. Is this obscuring of the opcode not independent of producing the instruction? I would again suggest that we pre-commit some tests, so we can see only the diffs in the codegen (and if inserting "endb64" itself is a requirement to obscure the opcode, please add comments in the test file to explain that).
>
> I suggested adding that the -x86-indirect-branch-tracking check because it seemed like we'd only want to do this in a binary that was expected to contain endbr opcodes. Putting things that could be confused for endbr opcodes in a binary that doesn't enable CET should be harmless.

Is this patch designed to change the compiler itself? Ie, we would enable this obfuscation mechanism while building clang, then use the newly built clang with the existing cl::opt flag to build an app that contains endbr instructions that are constructed in the convoluted way? We don't care if the compiler is littered with endbr itself?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88194/new/

https://reviews.llvm.org/D88194



More information about the llvm-commits mailing list