From patchwork Wed Jan 24 02:41:34 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Yang, Weijiang" X-Patchwork-Id: 191300 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:2553:b0:103:945f:af90 with SMTP id p19csp740041dyi; Tue, 23 Jan 2024 18:50:38 -0800 (PST) X-Google-Smtp-Source: AGHT+IG8BwxhScDEnf8h1jU/KSqtR5sbg2Spw0AFD8IXoCxZQSHiHAsaK7OxXJrEdUcAf1eGXZVu X-Received: by 2002:a17:903:2589:b0:1d6:fff6:2fc9 with SMTP id jb9-20020a170903258900b001d6fff62fc9mr159902plb.64.1706064638706; Tue, 23 Jan 2024 18:50:38 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706064638; cv=pass; d=google.com; s=arc-20160816; b=KjF1HQhDnRehToL/TZvFjDVAA0laaJXvXuTvg/j6ba5xtbxlG1a4w+opk5mN2XClEA gkVhZEPUVcq4N4EXQlN5Xo7bTBjgWv8HbkJZMG506iirDWY/q0RrXXO+AIyxUYcqpeLR s1ld1yAVaxFwmUxbvsLE2yfTD5CGu3P9C9PpslyHbfi2XzYnPSX6LJCpdJjxh2nWjrmn Rw2lr8NoEYL6q0IySbroDI3ETLoL1YHum3l8jHjQ8GgXOB+YOVgW0ti8fifYp3G1Az9F iixtK1fiBMWUxb3Dp416LZoaNWlzzAdE3T3zhEPwGh5zZXoxXU6y/kvu+OGcB8nODnPK 9W4w== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=mV2bq58ycyg1LFuciIh50RjNESRmqVAe6x0wSkquCB4=; fh=D+u40KSnYgjUYLGDRdXdD62xsMHg3nFDmpf3sEnyojA=; b=u42PSQx9EQc3KdRDLHpx+37LI2OHWFVWov+hGZ3R3cPhgp9SIUDsRD+cJEXDzYNG1F b0v7vMwLiFg0FnqaAT+85BUh5Ontwsm5oc1LHmZKpJA1ynUS118cRTi8dewu2O6BTPWN Xcd3gxFZyOBDo0V5n0/Ibvjqrsngd1kk2yWugEYrKjpaKMrQluTv7k+2CY2WgkP5/mdX /02nBUILXc7DfJG2DN6twdAMTjHJi38OsyfYmhUF74/iWy3j7bswmMmVZt0YNU5GW4Df cWEN9hXG1DxqjcE4u8hzrFC5XXpGTu+6wxIxP5V54+kMW70RnXnRr7qIapiSM7sMrY9C wVRw== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=QKJ7czjw; arc=pass (i=1 spf=pass spfdomain=intel.com dkim=pass dkdomain=intel.com dmarc=pass fromdomain=intel.com); spf=pass (google.com: domain of linux-kernel+bounces-36322-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-36322-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [2604:1380:40f1:3f00::1]) by mx.google.com with ESMTPS id j12-20020a170902c3cc00b001d6ee361679si960241plj.489.2024.01.23.18.50.38 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Jan 2024 18:50:38 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-36322-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=QKJ7czjw; arc=pass (i=1 spf=pass spfdomain=intel.com dkim=pass dkdomain=intel.com dmarc=pass fromdomain=intel.com); spf=pass (google.com: domain of linux-kernel+bounces-36322-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-36322-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id 0589CB20D11 for ; Wed, 24 Jan 2024 02:44:28 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id D646E168B1; Wed, 24 Jan 2024 02:42:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="QKJ7czjw" Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2F02FBE6E; Wed, 24 Jan 2024 02:42:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.55.52.120 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706064155; cv=none; b=T2zwGThiu+zmpVfGuIQbQArg/te3Vo9s9tuP6GJS51cc8hkS+HuZbtpX0D4+vIL15HoW8MVBzgwbTMzYcs2V57r3V97gnn0Wu3ureoxps6RnjamNudFp+ypaSTUzFK57J0pYftfwmxgUZfIedCoF0tqzc1IBjGHLrKjnLwidJog= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706064155; c=relaxed/simple; bh=VvF0PBScwCsWmxl1ZnSXv9NBr/c+xJKpYRCNE4wuI0c=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=NKn+N+TcACWYtpXDuxVJwMza4noRByafF8N6uBxUSWtapDYHWpNAgi5rMfzwgfBRliwxfESu1hziRUpRPHPn7b7YJWP8ldPlj5ChhBpNpScMcSw6yYQgcZepIDCEH/ZEHZQT5hyDEpKHLkO/WG24mPm8MjETY1bD7GjPuFOcfJg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=QKJ7czjw; arc=none smtp.client-ip=192.55.52.120 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1706064153; x=1737600153; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=VvF0PBScwCsWmxl1ZnSXv9NBr/c+xJKpYRCNE4wuI0c=; b=QKJ7czjwLaBA5ABb6qSmRj2OSeRhFo/hR81D2BgiiMPZoWiSGj6ORfOb MsHy6vkL2sTEKXVxe3R/CEOjTE/oYh65ZaxYdSRfMTi4hCCGzXXHYfTw5 ir0mDebBqCBE5mN0z4Qq3/Iv1LTeY0/ONeSLwR97TdyqzoThN7RH1r8L8 PxpZ64B3doOhK37tFErsLdXdYNDhKMMk3GKJXMEjL5RhVocplLovmX92W 4rSNjC93g0K5Gw0yfGn/bfh3R7lN5NNpqq9r/zHG6fsaM2S08KVB16CYg R2joTnZ1nZeV9erfBauGvzEcJ+gMOoH1Ge6X6U4RL5Hs07CWzuz1oQkyr A==; X-IronPort-AV: E=McAfee;i="6600,9927,10962"; a="400586417" X-IronPort-AV: E=Sophos;i="6.05,215,1701158400"; d="scan'208";a="400586417" Received: from fmviesa003.fm.intel.com ([10.60.135.143]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Jan 2024 18:42:30 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.05,215,1701158400"; d="scan'208";a="1825812" Received: from 984fee00a5ca.jf.intel.com ([10.165.9.183]) by fmviesa003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Jan 2024 18:42:30 -0800 From: Yang Weijiang To: seanjc@google.com, pbonzini@redhat.com, dave.hansen@intel.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, x86@kernel.org, yuan.yao@linux.intel.com Cc: peterz@infradead.org, chao.gao@intel.com, rick.p.edgecombe@intel.com, mlevitsk@redhat.com, john.allen@amd.com, weijiang.yang@intel.com Subject: [PATCH v9 01/27] x86/fpu/xstate: Always preserve non-user xfeatures/flags in __state_perm Date: Tue, 23 Jan 2024 18:41:34 -0800 Message-Id: <20240124024200.102792-2-weijiang.yang@intel.com> X-Mailer: git-send-email 2.39.3 In-Reply-To: <20240124024200.102792-1-weijiang.yang@intel.com> References: <20240124024200.102792-1-weijiang.yang@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1788938434439727049 X-GMAIL-MSGID: 1788938434439727049 From: Sean Christopherson When granting userspace or a KVM guest access to an xfeature, preserve the entity's existing supervisor and software-defined permissions as tracked by __state_perm, i.e. use __state_perm to track *all* permissions even though all supported supervisor xfeatures are granted to all FPUs and FPU_GUEST_PERM_LOCKED disallows changing permissions. Effectively clobbering supervisor permissions results in inconsistent behavior, as xstate_get_group_perm() will report supervisor features for process that do NOT request access to dynamic user xfeatures, whereas any and all supervisor features will be absent from the set of permissions for any process that is granted access to one or more dynamic xfeatures (which right now means AMX). The inconsistency isn't problematic because fpu_xstate_prctl() already strips out everything except user xfeatures: case ARCH_GET_XCOMP_PERM: /* * Lockless snapshot as it can also change right after the * dropping the lock. */ permitted = xstate_get_host_group_perm(); permitted &= XFEATURE_MASK_USER_SUPPORTED; return put_user(permitted, uptr); case ARCH_GET_XCOMP_GUEST_PERM: permitted = xstate_get_guest_group_perm(); permitted &= XFEATURE_MASK_USER_SUPPORTED; return put_user(permitted, uptr); and similarly KVM doesn't apply the __state_perm to supervisor states (kvm_get_filtered_xcr0() incorporates xstate_get_guest_group_perm()): case 0xd: { u64 permitted_xcr0 = kvm_get_filtered_xcr0(); u64 permitted_xss = kvm_caps.supported_xss; But if KVM in particular were to ever change, dropping supervisor permissions would result in subtle bugs in KVM's reporting of supported CPUID settings. And the above behavior also means that having supervisor xfeatures in __state_perm is correctly handled by all users. Dropping supervisor permissions also creates another landmine for KVM. If more dynamic user xfeatures are ever added, requesting access to multiple xfeatures in separate ARCH_REQ_XCOMP_GUEST_PERM calls will result in the second invocation of __xstate_request_perm() computing the wrong ksize, as as the mask passed to xstate_calculate_size() would not contain *any* supervisor features. Commit 781c64bfcb73 ("x86/fpu/xstate: Handle supervisor states in XSTATE permissions") fudged around the size issue for userspace FPUs, but for reasons unknown skipped guest FPUs. Lack of a fix for KVM "works" only because KVM doesn't yet support virtualizing features that have supervisor xfeatures, i.e. as of today, KVM guest FPUs will never need the relevant xfeatures. Simply extending the hack-a-fix for guests would temporarily solve the ksize issue, but wouldn't address the inconsistency issue and would leave another lurking pitfall for KVM. KVM support for virtualizing CET will likely add CET_KERNEL as a guest-only xfeature, i.e. CET_KERNEL will not be set in xfeatures_mask_supervisor() and would again be dropped when granting access to dynamic xfeatures. Note, the existing clobbering behavior is rather subtle. The @permitted parameter to __xstate_request_perm() comes from: permitted = xstate_get_group_perm(guest); which is either fpu->guest_perm.__state_perm or fpu->perm.__state_perm, where __state_perm is initialized to: fpu->perm.__state_perm = fpu_kernel_cfg.default_features; and copied to the guest side of things: /* Same defaults for guests */ fpu->guest_perm = fpu->perm; fpu_kernel_cfg.default_features contains everything except the dynamic xfeatures, i.e. everything except XFEATURE_MASK_XTILE_DATA: fpu_kernel_cfg.default_features = fpu_kernel_cfg.max_features; fpu_kernel_cfg.default_features &= ~XFEATURE_MASK_USER_DYNAMIC; When __xstate_request_perm() restricts the local "mask" variable to compute the user state size: mask &= XFEATURE_MASK_USER_SUPPORTED; usize = xstate_calculate_size(mask, false); it subtly overwrites the target __state_perm with "mask" containing only user xfeatures: perm = guest ? &fpu->guest_perm : &fpu->perm; /* Pairs with the READ_ONCE() in xstate_get_group_perm() */ WRITE_ONCE(perm->__state_perm, mask); Cc: Maxim Levitsky Cc: Weijiang Yang Cc: Dave Hansen Cc: Paolo Bonzini Cc: Peter Zijlstra Cc: Chao Gao Cc: Rick Edgecombe Cc: John Allen Cc: kvm@vger.kernel.org Link: https://lore.kernel.org/all/ZTqgzZl-reO1m01I@google.com Signed-off-by: Sean Christopherson Signed-off-by: Yang Weijiang Reviewed-by: Maxim Levitsky Reviewed-by: Rick Edgecombe --- arch/x86/kernel/fpu/xstate.c | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c index 117e74c44e75..07911532b108 100644 --- a/arch/x86/kernel/fpu/xstate.c +++ b/arch/x86/kernel/fpu/xstate.c @@ -1601,16 +1601,20 @@ static int __xstate_request_perm(u64 permitted, u64 requested, bool guest) if ((permitted & requested) == requested) return 0; - /* Calculate the resulting kernel state size */ + /* + * Calculate the resulting kernel state size. Note, @permitted also + * contains supervisor xfeatures even though supervisor are always + * permitted for kernel and guest FPUs, and never permitted for user + * FPUs. + */ mask = permitted | requested; - /* Take supervisor states into account on the host */ - if (!guest) - mask |= xfeatures_mask_supervisor(); ksize = xstate_calculate_size(mask, compacted); - /* Calculate the resulting user state size */ - mask &= XFEATURE_MASK_USER_SUPPORTED; - usize = xstate_calculate_size(mask, false); + /* + * Calculate the resulting user state size. Take care not to clobber + * the supervisor xfeatures in the new mask! + */ + usize = xstate_calculate_size(mask & XFEATURE_MASK_USER_SUPPORTED, false); if (!guest) { ret = validate_sigaltstack(usize);