Received-SPF: pass (google.com: domain of linux-kernel+bounces-129708-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Wed, 3 Apr 2024 14:14:36 +0200
From: Borislav Petkov <bp@alien8.de>
To: Michael Roth <michael.roth@amd.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>
Cc: bp@kernel.org, bgardon@google.com, dave.hansen@linux.intel.com,
	dmatlack@google.com, hpa@zytor.com, jpoimboe@kernel.org,
	kvm@vger.kernel.org, leitao@debian.org,
	linux-kernel@vger.kernel.org, maz@kernel.org, mingo@redhat.com,
	mirsad.todorovac@alu.unizg.hr, pawan.kumar.gupta@linux.intel.com,
	pbonzini@redhat.com, peterz@infradead.org, seanjc@google.com,
	shahuang@redhat.com, tabba@google.com, tglx@linutronix.de,
	x86@kernel.org
Subject: Re: [BUG net-next] arch/x86/kernel/cpu/bugs.c:2935: "Unpatched
 return thunk in use. This should not happen!" [STACKTRACE]
Message-ID: <20240403121436.GDZg1ILCn0a4Ddif3g@fat_crate.local>
References: <1d10cd73-2ae7-42d5-a318-2f9facc42bbe@alu.unizg.hr>
 <20240318202124.GCZfiiRGVV0angYI9j@fat_crate.local>
 <12619bd4-9e9e-4883-8706-55d050a4d11a@alu.unizg.hr>
 <20240326101642.GAZgKgisKXLvggu8Cz@fat_crate.local>
 <8fc784c2-2aad-4d1d-ba0f-e5ab69d28ec5@alu.unizg.hr>
 <20240328123830.dma3nnmmlb7r52ic@amd.com>
 <20240402101549.5166-1-bp@kernel.org>
 <20240402133856.dtzinbbudsu7rg7d@amd.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20240402133856.dtzinbbudsu7rg7d@amd.com>

On Tue, Apr 02, 2024 at 08:38:56AM -0500, Michael Roth wrote:
> On Tue, Apr 02, 2024 at 12:15:49PM +0200, bp@kernel.org wrote:
> > From: Borislav Petkov <bp@alien8.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