[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 00/65] x86: Support for CET Indirect Branch Tracking
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |