LinuxLists.cc - [Question] int3 instruction generates a #UD in SEV VM

[permalink] [raw]

Subject: Re: [Question] int3 instruction generates a #UD in SEV VM

On 7/31/23 09:30, Sean Christopherson wrote:
> On Sat, Jul 29, 2023, wuzongyong wrote:
>> Hi,
>> I am writing a firmware in Rust to support SEV based on project td-shim[1].
>> But when I create a SEV VM (just SEV, no SEV-ES and no SEV-SNP) with the firmware,
>> the linux kernel crashed because the int3 instruction in int3_selftest() cause a
>> #UD.
>
> ...
>
>> BTW, if a create a normal VM without SEV by qemu & OVMF, the int3 instruction always generates a
>> #BP.
>> So I am confused now about the behaviour of int3 instruction, could anyone help to explain the behaviour?
>> Any suggestion is appreciated!
>
> Have you tried my suggestions from the other thread[*]?
>
> : > > I'm curious how this happend. I cannot find any condition that would
> : > > cause the int3 instruction generate a #UD according to the AMD's spec.
> :
> : One possibility is that the value from memory that gets executed diverges from the
> : value that is read out be the #UD handler, e.g. due to patching (doesn't seem to
> : be the case in this test), stale cache/tlb entries, etc.
> :
> : > > BTW, it worked nomarlly with qemu and ovmf.
> : >
> : > Does this happen every time you boot the guest with your firmware? What
> : > processor are you running on?
> :
> : And have you ruled out KVM as the culprit? I.e. verified that KVM is NOT injecting
> : a #UD. That obviously shouldn't happen, but it should be easy to check via KVM
> : tracepoints.

I have a feeling that KVM is injecting the #UD, but it will take
instrumenting KVM to see which path the #UD is being injected from.

Wu Zongyo, can you add some instrumentation to figure that out if the
trace points towards KVM injecting the #UD?

Thanks,
Tom

>
> [*] https://lore.kernel.org/all/[email protected]

2023-07-31 16:33:17

[permalink] [raw]

Subject: Re: [Question] int3 instruction generates a #UD in SEV VM

On 2023/7/31 23:03, Tom Lendacky wrote:
> On 7/31/23 09:30, Sean Christopherson wrote:
>> On Sat, Jul 29, 2023, wuzongyong wrote:
>>> Hi,
>>> I am writing a firmware in Rust to support SEV based on project td-shim[1].
>>> But when I create a SEV VM (just SEV, no SEV-ES and no SEV-SNP) with the firmware,
>>> the linux kernel crashed because the int3 instruction in int3_selftest() cause a
>>> #UD.
>>
>> ...
>>
>>> BTW, if a create a normal VM without SEV by qemu & OVMF, the int3 instruction always generates a
>>> #BP.
>>> So I am confused now about the behaviour of int3 instruction, could anyone help to explain the behaviour?
>>> Any suggestion is appreciated!
>>
>> Have you tried my suggestions from the other thread[*]?
Firstly, I'm sorry for sending muliple mails with the same content. I thought the mails I sent previously
didn't be sent successfully.
And let's talk the problem here.
>>
>>    : > > I'm curious how this happend. I cannot find any condition that would
>>    : > > cause the int3 instruction generate a #UD according to the AMD's spec.
>>    :
>>    : One possibility is that the value from memory that gets executed diverges from the
>>    : value that is read out be the #UD handler, e.g. due to patching (doesn't seem to
>>    : be the case in this test), stale cache/tlb entries, etc.
>>    :
>>    : > > BTW, it worked nomarlly with qemu and ovmf.
>>    : >
>>    : > Does this happen every time you boot the guest with your firmware? What
>>    : > processor are you running on?
>>    :
Yes, every time.
The processor I used is EPYC 7T83.
>>    : And have you ruled out KVM as the culprit? I.e. verified that KVM is NOT injecting
>>    : a #UD. That obviously shouldn't happen, but it should be easy to check via KVM
>>    : tracepoints.
>
> I have a feeling that KVM is injecting the #UD, but it will take instrumenting KVM to see which path the #UD is being injected from.
>
> Wu Zongyo, can you add some instrumentation to figure that out if the trace points towards KVM injecting the #UD?
Ok, I will try to do that.
>
> Thanks,
> Tom
>
>>
>> [*] https://lore.kernel.org/all/[email protected]

2023-07-31 17:06:52

[permalink] [raw]

Subject: Re: [Question] int3 instruction generates a #UD in SEV VM

On Sat, Jul 29, 2023, wuzongyong wrote:
> Hi,
> I am writing a firmware in Rust to support SEV based on project td-shim[1].
> But when I create a SEV VM (just SEV, no SEV-ES and no SEV-SNP) with the firmware,
> the linux kernel crashed because the int3 instruction in int3_selftest() cause a
> #UD.

...

> BTW, if a create a normal VM without SEV by qemu & OVMF, the int3 instruction always generates a
> #BP.
> So I am confused now about the behaviour of int3 instruction, could anyone help to explain the behaviour?
> Any suggestion is appreciated!

Have you tried my suggestions from the other thread[*]?

: > > I'm curious how this happend. I cannot find any condition that would
: > > cause the int3 instruction generate a #UD according to the AMD's spec.
:
: One possibility is that the value from memory that gets executed diverges from the
: value that is read out be the #UD handler, e.g. due to patching (doesn't seem to
: be the case in this test), stale cache/tlb entries, etc.
:
: > > BTW, it worked nomarlly with qemu and ovmf.
: >
: > Does this happen every time you boot the guest with your firmware? What
: > processor are you running on?
:
: And have you ruled out KVM as the culprit? I.e. verified that KVM is NOT injecting
: a #UD. That obviously shouldn't happen, but it should be easy to check via KVM
: tracepoints.

[*] https://lore.kernel.org/all/[email protected]

2023-08-02 14:26:05

[permalink] [raw]

Subject: Re: [Question] int3 instruction generates a #UD in SEV VM

