linux-kernel - Re: [Question] int3 instruction generates a #UD in SEV VM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4ebb3e20-a043-8ad3-ef6c-f64c2443412c@amd.com>
Date:   Mon, 31 Jul 2023 10:03:34 -0500
From:   Tom Lendacky <thomas.lendacky@....com>
To:     Sean Christopherson <seanjc@...gle.com>,
        wuzongyong <wuzongyo@...l.ustc.edu.cn>
Cc:     linux-kernel@...r.kernel.org, kvm@...r.kernel.org, x86@...nel.org,
        linux-coco@...ts.linux.dev
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/ZMFd5kkehlkIfnBA@google.com