From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f201.google.com (mail-pg1-f201.google.com [209.85.215.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1C641328273 for ; Sat, 7 Mar 2026 01:51:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772848335; cv=none; b=JlNeRe3ntT0eHCtqNLfgL+/zz1fRs0AMzRdT1rg6RPBu5RW/CB3gZzDKB8ouKD5p41sO4UodwG35FkDNvVfQjWQgkcYe4p23JhSp6xQ0OaNJnzPGPT51foXrYxorpnUnWqkYWypSQedwlHsWA7c1NaGMiKzYoVOoqEEtredTGvA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772848335; c=relaxed/simple; bh=9TdYo2hrAmXwNx2QzpsSdZDhIlxyPDORKhsBkkATOPk=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=CjrDzH7wIgU2dmi30racbhihoWuYYennC3lFH8LcRTfU8XRh6oHUp5Ea63v4GEl5uPHMWumYSSD72WjNucvvMq/0WzO69AXQ6ngQhtOkFQr9S/fxTUBHU6+F8VWDVWjc0SitYw3sZ5BzzmbTfd9W845tWx5u8BfCbDu5d1Mjj0Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=MdTcTb1b; arc=none smtp.client-ip=209.85.215.201 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="MdTcTb1b" Received: by mail-pg1-f201.google.com with SMTP id 41be03b00d2f7-c70dd30025fso35835461a12.2 for ; Fri, 06 Mar 2026 17:51:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1772848317; x=1773453117; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=X8Y0ox6GXyJuz0HXLsf/EcxN0tNLkLTey5RZvxhe0co=; b=MdTcTb1bk+5pXMZdK4gOI52ANZKkrnKT6cTYABu/QZ2SMG6hHpRbLr2iC3fL3xvkFk fRBmZ2nk+x66QfGIg+FS2eBerROsfsGpdGhTkKJ1T+HWQgeFbj9PrRJUkdUMbohBhnNm akXHWL7MB3wMJ9tjvXbSoCbzV5yMMLTFnMfh3N4zP2PTNPV92YMY0oTZUmLm2PVA1r0M nvpcmTpyIdNJ5eUc4iT8ALCbCqR290jE/pgwmTagPViuWXtgCyzY8oLL5PASl4WvBkuW iY8O4ci+0uRAZfIt9RcCnSdpYFPH1QhZnnhQEG93hwsUY6rt3QCUXPCX+le0hon9FR8/ Ethw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772848317; x=1773453117; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=X8Y0ox6GXyJuz0HXLsf/EcxN0tNLkLTey5RZvxhe0co=; b=fb0SRH+8XSm9lrVJEMKm5x/u0q5dRgRLpHjzYRMWAuvA9+E18W5hzKnGfY8PRQCisz fbl1fyHrOpuV4umtv8/dq63KkWcKbXbmmTTA20042ppaWsoAx87MtX3jcGYJtAICJdYV OoO7Kw8BDo/KT795JNH2jdYRLHoKgcNFLd3nPPMlc4eKmPpQQK79UN3xfCnQaFM1NQjx YTBS32DB5Zz3xv4uFNpvyR+b5sCjQh26RHFrQmkBDf0PH6b8k8yvX+lwIiqUGILUKSfK vkM4r0oD/n084UdZoBO+ZVHshrhHP7TmUllIEvg8ZU1pIMDAV3pfdSBKvNhJpkglfWQT SA2A== X-Forwarded-Encrypted: i=1; AJvYcCXUlP90GwoZjUR7ljqfWqhnHfZaDzBfI7AaqHxrhLVbd9/FE63/s/xMbZkplOF5xk363BGeAf630+m2rD8=@vger.kernel.org X-Gm-Message-State: AOJu0Yyc1SG1BUYK387c2qQtEvKl/8Pu41mvedVEXZh8X4UdkwgTinS8 ABMqWQDSMCnsqurDzmhUmr0QIySAZQ0mmW64T1BFji8YoknVJGPOlYP5tYiQqIMI+3D/NE+KmdX QyBxuxA== X-Received: from pfbbj28.prod.google.com ([2002:a05:6a00:319c:b0:827:44d1:121d]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:3c8a:b0:829:86aa:e168 with SMTP id d2e1a72fcca58-829a2d655a2mr3760934b3a.8.1772848317055; Fri, 06 Mar 2026 17:51:57 -0800 (PST) Date: Fri, 6 Mar 2026 17:51:55 -0800 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <928a31e1-bb6f-44d4-b1de-654d6968fd55@fortanix.com> <64a01647-2f99-44a8-a183-702d6eb6fd81@fortanix.com> Message-ID: Subject: Re: [PATCH] KVM: SEV: Track SNP launch state and disallow invalid userspace interactions From: Sean Christopherson To: Jethro Beekman Cc: Paolo Bonzini , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-coco@lists.linux.dev Content-Type: text/plain; charset="us-ascii" On Thu, Feb 26, 2026, Sean Christopherson wrote: > On Wed, Feb 25, 2026, Jethro Beekman wrote: > > On 2026-02-25 12:21, Sean Christopherson wrote: > > > On Wed, Feb 25, 2026, Jethro Beekman wrote: > > >> On 2026-02-25 12:05, Sean Christopherson wrote: > > >>> On Mon, Jan 19, 2026, Jethro Beekman wrote: > > >>>> Calling any of the SNP_LAUNCH_ ioctls after SNP_LAUNCH_FINISH results in a > > >>>> kernel page fault due to RMP violation. Track SNP launch state and exit early. > > >>> > > >>> What exactly trips the RMP #PF? A backtrace would be especially helpful for > > >>> posterity. > > >> > > >> Here's a backtrace for calling ioctl(KVM_SEV_SNP_LAUNCH_FINISH) twice. Note this is with a modified version of QEMU. > > > > > >> RIP: 0010:sev_es_sync_vmsa+0x54/0x4c0 [kvm_amd] > > >> snp_launch_update_vmsa+0x19d/0x290 [kvm_amd] > > >> snp_launch_finish+0xb6/0x380 [kvm_amd] > > >> sev_mem_enc_ioctl+0x14e/0x720 [kvm_amd] > > >> kvm_arch_vm_ioctl+0x837/0xcf0 [kvm] > > > > > > Ah, it's the VMSA that's being accessed. Can't we just do? > > > > > > diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c > > > index 723f4452302a..1e40ae592c93 100644 > > > --- a/arch/x86/kvm/svm/sev.c > > > +++ b/arch/x86/kvm/svm/sev.c > > > @@ -882,6 +882,9 @@ static int sev_es_sync_vmsa(struct vcpu_svm *svm) > > > u8 *d; > > > int i; > > > > > > + if (vcpu->arch.guest_state_protected) > > > + return -EINVAL; > > > + > > > /* Check some debug related fields before encrypting the VMSA */ > > > if (svm->vcpu.guest_debug || (svm->vmcb->save.dr7 & ~DR7_FIXED_1)) > > > return -EINVAL; > > > > I tried relying on guest_state_protected instead of creating new state but I > > don't think it's sufficient. In particular, your proposal may fix > > snp_launch_finish() > > But it does fix that case, correct? I don't want to complicate one fix just > because there are other bugs that are similar but yet distinct. > > > but I don't believe this addresses the issues in snp_launch_update() and > > Do you mean snp_launch_update_vmsa() here? Or am I missing an interaction with > vCPUs in snp_launch_update()? > > > sev_vcpu_create(). > > There are a pile of SEV lifecycle and locking issues, i.e. this is just one of > several flaws. Fixing the locking has been on my todo list for a few months (we > found some "fun" bugs with an internal run of syzkaller), and I'm finally getting > to it. Hopefully I'll post a series early next week. > > Somewhat off the cuff, but I think the easiest way to close the race between > KVM_CREATE_VCPU and KVM_SEV_SNP_LAUNCH_FINISH is to reject KVM_SEV_SNP_LAUNCH_FINISH > if a vCPU is being created. Or did I misunderstand the race you're pointing out? > > Though unless there's a strong reason not to, I'd prefer to get greedy and block > all of sev_mem_enc_ioctl(), e.g. Circling back to this (writing changelogs), I don't think there's actually a novel bug with respect to KVM_SEV_SNP_LAUNCH_FINISH racing with KVM_CREATE_VCPU. kvm_for_each_vcpu() operates on online_vcpus, LAUNCH_FINISH (all SEV+ sub-ioctls) holds kvm->mutex, and fully onlining a vCPU in kvm_vm_ioctl_create_vcpu() is done under kvm->mutex. So AFAICT, there's no difference between an in-progress vCPU and a vCPU that is created entirely after LAUNCH_FINISH. It's probably worth preventing as a hardening measure, but I don't think there's an actual bug to be fixed.