Taking a look at the endbr64 instruction, its encoding is listed in the SDM as F3 0F 1E FA. From what I can find, most discussion around this instruction seems to assume exactly this 4-byte sequence and how to construct - or prevent the construction of - gadgets containing this exact sequence. However, given that the instruction is composed of a mandatory F3 prefix followed by a specific long-NOP enocding, a question arises of whether the instruction remains a valid CET end-branch instruction if more prefixes are added. If so, there seems to be a possible security issue in that it becomes possible to create an endbr64 instruction/gadget that does not contain the exact 4-byte sequence F3 0F 1E FA.
For a specific example, consider the encoding F3 3E 0F 1E FA (that adds a useless DS prefix). Should this encoding be recognized as a valid endbr64 instruction? (xed -64 -cet -d F3 3E 0F 1E FA currently recognizes it as such.)
Taking a look at the
endbr64instruction, its encoding is listed in the SDM asF3 0F 1E FA. From what I can find, most discussion around this instruction seems to assume exactly this 4-byte sequence and how to construct - or prevent the construction of - gadgets containing this exact sequence. However, given that the instruction is composed of a mandatoryF3prefix followed by a specific long-NOP enocding, a question arises of whether the instruction remains a valid CET end-branch instruction if more prefixes are added. If so, there seems to be a possible security issue in that it becomes possible to create anendbr64instruction/gadget that does not contain the exact 4-byte sequenceF3 0F 1E FA.For a specific example, consider the encoding
F3 3E 0F 1E FA(that adds a useless DS prefix). Should this encoding be recognized as a validendbr64instruction? (xed -64 -cet -d F3 3E 0F 1E FAcurrently recognizes it as such.)