Re: [PATCH 01/65] x86: Introduce support for CET-IBT

[Andrew Cooper <amc96@xxxxxxxx>]

On 26/11/2021 14:10, Jan Beulich wrote:
> On 26.11.2021 13:33, Andrew Cooper wrote:
>> @@ -124,6 +129,18 @@ config XEN_SHSTK
>>        When CET-SS is active, 32bit PV guests cannot be used.  Backwards
>>        compatiblity can be provided via the PV Shim mechanism.
>>  
>> +config XEN_IBT
>> +    bool "Supervisor Indirect Branch Tracking"
>> +    depends on HAS_CC_CET_IBT
>> +    default y
>> +    help
>> +      Control-flow Enforcement Technology (CET) is a set of features in
>> +      hardware designed to combat Return-oriented Programming (ROP, also
>> +      call/jump COP/JOP) attacks.  Indirect Branch Tracking is one CET
>> +      feature designed to provide function pointer protection.
>> +
>> +      This option arranges for Xen to use CET-IBT for its own protection.
> Shouldn't this depend on BROKEN until it's actually functional?

It compiles fine right from now, and making it BROKEN would inhibit
bisection through the series.

Nothing actually matters until patch 65 turns on MSR_S_CET.ENDBR_EN.

>> --- a/xen/arch/x86/x86_emulate/x86_emulate.h
>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.h
>> @@ -35,6 +35,11 @@
>>  # error Unknown compilation width
>>  #endif
>>  
>> +#ifndef cf_check
>> +/* Cope with userspace build not knowing about CET-IBT */
>> +#define cf_check
>> +#endif
> Imo this shouldn't go here, but in tools/tests/x86_emulator/x86-emulate.h,
> and then presumably without #ifdef.

I considered that, but the test harness isn't the only userspace
harness.  There is the fuzzing harness too, and I'm not sure we want to
force every userspace harness to provide the same workaround.

~Andrew