On 11.01.2023 22:05, Andrew Cooper wrote:
> On 13/12/2022 4:31 pm, Roger Pau Monne wrote:
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -1428,10 +1428,19 @@ static void cf_check vmx_update_host_cr3(struct vcpu
>> *v)
>>
>> void vmx_update_debug_state(struct vcpu *v)
>> {
>> + unsigned int mask = 1u << TRAP_int3;
>> +
>> + if ( !cpu_has_monitor_trap_flag && cpu_has_vmx_notify_vm_exiting )
>> + /*
>> + * Only allow toggling TRAP_debug if notify VM exit is enabled, as
>> + * unconditionally setting TRAP_debug is part of the XSA-156 fix.
>> + */
>> + mask |= 1u << TRAP_debug;
>> +
>> if ( v->arch.hvm.debug_state_latch )
>> - v->arch.hvm.vmx.exception_bitmap |= 1U << TRAP_int3;
>> + v->arch.hvm.vmx.exception_bitmap |= mask;
>> else
>> - v->arch.hvm.vmx.exception_bitmap &= ~(1U << TRAP_int3);
>> + v->arch.hvm.vmx.exception_bitmap &= ~mask;
>>
>> vmx_vmcs_enter(v);
>> vmx_update_exception_bitmap(v);
>> @@ -4180,6 +4189,9 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
>> switch ( vector )
>> {
>> case TRAP_debug:
>> + if ( cpu_has_monitor_trap_flag && cpu_has_vmx_notify_vm_exiting
>> )
>> + goto exit_and_crash;
>
> This breaks GDBSX and introspection.
>
> For XSA-156, we were forced to intercept #DB unilaterally for safety,
> but both GDBSX and Introspection can optionally intercepting #DB for
> logical reasons too.
>
> i.e. we can legitimately end up here even on an system with VM Notify.
>
>
> What I can't figure out is why made any reference to MTF. MTF has
> absolutely nothing to do with TRAP_debug.
Looking back I see that the two seemingly asymmetric conditions puzzled
me during review, but for some reason I didn't question the MTF part
as a whole; I think I simply wasn't sure and hence left it to the
VMX maintainers. I think you're right and that part of the condition
wants deleting from vmx_update_debug_state() (on top of deleting the
entire if() above).
> Furthermore, there's no CPU in practice that has VM Notify but lacks
> MTF, so the head of vmx_update_debug_state() looks like dead code...
"No CPU in practice" is not an applicable argument as long as the spec
doesn't spell out a connection. When running virtualized ourselves, any
valid feature combination may be found (seeing that we similarly
may ourselves surface feature combinations to guests which no real
hardware equivalent exists for).
Jan
