linux-kernel - Re: [BUG net-next] arch/x86/kernel/cpu/bugs.c:2935: "Unpatched return thunk in use. This should not happen!" [STACKTRACE]

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]

Date: Wed, 3 Apr 2024 14:14:36 +0200
From: Borislav Petkov <bp@...en8.de>
To: Michael Roth <michael.roth@....com>,
	Josh Poimboeuf <jpoimboe@...nel.org>
Cc: bp@...nel.org, bgardon@...gle.com, dave.hansen@...ux.intel.com,
	dmatlack@...gle.com, hpa@...or.com, jpoimboe@...nel.org,
	kvm@...r.kernel.org, leitao@...ian.org,
	linux-kernel@...r.kernel.org, maz@...nel.org, mingo@...hat.com,
	mirsad.todorovac@....unizg.hr, pawan.kumar.gupta@...ux.intel.com,
	pbonzini@...hat.com, peterz@...radead.org, seanjc@...gle.com,
	shahuang@...hat.com, tabba@...gle.com, tglx@...utronix.de,
	x86@...nel.org
Subject: Re: [BUG net-next] arch/x86/kernel/cpu/bugs.c:2935: "Unpatched
 return thunk in use. This should not happen!" [STACKTRACE]

On Tue, Apr 02, 2024 at 08:38:56AM -0500, Michael Roth wrote:
> On Tue, Apr 02, 2024 at 12:15:49PM +0200, bp@...nel.org wrote:
> > From: Borislav Petkov <bp@...en8.de>
> > 
> > Sorry if this comes out weird - mail troubles currently.
> > 
> > On Thu, Mar 28, 2024 at 07:38:30AM -0500, Michael Roth wrote:
> > > I'm seeing it pretty consistently on kvm/next as well. Not sure if
> > > there's anything special about my config but starting a fairly basic
> > > SVM guest seems to be enough to trigger it for me on the first
> > > invocation of svm_vcpu_run().
> > 
> > Hmm, can you share your config and what exactly you're doing?
> > 
> > I can't reproduce with Mirsad's reproducer, probably because of .config
> > differences. I tried making all CONFIG*KVM* options =y but no
> > difference.
> 
> I've reproduced against tip/master from today and attached the host
> config I used.
> 
> I can reproduce with a normal SVM guest using the following cmdline,
> but I don't think there's anything particular special regarding what
> QEMU options you use. It seems to trigger on the very first entry into
> VMRUN path:
> 
>   /home/mroth/qemu-build-snp-v4-wip2/qemu-system-x86_64
>     -smp 32,maxcpus=255 -cpu EPYC-Milan-v2 -overcommit cpu-pm=off
>     -enable-kvm -m 4G,slots=5,maxmem=210G -vga std -nographic
>     -machine pc,memory-backend=ram1
>     -object memory-backend-memfd,id=ram1,size=4G,share=true,prealloc=false,reserve=false
>     -device virtio-scsi-pci,id=scsi0,disable-legacy=on,iommu_platform=true
>     -drive file=/home/mroth/ubuntu-18.04-seves2.qcow2,if=none,id=drive0,snapshot=on
>     -device scsi-hd,id=hd0,drive=drive0,bus=scsi0.0
>     -device virtio-net-pci,mac=52:54:00:6c:3c:01,netdev=netdev0,id=net0,disable-legacy=on,iommu_platform=true,romfile=
>     -netdev tap,script=/home/mroth/qemu-ifup,id=netdev0
>     -L /home/mroth/AMDSEV/snp-release-2024-02-22/usr/local/share/qemu
>     -msg timestamp=on
>     -drive if=pflash,format=raw,unit=0,file=/home/mroth/AMDSEV/snp-release-2024-02-22/usr/local/share/qemu/OVMF_CODE.fd,readonly=on
>     -drive if=pflash,format=raw,unit=1,file=/home/mroth/AMDSEV/snp-release-2024-02-22/usr/local/share/qemu/OVMF_VARS.fd
> 
> I can also trigger using one of the more basic KVM selftests:
> 
>   make INSTALL_HDR_PATH="$headers_dir" headers_install
>   make -C tools/testing/selftests TARGETS="kvm" EXTRA_CFLAGS="-DDEBUG -I$headers_dir"
>   sudo tools/testing/selftests/kvm/userspace_io_test

Ok, thanks, that helped.

Problem is:

7f4b5cde2409 ("kvm: Disable objtool frame pointer checking for vmenter.S")

it is disabling checking of the arch/x86/kvm/svm/vmenter.S by objtool
when CONFIG_FRAME_POINTER=y but that also leads to objtool *not*
generating .return_sites and the return thunk remains unpatched.

I think we need to say: ignore frame pointer checking but still generate
return_sites.

Josh, ideas?

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette