Message ID | 20230808162320.27297-1-kirill.shutemov@linux.intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:c44e:0:b0:3f2:4152:657d with SMTP id w14csp2416054vqr; Tue, 8 Aug 2023 14:54:54 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEc67/BHTzjzj40GLDVGJ74xzJgJP6OsBwQGLUO0qrVPu9Jla9L+LLICVJK0CZGp6nJFbMM X-Received: by 2002:a17:90b:1496:b0:267:f7eb:f12e with SMTP id js22-20020a17090b149600b00267f7ebf12emr660105pjb.39.1691531694462; Tue, 08 Aug 2023 14:54:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1691531694; cv=none; d=google.com; s=arc-20160816; b=WrfkJW23rwr0qEnvXO4vqiJm1r9JBlrHehrWvS8BZzH7TDADdRg+Knytimqv4g4r6e NFgww5N7yyZxZwwm2u78c/bgLpefqhwQqJqyZg1f6WCkXGPhoTeBgL8oDeVCzHYJpCc8 +S3Hr7iHmma9L6Q9NH+xoOVTn5o5XjCrdCwx6CcnEuh0Q1L3yInyt2oNq2ZCCR9vbf6E BDXOWHQfdYsvfsFxxndpNe+9ClNqfi8rI1Fv80uS81cjC/slZmK0cmExk++96RonQigJ oKRh7MuJoWgw/ZLBZJhZlYZ7v8laeGautClEpTH/VaAJ6F2dL95PNyD+xCAAabvvzkZG chDA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=HDefNduP2Bxt+0Oyffg0TpGEw7qs7Rn2M3en9UqCq98=; fh=ggeDODYgUvQhEjj14Y2MlPueduWP67hrMMdOpBS8ZBM=; b=xxRagOrbLNJcjFXHYg4bgYyX5JpQb68uh7cSjDBgB16clpepCU+JbVJdvfkZTEl44D WtiRL3DLRvYRcHhRh2XHFlcekvyPh9vi7UDPdqtMgnHug3u9rsBbHIrNFV79F/KHa4Cl kEGa0X4dLtZvVN5jc4KiNJAc59rl22DzP+qu8vTu1AcMERtnH31zZy0BYkElUh/i7CND 6P7QQecUmptKvCWhjl0rAbx3MiqU3nOZ6T8ZUtWsf4LeiO1q3vHQ9e3XgLOPQIg8FMjr wgzq+X0hckDQIvhn0hrD9Dm4lI0zlGSlxh7z4FvvrFZey6UZl+uvZm7xuR2L0ocbE5bw I4Dw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=Wwd84tJM; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id lp18-20020a17090b4a9200b00263e4949dbbsi43476pjb.29.2023.08.08.14.54.41; Tue, 08 Aug 2023 14:54:54 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=Wwd84tJM; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231354AbjHHTTL (ORCPT <rfc822;aaronkmseo@gmail.com> + 99 others); Tue, 8 Aug 2023 15:19:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37084 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233988AbjHHTSi (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 8 Aug 2023 15:18:38 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DB0C73CD32 for <linux-kernel@vger.kernel.org>; Tue, 8 Aug 2023 09:41:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1691512912; x=1723048912; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=0z1l/njVD+UEzwVIY4bLXSqHss3Uzx8s2RCDApioNEA=; b=Wwd84tJMgkhhVANO2Sd9wBfweXP3Lu2kFmcGRUc4IJLat7EJyexeu+Cf lQs1LC0wwpnRzS25DrNA8r5cRoY9LkIYQfEGbxpHL+TJczxviNhRoboS+ Y6HxFwE226HLAzLVtGFpeT3h+vH8R/eIDXKqXO6ZIMReGs4mLfUq6Rt5k iOmyjzPL+Nxrt6kKSM8r6dqElywEOUWWu9SQXmx6L4m46gLTylpd1z7PL gcAdU8/CLiibkr9ikvfBEcN0+y2/B4h8VUu69LfxAQUmJyxy366mQiVP8 QhiJ9MF1kPlItWpMONcB5gRYnnu7bdiqGrT4IVCFijsem9WYf+FNCBXYV Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10795"; a="374551726" X-IronPort-AV: E=Sophos;i="6.01,156,1684825200"; d="scan'208";a="374551726" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Aug 2023 09:23:30 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10795"; a="977932468" X-IronPort-AV: E=Sophos;i="6.01,156,1684825200"; d="scan'208";a="977932468" Received: from vevladis-mobl.ccr.corp.intel.com (HELO box.shutemov.name) ([10.252.49.245]) by fmsmga006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Aug 2023 09:23:27 -0700 Received: by box.shutemov.name (Postfix, from userid 1000) id E348C10A12B; Tue, 8 Aug 2023 19:23:24 +0300 (+03) From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> To: Thomas Gleixner <tglx@linutronix.de>, Dave Hansen <dave.hansen@intel.com>, Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org> Cc: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>, Elena Reshetova <elena.reshetova@intel.com>, Jun Nakajima <jun.nakajima@intel.com>, x86@kernel.org, linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org, "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> Subject: [PATCH] x86/tdx: Mark TSC reliable Date: Tue, 8 Aug 2023 19:23:20 +0300 Message-ID: <20230808162320.27297-1-kirill.shutemov@linux.intel.com> X-Mailer: git-send-email 2.41.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_BLOCKED, SPF_HELO_NONE,SPF_NONE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1773688972638215036 X-GMAIL-MSGID: 1773699537998152218 |
Series |
x86/tdx: Mark TSC reliable
|
|
Commit Message
Kirill A. Shutemov
Aug. 8, 2023, 4:23 p.m. UTC
In x86 virtualization environments, including TDX, RDTSC instruction is
handled without causing a VM exit, resulting in minimal overhead and
jitters. On the other hand, other clock sources (such as HPET, ACPI
timer, APIC, etc.) necessitate VM exits to implement, resulting in more
fluctuating measurements compared to TSC. Thus, those clock sources are
not effective for calibrating TSC.
In TD guests, TSC is virtualized by the TDX module, which ensures:
- Virtual TSC values are consistent among all the TD’s VCPUs;
- Monotonously incrementing for any single VCPU;
- The frequency is determined by TD configuration. The host TSC is
invariant on platforms where TDX is available.
Use TSC as the only reliable clock source in TD guests, bypassing
unstable calibration.
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
---
arch/x86/coco/tdx/tdx.c | 3 +++
1 file changed, 3 insertions(+)
Comments
On Tue, Aug 08, 2023 at 10:13:05AM -0700, Dave Hansen wrote: > On 8/8/23 09:23, Kirill A. Shutemov wrote: > ... > > On the other hand, other clock sources (such as HPET, ACPI timer, > > APIC, etc.) necessitate VM exits to implement, resulting in more > > fluctuating measurements compared to TSC. Thus, those clock sources > > are not effective for calibrating TSC. > > Do we need to do anything to _those_ to mark them as slightly stinky? I don't know what the rules here. As far as I can see, all other clock sources relevant for TDX guest have lower rating. I guess we are fine? There's notable exception to the rating order is kvmclock which is higher than tsc. It has to be disabled, but it is not clear to me how. This topic is related to how we are going to filter allowed devices/drivers, so I would postpone the decision until we settle on wider filtering schema. > > In TD guests, TSC is virtualized by the TDX module, which ensures: > > > > - Virtual TSC values are consistent among all the TD’s VCPUs; > > - Monotonously incrementing for any single VCPU; > > - The frequency is determined by TD configuration. The host TSC is > > invariant on platforms where TDX is available. > > I take it this is carved in stone in the TDX specs somewhere. A > reference would be nice. TDX Module 1.0 spec: 5.3.5. Time Stamp Counter (TSC) TDX provides a trusted virtual TSC to the guest TDs. TSC value is monotonously incrementing, starting from 0 on TD initialization by the host VMM. The deviation between virtual TSC values read by each VCPU is small. A guest TD should disable mechanisms that are used in non-trusted environment, which attempt to synchronize TSC between VCPUs, and should not revert to using untrusted time mechanisms. ... 13.13.1. TSC Virtualization For virtual time stamp counter (TSC) values read by guest TDs, the Intel TDX module is designed to achieve the following: • Virtual TSC values are consistent among all the TD’s VCPUs at the level supported by the CPU, see below. • The virtual TSC value for any single VCPU is monotonously incrementing (except roll over from 264-1 to 0). • The virtual TSC frequency is determined by TD configuration. ... > We've got VMWare and Hyper-V code basically doing the same thing today. > So TDX is in kinda good company. But this still makes me rather > nervous. Do you have any encouraging words about how unlikely future > hardware is to screw this up, especially as TDX-supporting hardware gets > more diverse? Wording in the spec looks okay to me. We can only hope that implementation going to be sane.
> On Tue, Aug 08, 2023 at 10:13:05AM -0700, Dave Hansen wrote: > > On 8/8/23 09:23, Kirill A. Shutemov wrote: > > ... > > > On the other hand, other clock sources (such as HPET, ACPI timer, > > > APIC, etc.) necessitate VM exits to implement, resulting in more > > > fluctuating measurements compared to TSC. Thus, those clock sources > > > are not effective for calibrating TSC. > > > > Do we need to do anything to _those_ to mark them as slightly stinky? IMO from pure security pov yes. It would be good secure default that TDX guests (and other CoCo guests also) are using only trusted source time. There are issues with this though and would need to understand where to draw the line. Things like hpet and such we hoped to disable via device filtering. For some other time sources we have used patches below. But then there are things like RTC that would be great to disable also, but without a proper remote time server that breaks any date/timing for the guest, so we have not done it and probably should not by default, but we recommend not using it in docs we have: https://intel.github.io/ccc-linux-guest-hardening-docs/security-spec.html#tsc-and-other-timers > > I don't know what the rules here. As far as I can see, all other clock > sources relevant for TDX guest have lower rating. I guess we are fine? What about acpi_pm? See this: https://github.com/intel/tdx/commit/045692772ab4ef75062a83cc6e4ffa22cab40226 > > There's notable exception to the rating order is kvmclock which is higher > than tsc. It has to be disabled, but it is not clear to me how. This topic > is related to how we are going to filter allowed devices/drivers, so I > would postpone the decision until we settle on wider filtering schema. One option is to include "no-kvmclock" into kernel command line, which is attested. Another option is to try to disable it explicitly, like we had in past: https://github.com/intel/tdx/commit/6b0357f2115c1bdd158c0c8836f4f541517bf375 The obvious issues with command line is that it is going to 1) grow considerably if we try to disable everything we can via command line and 2) there is a high chance that in practice people will not use secure default and/or forget to verify the correct status of cmd line. But this is to be expected I guess for any security method that involves attestation unfortunately. Best Regards, Elena.
On Wed, Aug 09, 2023 at 05:44:37AM +0000, Reshetova, Elena wrote: > > > > I don't know what the rules here. As far as I can see, all other clock > > sources relevant for TDX guest have lower rating. I guess we are fine? > > What about acpi_pm? > See this: > https://github.com/intel/tdx/commit/045692772ab4ef75062a83cc6e4ffa22cab40226 clocksource_acpi_pm.rating is 200 while TSC is 300. > > There's notable exception to the rating order is kvmclock which is higher > > than tsc. It has to be disabled, but it is not clear to me how. This topic > > is related to how we are going to filter allowed devices/drivers, so I > > would postpone the decision until we settle on wider filtering schema. > > One option is to include "no-kvmclock" into kernel command line, which > is attested. Another option is to try to disable it explicitly, like we had > in past: > https://github.com/intel/tdx/commit/6b0357f2115c1bdd158c0c8836f4f541517bf375 > > The obvious issues with command line is that it is going to 1) grow > considerably if we try to disable everything we can via command line > and 2) there is a high chance that in practice people will not use secure default > and/or forget to verify the correct status of cmd line. But this is to be > expected I guess for any security method that involves attestation unfortunately. I guess command line is fine, until we have coherent solution on filtering.
diff --git a/arch/x86/coco/tdx/tdx.c b/arch/x86/coco/tdx/tdx.c index 1d6b863c42b0..1583ec64d92e 100644 --- a/arch/x86/coco/tdx/tdx.c +++ b/arch/x86/coco/tdx/tdx.c @@ -769,6 +769,9 @@ void __init tdx_early_init(void) setup_force_cpu_cap(X86_FEATURE_TDX_GUEST); + /* TSC is the only reliable clock in TDX guest */ + setup_force_cpu_cap(X86_FEATURE_TSC_RELIABLE); + cc_vendor = CC_VENDOR_INTEL; tdx_parse_tdinfo(&cc_mask); cc_set_mask(cc_mask);