[PATCH] D88194: [X86] CET endbr enhance

Craig Topper via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sat Oct 10 10:33:01 PDT 2020


craig.topper added a comment.

In D88194#2323402 <https://reviews.llvm.org/D88194#2323402>, @spatel wrote:

> In D88194#2323400 <https://reviews.llvm.org/D88194#2323400>, @spatel wrote:
>
>> In D88194#2323095 <https://reviews.llvm.org/D88194#2323095>, @xiangzhangllvm wrote:
>>
>>> In D88194#2322366 <https://reviews.llvm.org/D88194#2322366>, @spatel wrote:
>>>
>>>> Ok, I don't have any other questions/comments (other than it would still be helpful to reduce/pre-commit the tests).
>>>
>>> Done, then update the tests.
>>
>> Thanks! That makes it easier to see how things are changing with this patch.
>> In addition to @craig.topper 's question about endbr32, shouldn't we have a test that checks for multiple and different prefix bytes? If I am seeing correctly, there is only 1 test checking for a single `0x2E` optional prefix.
>
> Thinking about this a bit more: if the attacker can recognize multiple different optional prefix bytes, then is there much value in complementing those bytes? They are already searching for a match from some dictionary of byte strings, so inverting the bits just means they need to increase their search by 2x?

I'm not sure I follow. If the bytes are inverted in the binary then they are no longer useful to the attacker. The goal here is to make sure that if an attacker gains control of the register or memory location used by an indirect call or jump that they can't jump to an immediate in the binary that matches the encoding for ENDBR. As that would convince the CET protection that this a place that an indirect jump was expected to be able to jump to.


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

https://reviews.llvm.org/D88194



More information about the llvm-commits mailing list