On 26.11.2021 14:13, Andrew Cooper wrote: > On 26/11/2021 12:48, Jan Beulich wrote: >> On 26.11.2021 13:33, Andrew Cooper wrote: >>> * I have not checked for misaligned endbr64's, and I'm not sure there is >>> anything useful we could do upon discovering that there were any. >>> Naively, there is a 1 in 2^32 chance (endbr64 being 4 bytes long), but >>> this doesn't account for the structure of x86 code, which is most >>> certainly not a uniform random distribution of bytes. >> Do you really mean "misaligned" here? The 2nd sentence rather might suggest >> that you mean byte sequences resembling ENDBR, despite actually being part >> of other insns. If so, checking might not allow to prove anything, as e.g. >> displacements change with about every build. > > I do mean "any sequence of bytes resembling ENDBR", because that is > ultimately how the CPU instruction decode will behave. > > And yes - you certainly can hide it in a 4-byte disp/imm, but it's an > incredibly rare imm32 to find (except for tasks such as in patch 64).
A disp alone won't do in general, as the top byte will only ever be 0x00 or 0xFF (as long as our binary image doesn't go beyond 16Mb). But a ModR/M or SIB byte could start such a sequence, with only two or three of the (lower) disp bytes used to complete the pattern. > You can also hide it in an disp/imm8 followed by a specific nopl, but > I'm not sure if we'd ever emit 0F 1E FA as a nopl by default. We don't, and the tool chain doesn't either. Only canonical NOPs (opcode 0x1F) are to be used there, as all others may gain a meaning beyond plain NOP. Jan
