[llvm-dev] RFC: No Control Flow Check Attribute

[Ben Simhon, Oren via llvm-dev]

Hi All,

Jump Oriented Programming attacks rely on tampering addresses used by indirect call / jmp, e.g. redirect control-flow to non-programmer intended bytes in binary.
A new target independent command line option -fcf-protection=<branch/return/full/none> instruments control flow protection schemes to handle such attacks.
X86 Supports Indirect Branch Tracking (IBT) as part of Control-Flow Enforcement Technology (CET).
IBT instruments ENDBR instructions (when -fcf-protection=branch is asserted) used to specify valid targets of indirect call / jmp.

The `nocf_check`  attribute indicates that no control-flow check will be performed on the attributed entity.
It disables -fcf-protection=<> for a specific entity to fine grain the HW control flow protection mechanism.
The flag is target independent and currently appertains to a function or function pointer.

The `nocf_check` attribute has two roles in the context of X86 IBT technology:
1.      Appertains to a function - do not add ENDBR instruction at the beginning of the function.
2.      Appertains to a function pointer - do not track the target function of this pointer by adding nocf_check prefix to the indirect-call instruction.

When the CPU decodes `nocf_check` prefix, it will not update IBT state machine, hence, the target addresses of the following indirect jump will not be tracked.

The naming convention and implementation follow GCC.
I will be happy to address any concerns raised by the community regarding the attribute.


Cheers,
Oren

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180131/47ca3844/attachment-0001.html>