Re: [PATCH 00/65] x86: Support for CET Indirect Branch Tracking

[Andrew Cooper <amc96@xxxxxxxx>]

On 26/11/2021 13:13, Andrew Cooper wrote:
> On 26/11/2021 12:48, Jan Beulich wrote:
>> On 26.11.2021 13:33, Andrew Cooper wrote:
>>> Various note accumulated through the work:
>>>   * I have already posted patches fixing some of the most egregious 
>>> (ab)uses of
>>>     function pointers.  There are plenty of other areas which could do with
>>>     cleanup.
>>>   * With everything turned on, we get 1688 runtime endbr64's, and 233 init
>>>     time.  The number of runtime endbr64's is expected to reduce with
>>>     Juergen's hypercall series (see later), and in common deployment cases
>>>     where not everything is compiled in by default.
>>>   * 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).

To this point, I have a cunning idea.  I'll write a custom is_endbr64()
helper which reads a dword, not's it, and then compares to imm32.  That
is for all intents and purposes the same performance, but doesn't have
an embedded endbr64.

~Andrew