Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp1482101ybh; Thu, 23 Jul 2020 09:57:34 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxCHspr5ZpkVf4vAQtPuQdOr3QYoHZpqDXh4asLiYVTvigoB3aOyu6z16V3hWU2tG4FIjVs X-Received: by 2002:a17:906:391:: with SMTP id b17mr5480790eja.282.1595523454131; Thu, 23 Jul 2020 09:57:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595523454; cv=none; d=google.com; s=arc-20160816; b=OURpwju0h8EGf4VX1ueZmS/l4hgcwVE8hJdqmZT7BbFGGKOom3raw0AUEtmFL+s6uV RJ0eKDqJAhBSsxrzdiDDekk7/wTuWrVSoagMcidsM3u1BG7pZGMUlrsOmg6Gq2wXkTRs 8mxmy+97Psc/VQ/X1CRSkSUsyvPx3w2Gp3zJXHwSsFIOaV05ErNv+Hj2SEBhULe6njaN vOI7F+mgGf8rNvwI/fFgisl59W1kKOUXeyrMIbGF4xcGv8E0nXUNmJ8btEGGlKJIzsIP 4zKfwHCdNL6FNZV2Y+Xv1UMxblc5kgy9ORhT73927UnEYAhf2OrPbmkmNkcq+LIj7tUc ZmZg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:ironport-sdr:ironport-sdr; bh=mnVjaG9CF6X/LfSwXTNHEveJMxFR3LT4aLR5BWwgqYk=; b=pnyRW1hYXoabK3MDQyATG/p8vBaP7FVtZCzlJRyxDZQ7cXakE/C3nqgPYFh0MR7GE4 6om05bbyXzcCR+mWPBbO9N92OLVFnH319UexAvjwOqc0cTlSfk5bzzENtWqIqk0JkQdi HEUpWnNl2RGfIqAoJnKKdcXsHB6oJLfMcY5/u7yd8PVYHjnntb6W3J40g2vcNVn7Z5/t AFC2mTvnLXzHoACPcLWOAnpGlsHrX/ejXtFFoi2R/v68H0BhJ6dfAr969JRgPqQsZoXO D5uOn3+BGfkuiYVqngRZf8jkUudcqcynTt/VBy+dw8SWozmF8GrYx0maqhg4JAp+LfcD BzZA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f10si2263336edr.215.2020.07.23.09.57.11; Thu, 23 Jul 2020 09:57:34 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729974AbgGWQ4u (ORCPT + 99 others); Thu, 23 Jul 2020 12:56:50 -0400 Received: from mga11.intel.com ([192.55.52.93]:29441 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726621AbgGWQ4u (ORCPT ); Thu, 23 Jul 2020 12:56:50 -0400 IronPort-SDR: 6ngY6kwxquf10seVEM1Dr3129Yr6MR7tDTC2zNDQXLnuts63EI0XSD8mLkOjyKA2wOdwZPZqaY SsK3IYcZZdsg== X-IronPort-AV: E=McAfee;i="6000,8403,9691"; a="148505366" X-IronPort-AV: E=Sophos;i="5.75,387,1589266800"; d="scan'208";a="148505366" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Jul 2020 09:56:49 -0700 IronPort-SDR: bJkHNGZQ1Hw3s5PdfbxZHNQOHZvHasSr4ggVzJ7OtBVpzlwhX06x7G1RkGsRivKVd1QUPc7qbj t8mvhax6Z8pQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,387,1589266800"; d="scan'208";a="288710474" Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.152]) by orsmga006.jf.intel.com with ESMTP; 23 Jul 2020 09:56:49 -0700 Date: Thu, 23 Jul 2020 09:56:49 -0700 From: Sean Christopherson To: Dave Hansen Cc: Yu-cheng Yu , x86@kernel.org, "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-api@vger.kernel.org, Arnd Bergmann , Andy Lutomirski , Balbir Singh , Borislav Petkov , Cyrill Gorcunov , Dave Hansen , Eugene Syromiatnikov , Florian Weimer , "H.J. Lu" , Jann Horn , Jonathan Corbet , Kees Cook , Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , Peter Zijlstra , Randy Dunlap , "Ravi V. Shankar" , Vedvyas Shanbhogue , Dave Martin , Weijiang Yang Subject: Re: [PATCH v10 00/26] Control-flow Enforcement: Shadow Stack Message-ID: <20200723165649.GG21891@linux.intel.com> References: <20200429220732.31602-1-yu-cheng.yu@intel.com> <20200723162531.GF21891@linux.intel.com> <2e9806a3-7485-a0d0-b63d-f112fcff954c@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2e9806a3-7485-a0d0-b63d-f112fcff954c@intel.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 23, 2020 at 09:41:37AM -0700, Dave Hansen wrote: > On 7/23/20 9:25 AM, Sean Christopherson wrote: > > How would people feel about taking the above two patches (02 and 03 in the > > series) through the KVM tree to enable KVM virtualization of CET before the > > kernel itself gains CET support? I.e. add the MSR and feature bits, along > > with the XSAVES context switching. The feature definitons could use "" to > > suppress displaying them in /proc/cpuinfo to avoid falsely advertising CET > > to userspace. > > > > AIUI, there are ABI issues that need to be sorted out, and that is likely > > going to drag on for some time. > > > > Is this a "hell no" sort of idea, or something that would be feasible if we > > can show that there are no negative impacts to the kernel? > > Negative impacts like bloating every task->fpu with XSAVE state that > will never get used? ;) Gah, should have qualified that with "meaningful or measurable negative impacts". E.g. the extra 40 bytes for CET XSAVE state seems like it would be acceptable overhead, but noticeably increasing the latency of XSAVES and/or XRSTORS would not be acceptable. > I thought KVM had its own vcpu->arch.guest_fpu buffers which mirrored > the size and format of task->fpu. Can we have KVM support today without > task->fpu support? I see some XSS munging in the KVM code so I think > this might be *possible*, but I don't see all of the plumbing that would > make it actually work. It'd be possible, but long term I don't think it's a good idea for KVM to diverge from the kernel's FPU support, i.e. fully converting KVM to it's own implementation will likely lead to pain and maintenance problems. Without fully converting KVM to a custom implementation, adding one off support for CET would be a massive hack job.