From patchwork Sat Mar 16 03:43:44 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Chengen Du X-Patchwork-Id: 1912777 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=lists.ubuntu.com (client-ip=185.125.189.65; helo=lists.ubuntu.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=patchwork.ozlabs.org) Received: from lists.ubuntu.com (lists.ubuntu.com [185.125.189.65]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4TxRnF5Szsz23s6 for ; Sat, 16 Mar 2024 14:44:17 +1100 (AEDT) Received: from localhost ([127.0.0.1] helo=lists.ubuntu.com) by lists.ubuntu.com with esmtp (Exim 4.86_2) (envelope-from ) id 1rlKxq-0004oy-B4; Sat, 16 Mar 2024 03:44:06 +0000 Received: from smtp-relay-internal-1.internal ([10.131.114.114] helo=smtp-relay-internal-1.canonical.com) by lists.ubuntu.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1rlKxe-0004mn-01 for kernel-team@lists.ubuntu.com; Sat, 16 Mar 2024 03:43:54 +0000 Received: from mail-pl1-f197.google.com (mail-pl1-f197.google.com [209.85.214.197]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-1.canonical.com (Postfix) with ESMTPS id D51AE3F628 for ; Sat, 16 Mar 2024 03:43:53 +0000 (UTC) Received: by mail-pl1-f197.google.com with SMTP id d9443c01a7336-1dd96aefa68so26882235ad.3 for ; Fri, 15 Mar 2024 20:43:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710560632; x=1711165432; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=HirGJy2rKe7zCYoDDRcqrcjlXBghB/kGGTisaRq1bOE=; b=ro5yxqlWU6NWFgccnJpb0lbhCGHDjgPLX40zwNCA0srqRZo+3OBHGOysVs2jE9j64p zmYkXPyQhPpbeMm0TSc30I4R4INppmZl0/0tc7G/aNH3MTmVTRm8l2glairjfY7IDOhE g8wfCJ/XA6lcZphjWgDVszaPKhmw7QY00hK/pwD9DOSbmXQYPf7Xbdiw/TbIfTc9FXlI AAZJThsIo4IlduuBidPR8NDsmVrLoiOypFAoQ3V3bpztZKqlyDM8C/+KJmU7xNU3Og2M Gy2E2CLj5GOGIpgYEzbdahCPCmb7HYXDn83ViIOu9bmii3v4yPQQA837jXj5REa/8Bt/ sNcw== X-Gm-Message-State: AOJu0YxhN+czLnItyRml1cnQrdhbcVlp6cYQV45GPkirp0nc2jZvmBUw 12UGVK3V5i1FziqSwUg9lW4m+M1MhPe8LbgiQRfBAaeT6A8ubK3/FzFe87Uxu0DHFOqqKj8CdUl Ceg4rNGnQZFDV+D2Hir+7QT9JRv2Pc5744tGdymoHjSTqZE3LF5dZjh3Olp6OT7AH9HNYbn96+6 XIqSqJDqjYPw== X-Received: by 2002:a17:902:c401:b0:1dd:dac3:297e with SMTP id k1-20020a170902c40100b001dddac3297emr9079272plk.13.1710560632205; Fri, 15 Mar 2024 20:43:52 -0700 (PDT) X-Google-Smtp-Source: AGHT+IG7GL4eZifEaHTtVxDGBWALYrhajwJgQEly5PHAsP48THlSOZXQiOzm8FtYft5CbYOkIKyd4w== X-Received: by 2002:a17:902:c401:b0:1dd:dac3:297e with SMTP id k1-20020a170902c40100b001dddac3297emr9079258plk.13.1710560631899; Fri, 15 Mar 2024 20:43:51 -0700 (PDT) Received: from chengendu.. (111-248-145-30.dynamic-ip.hinet.net. [111.248.145.30]) by smtp.gmail.com with ESMTPSA id ki3-20020a170903068300b001dd02f4c2casm4695740plb.164.2024.03.15.20.43.50 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Mar 2024 20:43:51 -0700 (PDT) From: Chengen Du To: kernel-team@lists.ubuntu.com Subject: [SRU][J][PATCH 2/2] KVM: x86: Constrain guest-supported xfeatures only at KVM_GET_XSAVE{2} Date: Sat, 16 Mar 2024 11:43:44 +0800 Message-Id: <20240316034344.17515-3-chengen.du@canonical.com> X-Mailer: git-send-email 2.40.1 In-Reply-To: <20240316034344.17515-1-chengen.du@canonical.com> References: <20240316034344.17515-1-chengen.du@canonical.com> MIME-Version: 1.0 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Sean Christopherson BugLink: https://bugs.launchpad.net/bugs/2032164 Mask off xfeatures that aren't exposed to the guest only when saving guest state via KVM_GET_XSAVE{2} instead of modifying user_xfeatures directly. Preserving the maximal set of xfeatures in user_xfeatures restores KVM's ABI for KVM_SET_XSAVE, which prior to commit ad856280ddea ("x86/kvm/fpu: Limit guest user_xfeatures to supported bits of XCR0") allowed userspace to load xfeatures that are supported by the host, irrespective of what xfeatures are exposed to the guest. There is no known use case where userspace *intentionally* loads xfeatures that aren't exposed to the guest, but the bug fixed by commit ad856280ddea was specifically that KVM_GET_SAVE{2} would save xfeatures that weren't exposed to the guest, e.g. would lead to userspace unintentionally loading guest-unsupported xfeatures when live migrating a VM. Restricting KVM_SET_XSAVE to guest-supported xfeatures is especially problematic for QEMU-based setups, as QEMU has a bug where instead of terminating the VM if KVM_SET_XSAVE fails, QEMU instead simply stops loading guest state, i.e. resumes the guest after live migration with incomplete guest state, and ultimately results in guest data corruption. Note, letting userspace restore all host-supported xfeatures does not fix setups where a VM is migrated from a host *without* commit ad856280ddea, to a target with a subset of host-supported xfeatures. However there is no way to safely address that scenario, e.g. KVM could silently drop the unsupported features, but that would be a clear violation of KVM's ABI and so would require userspace to opt-in, at which point userspace could simply be updated to sanitize the to-be-loaded XSAVE state. Reported-by: Tyler Stachecki Closes: https://lore.kernel.org/all/20230914010003.358162-1-tstachecki@bloomberg.net Fixes: ad856280ddea ("x86/kvm/fpu: Limit guest user_xfeatures to supported bits of XCR0") Cc: stable@vger.kernel.org Cc: Leonardo Bras Signed-off-by: Sean Christopherson Acked-by: Dave Hansen Message-Id: <20230928001956.924301-3-seanjc@google.com> Signed-off-by: Paolo Bonzini (backported from commit 8647c52e9504c99752a39f1d44f6268f82c40a5c) [chengen - ignore changes related to fpstate_realloc and kvm_vcpu_after_set_cpuid because the commits associated with them are not included] Signed-off-by: Chengen Du --- arch/x86/kvm/x86.c | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index efa794d5436f..07c71892d5ae 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -4866,12 +4866,26 @@ static int kvm_vcpu_ioctl_x86_set_debugregs(struct kvm_vcpu *vcpu, static void kvm_vcpu_ioctl_x86_get_xsave2(struct kvm_vcpu *vcpu, u8 *state, unsigned int size) { + /* + * Only copy state for features that are enabled for the guest. The + * state itself isn't problematic, but setting bits in the header for + * features that are supported in *this* host but not exposed to the + * guest can result in KVM_SET_XSAVE failing when live migrating to a + * compatible host without the features that are NOT exposed to the + * guest. + * + * FP+SSE can always be saved/restored via KVM_{G,S}ET_XSAVE, even if + * XSAVE/XCRO are not exposed to the guest, and even if XSAVE isn't + * supported by the host. + */ + u64 supported_xcr0 = vcpu->arch.guest_supported_xcr0 | + XFEATURE_MASK_FPSSE; + if (fpstate_is_confidential(&vcpu->arch.guest_fpu)) return; fpu_copy_guest_fpstate_to_uabi(&vcpu->arch.guest_fpu, state, size, - vcpu->arch.guest_fpu.fpstate->user_xfeatures, - vcpu->arch.pkru); + supported_xcr0, vcpu->arch.pkru); } static void kvm_vcpu_ioctl_x86_get_xsave(struct kvm_vcpu *vcpu,