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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 26.11.2021 13:33, Andrew Cooper wrote:
> CET Indirect Branch Tracking is a hardware feature designed to protect against
> forward-edge control flow hijacking (Call/Jump oriented programming), and is a
> companion feature to CET Shadow Stacks added in Xen 4.14.
> 
> This series depends on lots of previously posted patches.  See
> xenbits/xen-cet-ibt for the full branch with all dependencies.
> 
> Patch 1 introduces some compile time infrastructure.
> 
> Patches 2 thru 56 annotate all function pointer targets in the common and x86
> hypervisor code.  Patches are split by API and in no particular order, and
> largely mechanical.  As such, I'm limiting review mainly to The Rest.  While
> doing this work does depend on an experimental GCC change (patch 56), the
> result does actually work properly with GCC 9 onwards.

I wonder what this means. Are you talking about a gcc 9 with the experimental
change backported? Or are you saying that things build fine there (but don't
work as far as IBT is concerned) in the absence of the experimental change?
In which case what about older gcc?

> 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.

Jan