On 26.11.2021 16:21, Andrew Cooper wrote:
> 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.
"Nothing" except that until then the promised extra security isn't
there.
>>> --- 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.
But that's the idea of putting it where I suggested: This header gets
re-used by the fuzzing harness:
x86-emulate.c x86-emulate.h wrappers.c: %:
[ -L $* ] || ln -sf $(XEN_ROOT)/tools/tests/x86_emulator/$*
Jan
