On 15.08.2022 11:33, Andrew Cooper wrote:
> On 15/08/2022 09:26, Jan Beulich wrote:
>> On 05.08.2022 12:38, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/spec_ctrl.c
>>> +++ b/xen/arch/x86/spec_ctrl.c
>>> @@ -1327,8 +1327,24 @@ void __init init_speculation_mitigations(void)
>>> * mappings.
>>>
On 15/08/2022 09:26, Jan Beulich wrote:
> On 05.08.2022 12:38, Andrew Cooper wrote:
>> --- a/xen/arch/x86/spec_ctrl.c
>> +++ b/xen/arch/x86/spec_ctrl.c
>> @@ -1327,8 +1327,24 @@ void __init init_speculation_mitigations(void)
>> * mappings.
>> */
>> if ( opt_rsb_hvm )
>> +{
>>
On 05.08.2022 12:38, Andrew Cooper wrote:
> --- a/xen/arch/x86/spec_ctrl.c
> +++ b/xen/arch/x86/spec_ctrl.c
> @@ -1327,8 +1327,24 @@ void __init init_speculation_mitigations(void)
> * mappings.
> */
> if ( opt_rsb_hvm )
> +{
> setup_force_cpu_cap(X86_FEATURE_SC_RSB_HVM
On 05.08.2022 12:38, Andrew Cooper wrote:
> There is a corner case where a VT-x guest which manages to reliably trigger
> non-fatal #MC's could evade the rogue RSB speculation protections that were
> supposed to be in place.
>
> This is a lack of defence in depth; Xen does not architecturally exec
There is a corner case where a VT-x guest which manages to reliably trigger
non-fatal #MC's could evade the rogue RSB speculation protections that were
supposed to be in place.
This is a lack of defence in depth; Xen does not architecturally execute more
RET than CALL instructions, so an attacker
