linux-kernel - Re: [PATCH V2 2/2] LoongArch: KVM: fix "unreliable stack" issue

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] [day] [month] [year] [list]
Message-ID: <9974d03b-bd07-04b0-c1e3-d76123c9cd2f@loongson.cn>
Date: Wed, 24 Dec 2025 17:13:15 +0800
From: lixianglai <lixianglai@...ngson.cn>
To: Bibo Mao <maobibo@...ngson.cn>, Huacai Chen <chenhuacai@...nel.org>,
 yangtiezhu@...ngson.cn
Cc: loongarch@...ts.linux.dev, linux-kernel@...r.kernel.org,
 kvm@...r.kernel.org, stable@...r.kernel.org, WANG Xuerui
 <kernel@...0n.name>, Tianrui Zhao <zhaotianrui@...ngson.cn>,
 Charlie Jenkins <charlie@...osinc.com>, Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH V2 2/2] LoongArch: KVM: fix "unreliable stack" issue

Hi:
> Add yangtiezhu@...ngson.cn
>
> Hi :
>>
>>
>> On 2025/12/23 上午10:46, Huacai Chen wrote:
>>> On Tue, Dec 23, 2025 at 9:27 AM Bibo Mao <maobibo@...ngson.cn> wrote:
>>>>
>>>>
>>>>
>>>> On 2025/12/22 下午7:34, Xianglai Li wrote:
>>>>> Insert the appropriate UNWIND macro definition into the 
>>>>> kvm_exc_entry in
>>>>> the assembly function to guide the generation of correct ORC table 
>>>>> entries,
>>>>> thereby solving the timeout problem of loading the 
>>>>> livepatch-sample module
>>>>> on a physical machine running multiple vcpus virtual machines.
>>>>>
>>>>> While solving the above problems, we have gained an additional 
>>>>> benefit,
>>>>> that is, we can obtain more call stack information
>>>>>
>>>>> Stack information that can be obtained before the problem is fixed:
>>>>> [<0>] kvm_vcpu_block+0x88/0x120 [kvm]
>>>>> [<0>] kvm_vcpu_halt+0x68/0x580 [kvm]
>>>>> [<0>] kvm_emu_idle+0xd4/0xf0 [kvm]
>>>>> [<0>] kvm_handle_gspr+0x7c/0x700 [kvm]
>>>>> [<0>] kvm_handle_exit+0x160/0x270 [kvm]
>>>>> [<0>] kvm_exc_entry+0x100/0x1e0
>>>>>
>>>>> Stack information that can be obtained after the problem is fixed:
>>>>> [<0>] kvm_vcpu_block+0x88/0x120 [kvm]
>>>>> [<0>] kvm_vcpu_halt+0x68/0x580 [kvm]
>>>>> [<0>] kvm_emu_idle+0xd4/0xf0 [kvm]
>>>>> [<0>] kvm_handle_gspr+0x7c/0x700 [kvm]
>>>>> [<0>] kvm_handle_exit+0x160/0x270 [kvm]
>>>>> [<0>] kvm_exc_entry+0x100/0x1e0
>>>>> [<0>] kvm_arch_vcpu_ioctl_run+0x260/0x488 [kvm]
>>>>> [<0>] kvm_vcpu_ioctl+0x200/0xcd8 [kvm]
>>>>> [<0>] sys_ioctl+0x498/0xf00
>>>>> [<0>] do_syscall+0x94/0x190
>>>>> [<0>] handle_syscall+0xb8/0x158
>>>>>
>>>>> Cc: stable@...r.kernel.org
>>>>> Signed-off-by: Xianglai Li <lixianglai@...ngson.cn>
>>>>> ---
>>>>> Cc: Huacai Chen <chenhuacai@...nel.org>
>>>>> Cc: WANG Xuerui <kernel@...0n.name>
>>>>> Cc: Tianrui Zhao <zhaotianrui@...ngson.cn>
>>>>> Cc: Bibo Mao <maobibo@...ngson.cn>
>>>>> Cc: Charlie Jenkins <charlie@...osinc.com>
>>>>> Cc: Xianglai Li <lixianglai@...ngson.cn>
>>>>> Cc: Thomas Gleixner <tglx@...utronix.de>
>>>>>
>>>>>    arch/loongarch/kvm/switch.S | 2 ++
>>>>>    1 file changed, 2 insertions(+)
>>>>>
>>>>> diff --git a/arch/loongarch/kvm/switch.S 
>>>>> b/arch/loongarch/kvm/switch.S
>>>>> index 93845ce53651..e3ecb24a3bc5 100644
>>>>> --- a/arch/loongarch/kvm/switch.S
>>>>> +++ b/arch/loongarch/kvm/switch.S
>>>>> @@ -170,6 +170,7 @@ SYM_CODE_START(kvm_exc_entry)
>>>>>        /* restore per cpu register */
>>>>>        ld.d    u0, a2, KVM_ARCH_HPERCPU
>>>>>        addi.d  sp, sp, -PT_SIZE
>>>>> +     UNWIND_HINT_REGS
>>>>>
>>>>>        /* Prepare handle exception */
>>>>>        or      a0, s0, zero
>>>>> @@ -214,6 +215,7 @@ SYM_FUNC_START(kvm_enter_guest)
>>>>>        addi.d  a2, sp, -PT_SIZE
>>>>>        /* Save host GPRs */
>>>>>        kvm_save_host_gpr a2
>>>>> +     st.d    ra, a2, PT_ERA
>>>> Had better add some comments here to show that it is special for 
>>>> unwind
>>>> usage since there is "st.d ra, a2, PT_R1" already in macro
>>>> kvm_save_host_gpr().
>>> Then there is a new problem, why can unwinder not recognize the
>>> instruction in  kvm_save_host_gpr()?
>> maybe it need unwinder owner to answer this question.
>>
> kvm_save_host_gpr() is an assembler macro that has already been 
> executed and is no longer normal on the stack.
> Am I explaining correctly? @tiezhu
>
> I guess you might be wondering why unwinder didn't recognize 
> kvm_enter_guest().
>
> There's something wrong with the logic that we're implementing here 
> that we should put the current pc in era instead of ra.
> This will allow unwind to identify the symbol kvm_enter_guest.
>
> So I will fix it in the next version like this:
>
> @@ -214,6 +215,7 @@ SYM_FUNC_START(kvm_enter_guest)
>        addi.d  a2, sp, -PT_SIZE
>        /* Save host GPRs */
>        kvm_save_host_gpr a2
>
> +    /*
> +     * The csr_era member variable of the pt_regs structure is required
> +     * for unwinding orc to perform stack traceback, so we need to put
> +     * pc into csr_era member variable here.
> +     */
> +    pcaddi    t0, 0
> +    st.d    t0, a2, PT_ERA
> +
>
We discussed it with @tiezhu internally and he was OK with the change!

Thanks,
Xianglai.

> Thanks,
> Xianglai.
>>>
>>> Huacai
>>>>
>>>> Regards
>>>> Bibo Mao
>>>>>
>>>>>        addi.d  a2, a1, KVM_VCPU_ARCH
>>>>>        st.d    sp, a2, KVM_ARCH_HSP
>>>>>
>>>>
>