On Mon, Jul 31, 2023 at 11:45:29PM +0800, wuzongyong wrote:
>
> On 2023/7/31 23:03, Tom Lendacky wrote:
> > On 7/31/23 09:30, Sean Christopherson wrote:
> >> On Sat, Jul 29, 2023, wuzongyong wrote:
> >>> Hi,
> >>> I am writing a firmware in Rust to support SEV based on project td-shim[1].
> >>> But when I create a SEV VM (just SEV, no SEV-ES and no SEV-SNP) with the firmware,
> >>> the linux kernel crashed because the int3 instruction in int3_selftest() cause a
> >>> #UD.
> >>
> >> ...
> >>
> >>> BTW, if a create a normal VM without SEV by qemu & OVMF, the int3 instruction always generates a
> >>> #BP.
> >>> So I am confused now about the behaviour of int3 instruction, could anyone help to explain the behaviour?
> >>> Any suggestion is appreciated!
> >>
> >> Have you tried my suggestions from the other thread[*]?
> Firstly, I'm sorry for sending muliple mails with the same content. I thought the mails I sent previously
> didn't be sent successfully.
> And let's talk the problem here.
> >>
> >> : > > I'm curious how this happend. I cannot find any condition that would
> >> : > > cause the int3 instruction generate a #UD according to the AMD's spec.
> >> :
> >> : One possibility is that the value from memory that gets executed diverges from the
> >> : value that is read out be the #UD handler, e.g. due to patching (doesn't seem to
> >> : be the case in this test), stale cache/tlb entries, etc.
> >> :
> >> : > > BTW, it worked nomarlly with qemu and ovmf.
> >> : >
> >> : > Does this happen every time you boot the guest with your firmware? What
> >> : > processor are you running on?
> >> :
> Yes, every time.
> The processor I used is EPYC 7T83.
> >> : And have you ruled out KVM as the culprit? I.e. verified that KVM is NOT injecting
> >> : a #UD. That obviously shouldn't happen, but it should be easy to check via KVM
> >> : tracepoints.
> >
> > I have a feeling that KVM is injecting the #UD, but it will take instrumenting KVM to see which path the #UD is being injected from.
> >
> > Wu Zongyo, can you add some instrumentation to figure that out if the trace points towards KVM injecting the #UD?
> Ok, I will try to do that.
You're right. The #UD is injected by KVM.

The path I found is:
svm_vcpu_run
svm_complete_interrupts
kvm_requeue_exception // vector = 3
kvm_make_request

vcpu_enter_guest
kvm_check_and_inject_events
svm_inject_exception
svm_update_soft_interrupt_rip
__svm_skip_emulated_instruction
x86_emulate_instruction
svm_can_emulate_instruction
kvm_queue_exception(vcpu, UD_VECTOR)

Does this mean a #PF intercept occur when the guest try to deliver a
#BP through the IDT? But why?

Thanks

> >
> > Thanks,
> > Tom
> >
> >>
> >> [*] https://lore.kernel.org/all/[email protected]

2023-08-02 15:09:35

[permalink] [raw]

Subject: Re: [Question] int3 instruction generates a #UD in SEV VM

On Wed, Aug 02, 2023, Wu Zongyo wrote:
> On Mon, Jul 31, 2023 at 11:45:29PM +0800, wuzongyong wrote:
> >
> > On 2023/7/31 23:03, Tom Lendacky wrote:
> > > On 7/31/23 09:30, Sean Christopherson wrote:
> > >> On Sat, Jul 29, 2023, wuzongyong wrote:
> > >>> Hi,
> > >>> I am writing a firmware in Rust to support SEV based on project td-shim[1].
> > >>> But when I create a SEV VM (just SEV, no SEV-ES and no SEV-SNP) with the firmware,
> > >>> the linux kernel crashed because the int3 instruction in int3_selftest() cause a
> > >>> #UD.
> > >>
> > >> ...
> > >>
> > >>> BTW, if a create a normal VM without SEV by qemu & OVMF, the int3 instruction always generates a
> > >>> #BP.
> > >>> So I am confused now about the behaviour of int3 instruction, could anyone help to explain the behaviour?
> > >>> Any suggestion is appreciated!
> > >>
> > >> Have you tried my suggestions from the other thread[*]?
> > Firstly, I'm sorry for sending muliple mails with the same content. I thought the mails I sent previously
> > didn't be sent successfully.
> > And let's talk the problem here.
> > >>
> > >> : > > I'm curious how this happend. I cannot find any condition that would
> > >> : > > cause the int3 instruction generate a #UD according to the AMD's spec.
> > >> :
> > >> : One possibility is that the value from memory that gets executed diverges from the
> > >> : value that is read out be the #UD handler, e.g. due to patching (doesn't seem to
> > >> : be the case in this test), stale cache/tlb entries, etc.
> > >> :
> > >> : > > BTW, it worked nomarlly with qemu and ovmf.
> > >> : >
> > >> : > Does this happen every time you boot the guest with your firmware? What
> > >> : > processor are you running on?
> > >> :
> > Yes, every time.
> > The processor I used is EPYC 7T83.
> > >> : And have you ruled out KVM as the culprit? I.e. verified that KVM is NOT injecting
> > >> : a #UD. That obviously shouldn't happen, but it should be easy to check via KVM
> > >> : tracepoints.
> > >
> > > I have a feeling that KVM is injecting the #UD, but it will take instrumenting KVM to see which path the #UD is being injected from.
> > >
> > > Wu Zongyo, can you add some instrumentation to figure that out if the trace points towards KVM injecting the #UD?
> > Ok, I will try to do that.
> You're right. The #UD is injected by KVM.
>
> The path I found is:
> svm_vcpu_run
> svm_complete_interrupts
> kvm_requeue_exception // vector = 3
> kvm_make_request
>
> vcpu_enter_guest
> kvm_check_and_inject_events
> svm_inject_exception
> svm_update_soft_interrupt_rip
> __svm_skip_emulated_instruction
> x86_emulate_instruction
> svm_can_emulate_instruction
> kvm_queue_exception(vcpu, UD_VECTOR)
>
> Does this mean a #PF intercept occur when the guest try to deliver a
> #BP through the IDT? But why?

I doubt it's a #PF. A #NPF is much more likely, though it could be something
else entirely, but I'm pretty sure that would require bugs in both the host and
guest.

What is the last exit recorded by trace_kvm_exit() before the #UD is injected?

2023-08-02 15:10:47

[permalink] [raw]

Subject: Re: [Question] int3 instruction generates a #UD in SEV VM

