linux-kernel - Re: [syzbot ci] Re: KVM: x86: Unify L1TF flushing under per-CPU variable

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: <DDI0QRWVTMQT.3BA2T46YJLIII@google.com>
Date: Tue, 14 Oct 2025 11:46:27 +0000
From: Brendan Jackman <jackmanb@...gle.com>
To: Brendan Jackman <jackmanb@...gle.com>, 
	syzbot ci <syzbot+ci693402a94575bcb2@...kaller.appspotmail.com>, <bp@...en8.de>, 
	<dave.hansen@...ux.intel.com>, <hpa@...or.com>, <kvm@...r.kernel.org>, 
	<linux-kernel@...r.kernel.org>, <mingo@...hat.com>, <pbonzini@...hat.com>, 
	<seanjc@...gle.com>, <tglx@...utronix.de>, <x86@...nel.org>
Cc: <syzbot@...ts.linux.dev>, <syzkaller-bugs@...glegroups.com>
Subject: Re: [syzbot ci] Re: KVM: x86: Unify L1TF flushing under per-CPU variable

On Tue Oct 14, 2025 at 8:57 AM UTC, Brendan Jackman wrote:
> On Tue Oct 14, 2025 at 6:13 AM UTC, syzbot ci wrote:
>> BUG: using __this_cpu_write() in preemptible code in x86_emulate_instruction
>
> Ah. And now I realise I never booted my debug config on an actual
> Skylake host, I'd better do that, presumably running the KVM selftests
> with DEBUG_PREEMPT etc would have been enough to catch this earlier.
>
> Anyway, I guest we just want to use vcpu->arch.last_vmentry_cpu instead
> of smp_processor_id()?

Just went to code it up and changed my mind about this. If the vCPU is
being migrated, it doesn't really matter which CPU stuff like
x86_emulate_instruction() sets the bit on since it's vcpu_load()'s job to
make sure it's set on the CPU that actually needs it. So I think instead
we just want raw_cpu_write() here, then there's no pointless remote
updates. The bit might get set on a CPU that doesn't end up needing it
for the current vCPU, but it was gonna get the bit set before it ran the
next vCPU anyway.