From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f201.google.com (mail-pl1-f201.google.com [209.85.214.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 B606F213E89 for ; Thu, 12 Feb 2026 18:06:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770919565; cv=none; b=JwgIeZvYP/JgoV24hlzIYZc5eNn4pqjhv4zbY/E/So61zlGUC1B+mwwuSU16gKlvkZJg9WfgWGBdjLDx5BMD3vuTzU87LNlTq459DJ/K4JoYcQWxacIJOAWBMWa/9FT1J+c2vb+oD96Zup2+R1ZpwZTzmz4aSMregJrCXePJ9ps= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770919565; c=relaxed/simple; bh=/PhTShLKJnFrNnpl1K3iXkufMll13s2vVyT8kh98aS8=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=RPVyO28Z1PzErAWEcA/ODfIJD+/xd/gBpCkGhPRBG/jmtNdGCsPn66BwN96MU/cYfScStGur43RVNpyFXtVP74OLOkAqfSmdymz8k1z+NyC6VK/C/VkXMDMT5oqs+rkFeazshsBnIGx1oL6/ipeAhjnQB88l6qXpUHiuV8Vxh4M= 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=OqUhuym5; arc=none smtp.client-ip=209.85.214.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="OqUhuym5" Received: by mail-pl1-f201.google.com with SMTP id d9443c01a7336-2aad3f8367bso1209705ad.0 for ; Thu, 12 Feb 2026 10:06:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1770919564; x=1771524364; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=ZMIgyP3ebwffaPtNSS2oFUqMF8kt/CpMxALQFuPMxGE=; b=OqUhuym5zhRiheoRS7rSSfbBXgJhgVLaETTbvIax4116n7glB3939k65vZZJtlAx0o 1792DO2BKTmbP9g6itWPGEAJSUBrGutIQV2BLGYBL6oiaWduLPHvQvkMF7Juc/1m2cwH C4uSIczx1uWZwx0Bu1A4eYsBvIJWXKjc4TVkRxiZEavqnPuCA6/+FyPL0QUMXsQnFAnz DaNSm5BDhTV7HDQvypXfurOMi4HDgp87eAxh1t0SBs67+jfG8KyTVhddXA4BVzABUB+t 65oNQQuddZ4dLivQkpSYKy4x5mHPGqjtuLsKZICfeOChJWc5GxIqq5k9SdaenOraUOdn q+dA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770919564; x=1771524364; h=content-transfer-encoding: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=ZMIgyP3ebwffaPtNSS2oFUqMF8kt/CpMxALQFuPMxGE=; b=jKIevJRIlcwOXE7P4AKjO0gpZk7ivoWnZHyPBcSBxXrxgYTN0uIUwLacAoHwP+/e/f /9jCPT6kYEBVbQP8cX7KBtY42fYYe18IxpRmAMkw33o+7Gz76MgCFADg9ShTtC6m1O/s 62G6vS0jXU8tUWGVRi/BnsB7zEAmfDhj8HbgDukpbYqYXLI4K4Mf+tnnB9dkZ/RMcjqv 48BvqHWWGfvRH3G5fE7StZyonKr/XnKed44Ed4UQUhpytVqG07+6XVXhYMVqXnrrigYK XEaN12Ugd2F9FIW058L4QJ04hLqM0HOCwqtDO3eW9nT3dMJf89bR2iwK3VkMPuqa9zpw +6gQ== X-Forwarded-Encrypted: i=1; AJvYcCXVqMwIr/vaepAR97chq/cKLunuFCm13CE1KVi8a8tsF0+7gOtW65oAkJPvlwqrBQzFhg8V2wfHUMqzB8k=@vger.kernel.org X-Gm-Message-State: AOJu0YyoZP6fyPR6T5PSKZfDuf/m/I9f4ZM/gW0s4ul5LGEAKiTIvZDE gRvDB6vzFI+xJmpb1Oj4eni61bIWtnrkz6OI6dNHVM9Uta2klnM3WSAIfdTwRijXk27U/tcLovY UVsTY/Q== X-Received: from plblq5.prod.google.com ([2002:a17:903:1445:b0:2aa:d708:7f2]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6300:67c8:b0:38f:86c0:449 with SMTP id adf61e73a8af0-3944880f8dfmr3589217637.49.1770919563816; Thu, 12 Feb 2026 10:06:03 -0800 (PST) Date: Thu, 12 Feb 2026 10:06:02 -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: <20260212102854.15790-1-ubizjak@gmail.com> <0a1ad845-a15b-4901-a65c-2668580751ed@redhat.com> Message-ID: Subject: Re: [PATCH] KVM: x86: Fix incorrect memory constraint for FXSAVE in emulator From: Sean Christopherson To: Uros Bizjak Cc: Paolo Bonzini , kvm@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Thu, Feb 12, 2026, Uros Bizjak wrote: > On Thu, Feb 12, 2026 at 2:05=E2=80=AFPM Paolo Bonzini wrote: > > > > On 2/12/26 11:27, Uros Bizjak wrote: > > > The inline asm used to invoke FXSAVE in em_fxsave() and fxregs_fixup(= ) > > > incorrectly specifies the memory operand as read-write ("+m"). FXSAVE > > > does not read from the destination operand; it only writes the curren= t > > > FPU state to memory. > > > > > > Using a read-write constraint is incorrect and misleading, as it tell= s > > > the compiler that the previous contents of the buffer are consumed by > > > the instruction. In both cases, the buffer passed to FXSAVE is > > > uninitialized, and marking it as read-write can therefore create a > > > false dependency on uninitialized memory. > > > > > > Fix the constraint to write-only ("=3Dm") to accurately describe the > > > instruction=E2=80=99s behavior and avoid implying that the buffer is = read. > > > > IIRC FXSAVE/FXRSTOR may (at least on some microarchitectures?) leave > > reserved fields untouched. > > > > Intel suggests writing zeros first, and then the "+m" constraint would > > be the right one because "=3Dm" would cause the memset to be dead. >=20 > Please note that the struct is not initialized before fxsave, so if > "+m" is required, the struct should be initialized. Regardless of CPU behavior with respect to reserved fields, I believe "+m" = is correct and "=3Dm" is wrong, strictly speaking. The SDM very explicitly sa= ys: Bytes 464:511 are available to software use. The processor does not write= to bytes 464:511 of an FXSAVE area. I.e. the entirety of the struct isn't written by FXSAVE, and so using "=3Dm= " is technically wrong because those bytes are "read". In practice, it shouldn'= t matter because fxstate_size() (correctly) truncates the size to a max of 46= 4 bytes, so that KVM-as-the-virutal-CPU honors the architecture and doesn't w= rite to the software-available fields. I.e. those bytes should never truly be r= ead by software. Given that emulating FXSAVE/FXRSTOR can't possibly be hot paths, explicitly initializing the on-stack structs seems prudent, e.g. diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c index c8e292e9a24d..20ed588015f1 100644 --- a/arch/x86/kvm/emulate.c +++ b/arch/x86/kvm/emulate.c @@ -3708,7 +3708,7 @@ static inline size_t fxstate_size(struct x86_emulate_= ctxt *ctxt) */ static int em_fxsave(struct x86_emulate_ctxt *ctxt) { - struct fxregs_state fx_state; + struct fxregs_state fx_state =3D {}; int rc; =20 rc =3D check_fxsr(ctxt); @@ -3738,7 +3738,7 @@ static int em_fxsave(struct x86_emulate_ctxt *ctxt) static noinline int fxregs_fixup(struct fxregs_state *fx_state, const size_t used_size) { - struct fxregs_state fx_tmp; + struct fxregs_state fx_tmp =3D {}; int rc; =20 rc =3D asm_safe("fxsave %[fx]", , [fx] "+m"(fx_tmp));