On 8/2/23 09:25, Tom Lendacky wrote:
> On 8/2/23 09:01, Sean Christopherson wrote:
>> On Wed, Aug 02, 2023, Wu Zongyo wrote:
>>> On Mon, Jul 31, 2023 at 11:45:29PM +0800, wuzongyong wrote:
>>>>
>>>> On 2023/7/31 23:03, Tom Lendacky wrote:
>>>>> On 7/31/23 09:30, Sean Christopherson wrote:
>>>>>> On Sat, Jul 29, 2023, wuzongyong wrote:
>>>>>>> Hi,
>>>>>>> I am writing a firmware in Rust to support SEV based on project
>>>>>>> td-shim[1].
>>>>>>> But when I create a SEV VM (just SEV, no SEV-ES and no SEV-SNP)
>>>>>>> with the firmware,
>>>>>>> the linux kernel crashed because the int3 instruction in
>>>>>>> int3_selftest() cause a
>>>>>>> #UD.
>>>>>>
>>>>>> ...
>>>>>>
>>>>>>> BTW, if a create a normal VM without SEV by qemu & OVMF, the int3
>>>>>>> instruction always generates a
>>>>>>> #BP.
>>>>>>> So I am confused now about the behaviour of int3 instruction, could
>>>>>>> anyone help to explain the behaviour?
>>>>>>> Any suggestion is appreciated!
>>>>>>
>>>>>> Have you tried my suggestions from the other thread[*]?
>>>> Firstly, I'm sorry for sending muliple mails with the same content. I
>>>> thought the mails I sent previously
>>>> didn't be sent successfully.
>>>> And let's talk the problem here.
>>>>>>
>>>>>>     : > > I'm curious how this happend. I cannot find any condition
>>>>>> that would
>>>>>>     : > > cause the int3 instruction generate a #UD according to the
>>>>>> AMD's spec.
>>>>>>     :
>>>>>>     : One possibility is that the value from memory that gets
>>>>>> executed diverges from the
>>>>>>     : value that is read out be the #UD handler, e.g. due to
>>>>>> patching (doesn't seem to
>>>>>>     : be the case in this test), stale cache/tlb entries, etc.
>>>>>>     :
>>>>>>     : > > BTW, it worked nomarlly with qemu and ovmf.
>>>>>>     : >
>>>>>>     : > Does this happen every time you boot the guest with your
>>>>>> firmware? What
>>>>>>     : > processor are you running on?
>>>>>>     :
>>>> Yes, every time.
>>>> The processor I used is EPYC 7T83.
>>>>>>     : And have you ruled out KVM as the culprit? I.e. verified that
>>>>>> KVM is NOT injecting
>>>>>>     : a #UD. That obviously shouldn't happen, but it should be easy
>>>>>> to check via KVM
>>>>>>     : tracepoints.
>>>>>
>>>>> I have a feeling that KVM is injecting the #UD, but it will take
>>>>> instrumenting KVM to see which path the #UD is being injected from.
>>>>>
>>>>> Wu Zongyo, can you add some instrumentation to figure that out if the
>>>>> trace points towards KVM injecting the #UD?
>>>> Ok, I will try to do that.
>>> You're right. The #UD is injected by KVM.
>>>
>>> The path I found is:
>>>      svm_vcpu_run
>>>          svm_complete_interrupts
>>>         kvm_requeue_exception // vector = 3
>>>             kvm_make_request
>>>
>>>      vcpu_enter_guest
>>>          kvm_check_and_inject_events
>>>         svm_inject_exception
>>>             svm_update_soft_interrupt_rip
>>>             __svm_skip_emulated_instruction
>>>                 x86_emulate_instruction
>>>                 svm_can_emulate_instruction
>>>                     kvm_queue_exception(vcpu, UD_VECTOR)
>>>
>>> Does this mean a #PF intercept occur when the guest try to deliver a
>>> #BP through the IDT? But why?
>>
>> I doubt it's a #PF. A #NPF is much more likely, though it could be
>> something
>> else entirely, but I'm pretty sure that would require bugs in both the
>> host and
>> guest.
>>
>> What is the last exit recorded by trace_kvm_exit() before the #UD is
>> injected?
>
> I'm guessing it was a #NPF, too. Could it be related to the changes that
> went in around svm_update_soft_interrupt_rip()?
>
> 6ef88d6e36c2 ("KVM: SVM: Re-inject INT3/INTO instead of retrying the
> instruction")

Sorry, that should have been:

7e5b5ef8dca3 ("KVM: SVM: Re-inject INTn instead of retrying the insn on "failure"")

>
> Before this the !nrips check would prevent the call into
> svm_skip_emulated_instruction(). But now, there is a call to:
>
> svm_update_soft_interrupt_rip()
>     __svm_skip_emulated_instruction()
>       kvm_emulate_instruction()
>         x86_emulate_instruction() (passed a NULL insn pointer)
>           kvm_can_emulate_insn() (passed a NULL insn pointer)
>             svm_can_emulate_instruction() (passed NULL insn pointer)
>
> Because it is an SEV guest, it ends up in the "if (unlikely(!insn))" path
> and injects the #UD.
>
> Thanks,
> Tom
>

2023-08-02 15:44:00

[permalink] [raw]

Subject: Re: [Question] int3 instruction generates a #UD in SEV VM

On Wed, Aug 02, 2023, Tom Lendacky wrote:
> On 8/2/23 09:25, Tom Lendacky wrote:
> > On 8/2/23 09:01, Sean Christopherson wrote:
> > > > You're right. The #UD is injected by KVM.
> > > >
> > > > The path I found is:
> > > >      svm_vcpu_run
> > > >          svm_complete_interrupts
> > > >         kvm_requeue_exception // vector = 3
> > > >             kvm_make_request
> > > >
> > > >      vcpu_enter_guest
> > > >          kvm_check_and_inject_events
> > > >         svm_inject_exception
> > > >             svm_update_soft_interrupt_rip
> > > >             __svm_skip_emulated_instruction
> > > >                 x86_emulate_instruction
> > > >                 svm_can_emulate_instruction
> > > >                     kvm_queue_exception(vcpu, UD_VECTOR)
> > > >
> > > > Does this mean a #PF intercept occur when the guest try to deliver a
> > > > #BP through the IDT? But why?
> > >
> > > I doubt it's a #PF. A #NPF is much more likely, though it could be
> > > something
> > > else entirely, but I'm pretty sure that would require bugs in both
> > > the host and
> > > guest.
> > >
> > > What is the last exit recorded by trace_kvm_exit() before the #UD is
> > > injected?
> >
> > I'm guessing it was a #NPF, too. Could it be related to the changes that
> > went in around svm_update_soft_interrupt_rip()?
> >
> > 6ef88d6e36c2 ("KVM: SVM: Re-inject INT3/INTO instead of retrying the
> > instruction")
>
> Sorry, that should have been:
>
> 7e5b5ef8dca3 ("KVM: SVM: Re-inject INTn instead of retrying the insn on "failure"")
>
> >
> > Before this the !nrips check would prevent the call into
> > svm_skip_emulated_instruction(). But now, there is a call to:
> >
> > svm_update_soft_interrupt_rip()
> >     __svm_skip_emulated_instruction()
> >       kvm_emulate_instruction()
> >         x86_emulate_instruction() (passed a NULL insn pointer)
> >           kvm_can_emulate_insn() (passed a NULL insn pointer)
> >             svm_can_emulate_instruction() (passed NULL insn pointer)
> >
> > Because it is an SEV guest, it ends up in the "if (unlikely(!insn))" path
> > and injects the #UD.

Yeah, my money is on that too. I believe this is the least awful solution:

diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index d381ad424554..2eace114a934 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -385,6 +385,9 @@ static int __svm_skip_emulated_instruction(struct kvm_vcpu *vcpu,
}

if (!svm->next_rip) {
+ if (sev_guest(vcpu->kvm))
+ return 0;
+
if (unlikely(!commit_side_effects))
old_rflags = svm->vmcb->save.rflags;

I'll send a formal patch (with a comment) if that solves the problem.

Side topic, KVM should require nrips for SEV and beyond, I don't see how SEV can
possibly work if KVM doesn't utilize nrips. E.g. this

diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 2eace114a934..43e500503d48 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -5111,9 +5111,11 @@ static __init int svm_hardware_setup(void)

svm_adjust_mmio_mask();

+ nrips = nrips && boot_cpu_has(X86_FEATURE_NRIPS);
+
/*
* Note, SEV setup consumes npt_enabled and enable_mmio_caching (which
- * may be modified by svm_adjust_mmio_mask()).
+ * may be modified by svm_adjust_mmio_mask()), as well as nrips.
*/
sev_hardware_setup();

@@ -5125,11 +5127,6 @@ static __init int svm_hardware_setup(void)
goto err;
}

- if (nrips) {
- if (!boot_cpu_has(X86_FEATURE_NRIPS))
- nrips = false;
- }
-
enable_apicv = avic = avic && avic_hardware_setup();

if (!enable_apicv) {

2023-08-02 15:50:33

[permalink] [raw]

Subject: Re: [Question] int3 instruction generates a #UD in SEV VM

On 8/2/23 09:01, Sean Christopherson wrote:
> On Wed, Aug 02, 2023, Wu Zongyo wrote:
>> On Mon, Jul 31, 2023 at 11:45:29PM +0800, wuzongyong wrote:
>>>
>>> On 2023/7/31 23:03, Tom Lendacky wrote:
>>>> On 7/31/23 09:30, Sean Christopherson wrote:
>>>>> On Sat, Jul 29, 2023, wuzongyong wrote:
>>>>>> Hi,
>>>>>> I am writing a firmware in Rust to support SEV based on project td-shim[1].
>>>>>> But when I create a SEV VM (just SEV, no SEV-ES and no SEV-SNP) with the firmware,
>>>>>> the linux kernel crashed because the int3 instruction in int3_selftest() cause a
>>>>>> #UD.
>>>>>
>>>>> ...
>>>>>
>>>>>> BTW, if a create a normal VM without SEV by qemu & OVMF, the int3 instruction always generates a
>>>>>> #BP.
>>>>>> So I am confused now about the behaviour of int3 instruction, could anyone help to explain the behaviour?
>>>>>> Any suggestion is appreciated!
>>>>>
>>>>> Have you tried my suggestions from the other thread[*]?
>>> Firstly, I'm sorry for sending muliple mails with the same content. I thought the mails I sent previously
>>> didn't be sent successfully.
>>> And let's talk the problem here.
>>>>>
>>>>> : > > I'm curious how this happend. I cannot find any condition that would
>>>>> : > > cause the int3 instruction generate a #UD according to the AMD's spec.
>>>>> :
>>>>> : One possibility is that the value from memory that gets executed diverges from the
>>>>> : value that is read out be the #UD handler, e.g. due to patching (doesn't seem to
>>>>> : be the case in this test), stale cache/tlb entries, etc.
>>>>> :
>>>>> : > > BTW, it worked nomarlly with qemu and ovmf.
>>>>> : >
>>>>> : > Does this happen every time you boot the guest with your firmware? What
>>>>> : > processor are you running on?
>>>>> :
>>> Yes, every time.
>>> The processor I used is EPYC 7T83.
>>>>> : And have you ruled out KVM as the culprit? I.e. verified that KVM is NOT injecting
>>>>> : a #UD. That obviously shouldn't happen, but it should be easy to check via KVM
>>>>> : tracepoints.
>>>>
>>>> I have a feeling that KVM is injecting the #UD, but it will take instrumenting KVM to see which path the #UD is being injected from.
>>>>
>>>> Wu Zongyo, can you add some instrumentation to figure that out if the trace points towards KVM injecting the #UD?
>>> Ok, I will try to do that.
>> You're right. The #UD is injected by KVM.
>>
>> The path I found is:
>> svm_vcpu_run
>> svm_complete_interrupts
>> kvm_requeue_exception // vector = 3
>> kvm_make_request
>>
>> vcpu_enter_guest
>> kvm_check_and_inject_events
>> svm_inject_exception
>> svm_update_soft_interrupt_rip
>> __svm_skip_emulated_instruction
>> x86_emulate_instruction
>> svm_can_emulate_instruction
>> kvm_queue_exception(vcpu, UD_VECTOR)
>>
>> Does this mean a #PF intercept occur when the guest try to deliver a
>> #BP through the IDT? But why?
>
> I doubt it's a #PF. A #NPF is much more likely, though it could be something
> else entirely, but I'm pretty sure that would require bugs in both the host and
> guest.
>
> What is the last exit recorded by trace_kvm_exit() before the #UD is injected?

I'm guessing it was a #NPF, too. Could it be related to the changes that
went in around svm_update_soft_interrupt_rip()?

6ef88d6e36c2 ("KVM: SVM: Re-inject INT3/INTO instead of retrying the instruction")

Before this the !nrips check would prevent the call into
svm_skip_emulated_instruction(). But now, there is a call to:

svm_update_soft_interrupt_rip()
__svm_skip_emulated_instruction()
kvm_emulate_instruction()
x86_emulate_instruction() (passed a NULL insn pointer)
kvm_can_emulate_insn() (passed a NULL insn pointer)
svm_can_emulate_instruction() (passed NULL insn pointer)

Because it is an SEV guest, it ends up in the "if (unlikely(!insn))" path
and injects the #UD.

Thanks,
Tom

2023-08-02 16:26:42

[permalink] [raw]

Subject: Re: [Question] int3 instruction generates a #UD in SEV VM

On Wed, Aug 02, 2023, Tom Lendacky wrote:
> On 8/2/23 10:04, Sean Christopherson wrote:
> > Side topic, KVM should require nrips for SEV and beyond, I don't see how SEV can
> > possibly work if KVM doesn't utilize nrips. E.g. this
> >
> > diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
> > index 2eace114a934..43e500503d48 100644
> > --- a/arch/x86/kvm/svm/svm.c
> > +++ b/arch/x86/kvm/svm/svm.c
> > @@ -5111,9 +5111,11 @@ static __init int svm_hardware_setup(void)
> > svm_adjust_mmio_mask();
> > + nrips = nrips && boot_cpu_has(X86_FEATURE_NRIPS);
> > +
> > /*
> > * Note, SEV setup consumes npt_enabled and enable_mmio_caching (which
> > - * may be modified by svm_adjust_mmio_mask()).
> > + * may be modified by svm_adjust_mmio_mask()), as well as nrips.
> > */
> > sev_hardware_setup();
>
> You moved the setting of nrips up, I'm assuming you then want to add a check
> in sev_hardware_setup() for nrips?

Doh. I like to think I would have noticed that I forgot to add that check before
postinga patch, but I give myself 50/50 odds at best.

2023-08-02 16:38:52

[permalink] [raw]

Subject: Re: [Question] int3 instruction generates a #UD in SEV VM

On 8/2/23 10:04, Sean Christopherson wrote:
> On Wed, Aug 02, 2023, Tom Lendacky wrote:
>> On 8/2/23 09:25, Tom Lendacky wrote:
>>> On 8/2/23 09:01, Sean Christopherson wrote:
>>>>> You're right. The #UD is injected by KVM.
>>>>>
>>>>> The path I found is:
>>>>>      svm_vcpu_run
>>>>>          svm_complete_interrupts
>>>>>         kvm_requeue_exception // vector = 3
>>>>>             kvm_make_request
>>>>>
>>>>>      vcpu_enter_guest
>>>>>          kvm_check_and_inject_events
>>>>>         svm_inject_exception
>>>>>             svm_update_soft_interrupt_rip
>>>>>             __svm_skip_emulated_instruction
>>>>>                 x86_emulate_instruction
>>>>>                 svm_can_emulate_instruction
>>>>>                     kvm_queue_exception(vcpu, UD_VECTOR)
>>>>>
>>>>> Does this mean a #PF intercept occur when the guest try to deliver a
>>>>> #BP through the IDT? But why?
>>>>
>>>> I doubt it's a #PF. A #NPF is much more likely, though it could be
>>>> something
>>>> else entirely, but I'm pretty sure that would require bugs in both
>>>> the host and
>>>> guest.
>>>>
>>>> What is the last exit recorded by trace_kvm_exit() before the #UD is
>>>> injected?
>>>
>>> I'm guessing it was a #NPF, too. Could it be related to the changes that
>>> went in around svm_update_soft_interrupt_rip()?
>>>
>>> 6ef88d6e36c2 ("KVM: SVM: Re-inject INT3/INTO instead of retrying the
>>> instruction")
>>
>> Sorry, that should have been:
>>
>> 7e5b5ef8dca3 ("KVM: SVM: Re-inject INTn instead of retrying the insn on "failure"")
>>
>>>
>>> Before this the !nrips check would prevent the call into
>>> svm_skip_emulated_instruction(). But now, there is a call to:
>>>
>>> svm_update_soft_interrupt_rip()
>>>     __svm_skip_emulated_instruction()
>>>       kvm_emulate_instruction()
>>>         x86_emulate_instruction() (passed a NULL insn pointer)
>>>           kvm_can_emulate_insn() (passed a NULL insn pointer)
>>>             svm_can_emulate_instruction() (passed NULL insn pointer)
>>>
>>> Because it is an SEV guest, it ends up in the "if (unlikely(!insn))" path
>>> and injects the #UD.
>
> Yeah, my money is on that too. I believe this is the least awful solution:
>
> diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
> index d381ad424554..2eace114a934 100644
> --- a/arch/x86/kvm/svm/svm.c
> +++ b/arch/x86/kvm/svm/svm.c
> @@ -385,6 +385,9 @@ static int __svm_skip_emulated_instruction(struct kvm_vcpu *vcpu,
> }
>
> if (!svm->next_rip) {
> + if (sev_guest(vcpu->kvm))
> + return 0;
> +
> if (unlikely(!commit_side_effects))
> old_rflags = svm->vmcb->save.rflags;
>
> I'll send a formal patch (with a comment) if that solves the problem.
>
>
> Side topic, KVM should require nrips for SEV and beyond, I don't see how SEV can
> possibly work if KVM doesn't utilize nrips. E.g. this
>
> diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
> index 2eace114a934..43e500503d48 100644
> --- a/arch/x86/kvm/svm/svm.c
> +++ b/arch/x86/kvm/svm/svm.c
> @@ -5111,9 +5111,11 @@ static __init int svm_hardware_setup(void)
>
> svm_adjust_mmio_mask();
>
> + nrips = nrips && boot_cpu_has(X86_FEATURE_NRIPS);
> +
> /*
> * Note, SEV setup consumes npt_enabled and enable_mmio_caching (which
> - * may be modified by svm_adjust_mmio_mask()).
> + * may be modified by svm_adjust_mmio_mask()), as well as nrips.
> */
> sev_hardware_setup();

You moved the setting of nrips up, I'm assuming you then want to add a
check in sev_hardware_setup() for nrips?

Thanks,
Tom

>
> @@ -5125,11 +5127,6 @@ static __init int svm_hardware_setup(void)
> goto err;
> }
>
> - if (nrips) {
> - if (!boot_cpu_has(X86_FEATURE_NRIPS))
> - nrips = false;
> - }
> -
> enable_apicv = avic = avic && avic_hardware_setup();
>
> if (!enable_apicv) {
>

2023-08-02 21:37:28

[permalink] [raw]

Subject: Re: [Question] int3 instruction generates a #UD in SEV VM

On 8/2/23 09:33, Tom Lendacky wrote:
> On 8/2/23 09:25, Tom Lendacky wrote:
>> On 8/2/23 09:01, Sean Christopherson wrote:
>>> On Wed, Aug 02, 2023, Wu Zongyo wrote:
>>>> On Mon, Jul 31, 2023 at 11:45:29PM +0800, wuzongyong wrote:
>>>>>
>>>>> On 2023/7/31 23:03, Tom Lendacky wrote:
>>>>>> On 7/31/23 09:30, Sean Christopherson wrote:
>>>>>>> On Sat, Jul 29, 2023, wuzongyong wrote:
>>>>>>>> Hi,
>>>>>>>> I am writing a firmware in Rust to support SEV based on project
>>>>>>>> td-shim[1].
>>>>>>>> But when I create a SEV VM (just SEV, no SEV-ES and no SEV-SNP)
>>>>>>>> with the firmware,
>>>>>>>> the linux kernel crashed because the int3 instruction in
>>>>>>>> int3_selftest() cause a
>>>>>>>> #UD.
>>>>>>>
>>>>>>> ...
>>>>>>>
>>>>>>>> BTW, if a create a normal VM without SEV by qemu & OVMF, the int3
>>>>>>>> instruction always generates a
>>>>>>>> #BP.
>>>>>>>> So I am confused now about the behaviour of int3 instruction,
>>>>>>>> could anyone help to explain the behaviour?
>>>>>>>> Any suggestion is appreciated!
>>>>>>>
>>>>>>> Have you tried my suggestions from the other thread[*]?
>>>>> Firstly, I'm sorry for sending muliple mails with the same content. I
>>>>> thought the mails I sent previously
>>>>> didn't be sent successfully.
>>>>> And let's talk the problem here.
>>>>>>>
>>>>>>>     : > > I'm curious how this happend. I cannot find any condition
>>>>>>> that would
>>>>>>>     : > > cause the int3 instruction generate a #UD according to
>>>>>>> the AMD's spec.
>>>>>>>     :
>>>>>>>     : One possibility is that the value from memory that gets
>>>>>>> executed diverges from the
>>>>>>>     : value that is read out be the #UD handler, e.g. due to
>>>>>>> patching (doesn't seem to
>>>>>>>     : be the case in this test), stale cache/tlb entries, etc.
>>>>>>>     :
>>>>>>>     : > > BTW, it worked nomarlly with qemu and ovmf.
>>>>>>>     : >
>>>>>>>     : > Does this happen every time you boot the guest with your
>>>>>>> firmware? What
>>>>>>>     : > processor are you running on?
>>>>>>>     :
>>>>> Yes, every time.
>>>>> The processor I used is EPYC 7T83.
>>>>>>>     : And have you ruled out KVM as the culprit? I.e. verified
>>>>>>> that KVM is NOT injecting
>>>>>>>     : a #UD. That obviously shouldn't happen, but it should be
>>>>>>> easy to check via KVM
>>>>>>>     : tracepoints.
>>>>>>
>>>>>> I have a feeling that KVM is injecting the #UD, but it will take
>>>>>> instrumenting KVM to see which path the #UD is being injected from.
>>>>>>
>>>>>> Wu Zongyo, can you add some instrumentation to figure that out if
>>>>>> the trace points towards KVM injecting the #UD?
>>>>> Ok, I will try to do that.
>>>> You're right. The #UD is injected by KVM.
>>>>
>>>> The path I found is:
>>>>      svm_vcpu_run
>>>>          svm_complete_interrupts
>>>>         kvm_requeue_exception // vector = 3
>>>>             kvm_make_request
>>>>
>>>>      vcpu_enter_guest
>>>>          kvm_check_and_inject_events
>>>>         svm_inject_exception
>>>>             svm_update_soft_interrupt_rip
>>>>             __svm_skip_emulated_instruction
>>>>                 x86_emulate_instruction
>>>>                 svm_can_emulate_instruction
>>>>                     kvm_queue_exception(vcpu, UD_VECTOR)
>>>>
>>>> Does this mean a #PF intercept occur when the guest try to deliver a
>>>> #BP through the IDT? But why?
>>>
>>> I doubt it's a #PF. A #NPF is much more likely, though it could be
>>> something
>>> else entirely, but I'm pretty sure that would require bugs in both the
>>> host and
>>> guest.
>>>
>>> What is the last exit recorded by trace_kvm_exit() before the #UD is
>>> injected?
>>
>> I'm guessing it was a #NPF, too. Could it be related to the changes that
>> went in around svm_update_soft_interrupt_rip()?
>>
>> 6ef88d6e36c2 ("KVM: SVM: Re-inject INT3/INTO instead of retrying the
>> instruction")
>
> Sorry, that should have been:
>
> 7e5b5ef8dca3 ("KVM: SVM: Re-inject INTn instead of retrying the insn on
> "failure"")

Doh! I was right the first time... sigh

6ef88d6e36c2 ("KVM: SVM: Re-inject INT3/INTO instead of retrying the instruction")

Thanks,
Tom

>
>>
>> Before this the !nrips check would prevent the call into
>> svm_skip_emulated_instruction(). But now, there is a call to:
>>
>>    svm_update_soft_interrupt_rip()
>>      __svm_skip_emulated_instruction()
>>        kvm_emulate_instruction()
>>          x86_emulate_instruction() (passed a NULL insn pointer)
>>            kvm_can_emulate_insn() (passed a NULL insn pointer)
>>              svm_can_emulate_instruction() (passed NULL insn pointer)
>>
>> Because it is an SEV guest, it ends up in the "if (unlikely(!insn))" path
>> and injects the #UD.
>>
>> Thanks,
>> Tom
>>

2023-08-03 04:03:02

[permalink] [raw]

Subject: Re: [Question] int3 instruction generates a #UD in SEV VM

On Wed, Aug 02, 2023 at 03:03:45PM -0500, Tom Lendacky wrote:
> On 8/2/23 09:33, Tom Lendacky wrote:
> > On 8/2/23 09:25, Tom Lendacky wrote:
> > > On 8/2/23 09:01, Sean Christopherson wrote:
> > > > On Wed, Aug 02, 2023, Wu Zongyo wrote:
> > > > > On Mon, Jul 31, 2023 at 11:45:29PM +0800, wuzongyong wrote:
> > > > > >
> > > > > > On 2023/7/31 23:03, Tom Lendacky wrote:
> > > > > > > On 7/31/23 09:30, Sean Christopherson wrote:
> > > > > > > > On Sat, Jul 29, 2023, wuzongyong wrote:
> > > > > > > > > Hi,
> > > > > > > > > I am writing a firmware in Rust to support
> > > > > > > > > SEV based on project td-shim[1].
> > > > > > > > > But when I create a SEV VM (just SEV, no
> > > > > > > > > SEV-ES and no SEV-SNP) with the firmware,
> > > > > > > > > the linux kernel crashed because the int3
> > > > > > > > > instruction in int3_selftest() cause a
> > > > > > > > > #UD.
> > > > > > > >
> > > > > > > > ...
> > > > > > > >
> > > > > > > > > BTW, if a create a normal VM without SEV by
> > > > > > > > > qemu & OVMF, the int3 instruction always
> > > > > > > > > generates a
> > > > > > > > > #BP.
> > > > > > > > > So I am confused now about the behaviour of
> > > > > > > > > int3 instruction, could anyone help to
> > > > > > > > > explain the behaviour?
> > > > > > > > > Any suggestion is appreciated!
> > > > > > > >
> > > > > > > > Have you tried my suggestions from the other thread[*]?
> > > > > > Firstly, I'm sorry for sending muliple mails with the
> > > > > > same content. I thought the mails I sent previously
> > > > > > didn't be sent successfully.
> > > > > > And let's talk the problem here.
> > > > > > > >
> > > > > > > > ??? : > > I'm curious how this happend. I cannot
> > > > > > > > find any condition that would
> > > > > > > > ??? : > > cause the int3 instruction generate a
> > > > > > > > #UD according to the AMD's spec.
> > > > > > > > ??? :
> > > > > > > > ??? : One possibility is that the value from
> > > > > > > > memory that gets executed diverges from the
> > > > > > > > ??? : value that is read out be the #UD handler,
> > > > > > > > e.g. due to patching (doesn't seem to
> > > > > > > > ??? : be the case in this test), stale cache/tlb entries, etc.
> > > > > > > > ??? :
> > > > > > > > ??? : > > BTW, it worked nomarlly with qemu and ovmf.
> > > > > > > > ??? : >
> > > > > > > > ??? : > Does this happen every time you boot the
> > > > > > > > guest with your firmware? What
> > > > > > > > ??? : > processor are you running on?
> > > > > > > > ??? :
> > > > > > Yes, every time.
> > > > > > The processor I used is EPYC 7T83.
> > > > > > > > ??? : And have you ruled out KVM as the
> > > > > > > > culprit?? I.e. verified that KVM is NOT
> > > > > > > > injecting
> > > > > > > > ??? : a #UD.? That obviously shouldn't happen,
> > > > > > > > but it should be easy to check via KVM
> > > > > > > > ??? : tracepoints.
> > > > > > >
> > > > > > > I have a feeling that KVM is injecting the #UD, but
> > > > > > > it will take instrumenting KVM to see which path the
> > > > > > > #UD is being injected from.
> > > > > > >
> > > > > > > Wu Zongyo, can you add some instrumentation to
> > > > > > > figure that out if the trace points towards KVM
> > > > > > > injecting the #UD?
> > > > > > Ok, I will try to do that.
> > > > > You're right. The #UD is injected by KVM.
> > > > >
> > > > > The path I found is:
> > > > > ???? svm_vcpu_run
> > > > > ???????? svm_complete_interrupts
> > > > > ??????? kvm_requeue_exception // vector = 3
> > > > > ??????????? kvm_make_request
> > > > >
> > > > > ???? vcpu_enter_guest
> > > > > ???????? kvm_check_and_inject_events
> > > > > ??????? svm_inject_exception
> > > > > ??????????? svm_update_soft_interrupt_rip
> > > > > ??????????? __svm_skip_emulated_instruction
> > > > > ??????????????? x86_emulate_instruction
> > > > > ??????????????? svm_can_emulate_instruction
> > > > > ??????????????????? kvm_queue_exception(vcpu, UD_VECTOR)
> > > > >
> > > > > Does this mean a #PF intercept occur when the guest try to deliver a
> > > > > #BP through the IDT? But why?
> > > >
> > > > I doubt it's a #PF.? A #NPF is much more likely, though it could
> > > > be something
> > > > else entirely, but I'm pretty sure that would require bugs in
> > > > both the host and
> > > > guest.
> > > >
> > > > What is the last exit recorded by trace_kvm_exit() before the
> > > > #UD is injected?
> > >
> > > I'm guessing it was a #NPF, too. Could it be related to the changes that
> > > went in around svm_update_soft_interrupt_rip()?
Yes, it's a #NPF with exit code 0x400.

There must be something I didn't handle corretly since it behave normally with
qemu & ovmf If I don't add int3 before mcheck_cpu_init().

So it'a about memory, is there something I need to pay special attention
to?

Thanks
> > >
> > > 6ef88d6e36c2 ("KVM: SVM: Re-inject INT3/INTO instead of retrying the
> > > instruction")
> >
> > Sorry, that should have been:
> >
> > 7e5b5ef8dca3 ("KVM: SVM: Re-inject INTn instead of retrying the insn on
> > "failure"")
>
> Doh! I was right the first time... sigh
>
> 6ef88d6e36c2 ("KVM: SVM: Re-inject INT3/INTO instead of retrying the instruction")
>
> Thanks,
> Tom
>
> >
> > >
> > > Before this the !nrips check would prevent the call into
> > > svm_skip_emulated_instruction(). But now, there is a call to:
> > >
> > > ?? svm_update_soft_interrupt_rip()
> > > ???? __svm_skip_emulated_instruction()
> > > ?????? kvm_emulate_instruction()
> > > ???????? x86_emulate_instruction() (passed a NULL insn pointer)
> > > ?????????? kvm_can_emulate_insn() (passed a NULL insn pointer)
> > > ???????????? svm_can_emulate_instruction() (passed NULL insn pointer)
> > >
> > > Because it is an SEV guest, it ends up in the "if (unlikely(!insn))" path
> > > and injects the #UD.
> > >
> > > Thanks,
> > > Tom
> > >

2023-08-03 09:52:26

[permalink] [raw]

Subject: Re: [Question] int3 instruction generates a #UD in SEV VM

On Thu, Aug 03, 2023 at 11:27:12AM +0800, Wu Zongyo wrote:
> On Wed, Aug 02, 2023 at 03:03:45PM -0500, Tom Lendacky wrote:
> > On 8/2/23 09:33, Tom Lendacky wrote:
> > > On 8/2/23 09:25, Tom Lendacky wrote:
> > > > On 8/2/23 09:01, Sean Christopherson wrote:
> > > > > On Wed, Aug 02, 2023, Wu Zongyo wrote:
> > > > > > On Mon, Jul 31, 2023 at 11:45:29PM +0800, wuzongyong wrote:
> > > > > > >
> > > > > > > On 2023/7/31 23:03, Tom Lendacky wrote:
> > > > > > > > On 7/31/23 09:30, Sean Christopherson wrote:
> > > > > > > > > On Sat, Jul 29, 2023, wuzongyong wrote:
> > > > > > > > > > Hi,
> > > > > > > > > > I am writing a firmware in Rust to support
> > > > > > > > > > SEV based on project td-shim[1].
> > > > > > > > > > But when I create a SEV VM (just SEV, no
> > > > > > > > > > SEV-ES and no SEV-SNP) with the firmware,
> > > > > > > > > > the linux kernel crashed because the int3
> > > > > > > > > > instruction in int3_selftest() cause a
> > > > > > > > > > #UD.
> > > > > > > > >
> > > > > > > > > ...
> > > > > > > > >
> > > > > > > > > > BTW, if a create a normal VM without SEV by
> > > > > > > > > > qemu & OVMF, the int3 instruction always
> > > > > > > > > > generates a
> > > > > > > > > > #BP.
> > > > > > > > > > So I am confused now about the behaviour of
> > > > > > > > > > int3 instruction, could anyone help to
> > > > > > > > > > explain the behaviour?
> > > > > > > > > > Any suggestion is appreciated!
> > > > > > > > >
> > > > > > > > > Have you tried my suggestions from the other thread[*]?
> > > > > > > Firstly, I'm sorry for sending muliple mails with the
> > > > > > > same content. I thought the mails I sent previously
> > > > > > > didn't be sent successfully.
> > > > > > > And let's talk the problem here.
> > > > > > > > >
> > > > > > > > > ??? : > > I'm curious how this happend. I cannot
> > > > > > > > > find any condition that would
> > > > > > > > > ??? : > > cause the int3 instruction generate a
> > > > > > > > > #UD according to the AMD's spec.
> > > > > > > > > ??? :
> > > > > > > > > ??? : One possibility is that the value from
> > > > > > > > > memory that gets executed diverges from the
> > > > > > > > > ??? : value that is read out be the #UD handler,
> > > > > > > > > e.g. due to patching (doesn't seem to
> > > > > > > > > ??? : be the case in this test), stale cache/tlb entries, etc.
> > > > > > > > > ??? :
> > > > > > > > > ??? : > > BTW, it worked nomarlly with qemu and ovmf.
> > > > > > > > > ??? : >
> > > > > > > > > ??? : > Does this happen every time you boot the
> > > > > > > > > guest with your firmware? What
> > > > > > > > > ??? : > processor are you running on?
> > > > > > > > > ??? :
> > > > > > > Yes, every time.
> > > > > > > The processor I used is EPYC 7T83.
> > > > > > > > > ??? : And have you ruled out KVM as the
> > > > > > > > > culprit?? I.e. verified that KVM is NOT
> > > > > > > > > injecting
> > > > > > > > > ??? : a #UD.? That obviously shouldn't happen,
> > > > > > > > > but it should be easy to check via KVM
> > > > > > > > > ??? : tracepoints.
> > > > > > > >
> > > > > > > > I have a feeling that KVM is injecting the #UD, but
> > > > > > > > it will take instrumenting KVM to see which path the
> > > > > > > > #UD is being injected from.
> > > > > > > >
> > > > > > > > Wu Zongyo, can you add some instrumentation to
> > > > > > > > figure that out if the trace points towards KVM
> > > > > > > > injecting the #UD?
> > > > > > > Ok, I will try to do that.
> > > > > > You're right. The #UD is injected by KVM.
> > > > > >
> > > > > > The path I found is:
> > > > > > ???? svm_vcpu_run
> > > > > > ???????? svm_complete_interrupts
> > > > > > ??????? kvm_requeue_exception // vector = 3
> > > > > > ??????????? kvm_make_request
> > > > > >
> > > > > > ???? vcpu_enter_guest
> > > > > > ???????? kvm_check_and_inject_events
> > > > > > ??????? svm_inject_exception
> > > > > > ??????????? svm_update_soft_interrupt_rip
> > > > > > ??????????? __svm_skip_emulated_instruction
> > > > > > ??????????????? x86_emulate_instruction
> > > > > > ??????????????? svm_can_emulate_instruction
> > > > > > ??????????????????? kvm_queue_exception(vcpu, UD_VECTOR)
> > > > > >
> > > > > > Does this mean a #PF intercept occur when the guest try to deliver a
> > > > > > #BP through the IDT? But why?
> > > > >
> > > > > I doubt it's a #PF.? A #NPF is much more likely, though it could
> > > > > be something
> > > > > else entirely, but I'm pretty sure that would require bugs in
> > > > > both the host and
> > > > > guest.
> > > > >
> > > > > What is the last exit recorded by trace_kvm_exit() before the
> > > > > #UD is injected?
> > > >
> > > > I'm guessing it was a #NPF, too. Could it be related to the changes that
> > > > went in around svm_update_soft_interrupt_rip()?
> Yes, it's a #NPF with exit code 0x400.
>
> There must be something I didn't handle corretly since it behave normally with
> qemu & ovmf If I don't add int3 before mcheck_cpu_init().
>
> So it'a about memory, is there something I need to pay special attention
> to?
>
> Thanks
I check the fault address of #NPF, and it is the IDT entry address of
the guest kernel. The NPT page table is not constructed for the IDT
entry and the #NPF is generated when guest try to access IDT.

With qemu & ovmf, I didn't see the #NPF when guest invoke the int3
handler. That means the NPT page table has already been constructed, but
when?

> > > >
> > > > 6ef88d6e36c2 ("KVM: SVM: Re-inject INT3/INTO instead of retrying the
> > > > instruction")
> > >
> > > Sorry, that should have been:
> > >
> > > 7e5b5ef8dca3 ("KVM: SVM: Re-inject INTn instead of retrying the insn on
> > > "failure"")
> >
> > Doh! I was right the first time... sigh
> >
> > 6ef88d6e36c2 ("KVM: SVM: Re-inject INT3/INTO instead of retrying the instruction")
> >
> > Thanks,
> > Tom
> >
> > >
> > > >
> > > > Before this the !nrips check would prevent the call into
> > > > svm_skip_emulated_instruction(). But now, there is a call to:
> > > >
> > > > ?? svm_update_soft_interrupt_rip()
> > > > ???? __svm_skip_emulated_instruction()
> > > > ?????? kvm_emulate_instruction()
> > > > ???????? x86_emulate_instruction() (passed a NULL insn pointer)
> > > > ?????????? kvm_can_emulate_insn() (passed a NULL insn pointer)
> > > > ???????????? svm_can_emulate_instruction() (passed NULL insn pointer)
> > > >
> > > > Because it is an SEV guest, it ends up in the "if (unlikely(!insn))" path
> > > > and injects the #UD.
> > > >
> > > > Thanks,
> > > > Tom
> > > >

2023-08-03 17:13:59

[permalink] [raw]

Subject: Re: [Question] int3 instruction generates a #UD in SEV VM

On Thu, Aug 03, 2023, Wu Zongyo wrote:
> On Thu, Aug 03, 2023 at 11:27:12AM +0800, Wu Zongyo wrote:
> > > > >
> > > > > I'm guessing it was a #NPF, too. Could it be related to the changes that
> > > > > went in around svm_update_soft_interrupt_rip()?
> > Yes, it's a #NPF with exit code 0x400.
> >
> > There must be something I didn't handle corretly since it behave normally with
> > qemu & ovmf If I don't add int3 before mcheck_cpu_init().
> >
> > So it'a about memory, is there something I need to pay special attention
> > to?
> >
> > Thanks
> I check the fault address of #NPF, and it is the IDT entry address of
> the guest kernel. The NPT page table is not constructed for the IDT
> entry and the #NPF is generated when guest try to access IDT.
>
> With qemu & ovmf, I didn't see the #NPF when guest invoke the int3
> handler. That means the NPT page table has already been constructed, but
> when?

More than likely, the page was used by the guest at some point earlier in boot.
Why the page is faulted in for certain setups but not others isn't really all
that interesting in terms of fixing the KVM bug, both guest behaviors are completely
normal and should work.

Can you try this patch I suggested earlier? If this fixes the problem, I'll post
a formal patch.

diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index d381ad424554..2eace114a934 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -385,6 +385,9 @@ static int __svm_skip_emulated_instruction(struct kvm_vcpu *vcpu,
}

if (!svm->next_rip) {
+ if (sev_guest(vcpu->kvm))
+ return 0;
+
if (unlikely(!commit_side_effects))
old_rflags = svm->vmcb->save.rflags;

2023-08-04 03:28:41