From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f202.google.com (mail-pl1-f202.google.com [209.85.214.202]) (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 0C6241AA1C1 for ; Fri, 17 Jan 2025 22:10:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737151805; cv=none; b=RY2Kgzmed+UowxvT5JUf319R20U3hbQXoMao5lCr0R13MwAl6sel+QbfvwvEY4AeGTFUAXK39zVb339iv77/IVyWE3qxCRGlr0nAPgjOsd8vUdu/TRDy2527hcjegqeFIVonrAiaTee2URWh78y4eipByxs7OzUClp0iIINiTEo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737151805; c=relaxed/simple; bh=wQRBieXdRj66Xgwhl+/H9hLEolBFFXzhrBi6hy4Wn7M=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=jXPWjvRq4rtAKqYuerS1/C++1AboKZT5vZ0+vMypNcqPoGos6wqR3DFbpME0MwmM/6qq8wEQzgcWuE4JL5ET7XwDvBZSlGl1JBchmeniYOS/CrVwkhezNDDORCd7ItemislD3DcNEcS4ePpntSlI0NLDEQibWwaLYrRAmhpMMpk= 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=PtjEG3eF; arc=none smtp.client-ip=209.85.214.202 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="PtjEG3eF" Received: by mail-pl1-f202.google.com with SMTP id d9443c01a7336-21650d4612eso69972245ad.2 for ; Fri, 17 Jan 2025 14:10:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1737151803; x=1737756603; 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=0MJEu8uv8HNmEUEhfOhw/JUesqkb4Ln7AYGePHYaKko=; b=PtjEG3eFWVrvZDIDzTvtP5qOgEuZi6Pscs2ejLtynI4CRjfx9GBlpt4AGMIChLwO6N rVx3wQKBcIGEzeEXGodG8KVrG6imWTvQ/svfbwBuewB0BqpepkklgS1jHNeTHehxoA66 RccyK8xKXesGwuKplnCLy0rN79eHsPYfUJyTM4+gWnek2gcAPJLcndS0VcTYamR+xAaF lbExOlLUDIV+gOY069xZMVptzNZWy9aFOfSosfcJpMWwP4SMnOgfi79MGISlsmZQI4Qm vjO7t5CV1h4qo+ZzholfuT0KUlubos+gvMPkVRoKYmE5UgfmKmnTwcSatbIeIE5yezXW sJKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737151803; x=1737756603; 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=0MJEu8uv8HNmEUEhfOhw/JUesqkb4Ln7AYGePHYaKko=; b=DEjn9Trpth3GgmA07zW25xojgtSvFJTgOtgXtg3NkDquOmi9E+mctZX8LX1QNJT3I/ 7Zg/8I6dRs6/rgikugysZk5i3kQc5Ea/HgUWt7xqh7UmMqKmMk3wFD4opfoxYeROkeBN ZL28F7q6VEkmg+0DqbP9POYBJDwaPSDdlQusMZ+OoMyrF8LhInaX7/foLl1YmN0eBtSH dCg0pRQE0dlB4pWmyIN+KK+btLIKv3+/WuZdh+8BNkLJ+cyiLiPyoYHN3MzDmRiJ/l8P veYNOA+lkXlvGMu0bpe6Y0T9Q6OUDL9BY+IJJgB+bppPtSiZSC4aYD9biy6SorGWmCUP 7WjQ== X-Forwarded-Encrypted: i=1; AJvYcCXieWk2vk2OfDf4Zxt5P0vw6OEQYLyAS4LEjNyPpz83TSIT6Wb63/n0PdPDevzCX21jRenBDSRw5IpAEcQ=@vger.kernel.org X-Gm-Message-State: AOJu0Yxm9A+eRK2NZ3GeVt/K3SwMg8NCWdGx/UUcj17ikJyhAQc8cAW3 VmWGCA2swUQlEMEj6qtNnQf99VgQhHliURmgqJTq4MKfmcYh2ye93tRKEdOm2DY6jlAxw/2tkog 62Q== X-Google-Smtp-Source: AGHT+IF3HsmxE/qJt92nVkrFtGceBUHKxLsdMtuqz3ceB3rbfYhzzyEGy1z6iWrYHZBzRn74l6RCE5eoKv4= X-Received: from pfve11.prod.google.com ([2002:a05:6a00:1a8b:b0:725:ceac:b484]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a20:734e:b0:1e1:ac4f:d322 with SMTP id adf61e73a8af0-1eb214a0817mr6929907637.14.1737151803130; Fri, 17 Jan 2025 14:10:03 -0800 (PST) Date: Fri, 17 Jan 2025 14:10:01 -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: <20250102075419.2559-1-TonyWWang-oc@zhaoxin.com> Message-ID: Subject: Re: [PATCH] x86/fpu: Fix the os panic issue caused by the XGETBV instruction From: Sean Christopherson To: "Chang S. Bae" Cc: Tony W Wang-oc , tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, aruna.ramakrishna@oracle.com, pbonzini@redhat.com, levymitchell0@gmail.com, attofari@amazon.de, linux-kernel@vger.kernel.org, CobeChen@zhaoxin.com, TimGuo@zhaoxin.com, LeoLiu-oc@zhaoxin.com, Lyle Li Content-Type: text/plain; charset="us-ascii" On Wed, Jan 15, 2025, Chang S. Bae wrote: > On 1/1/2025 11:54 PM, Tony W Wang-oc wrote: > > From: Lyle Li > > > > The callers of the xfeatures_in_use function must ensure that the > > current processor has the X86_FEATURE_XGETBV1 feature. However, in some > > places where xfeatures_in_use is called, there is no check to see if the > > processor supports this feature, leading to the execution of the XGETBV > > XCR1 instruction on processors that do not support this feature, > > triggering a #GP exception, and ultimately causing an OS panic. > > I doubt this is a real issue. An XFD implementation without XGETBV1 is > considerably broken; every AMX system includes XGETBV1. Similarly, as far as > I can see, PKU implementations also include XGETBV1. QEMU's CPU feature list > [1] seems consistent with this. QEMU's CPU models are not authoritative when it comes to architecture, they are purely what CPUs hardware vendors have shipped. The absense of a model with PKU but not XGETBV1 simply reflects that neither Intel nor AMD have ever shipped such a model. > Maybe a wild clearcpuid use may clear off the XGETBV1 flag. Adding this > dependency to the table would make the relationship explicit: > > static const struct cpuid_dep cpuid_deps[] = { > ... > + { X86_FEATURE_PKU, X86_FEATURE_XGETBV1 }, > {} > }; > > Note that XFD is already listed as dependent on XGETBV1. > > But I doubt the kernel needs to be resilient to deliberately misconfigured > or crazy virtual machine setups. I don't see anything in the SDM that suggests this is a misconfigured CPU. Intel might not have plans to ship such CPUs, but AFAICT it's not a violation of the architecture as defined in the SDM. The SDM even explicitly says that protection keys can exist and be used without PKU state being supported in XSAVE at all, at which point assuming the existence of XGETBV1 is rather nonsensical. XCR0[9] is associated with PKRU state (see Section 13.5.7). Software can use the XSAVE feature set to manage PKRU state only if XCR0[9] = 1. The value of XCR0[9] in no way determines whether software can use protection keys or execute other instructions that access PKRU state (these instructions can be executed even if XCR0[9] = 0). XCR0[9] is 0 coming out of RESET. As noted in Section 13.2, a processor allows software to set XCR0[9] if and only if CPUID.(EAX=0DH,ECX=0):EAX[9] = 1.