All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Reshetova, Elena" <elena.reshetova@intel.com>
To: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	"Hansen, Dave" <dave.hansen@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Borislav Petkov <bp@alien8.de>,
	"Lutomirski, Andy" <luto@kernel.org>,
	Kuppuswamy Sathyanarayanan
	<sathyanarayanan.kuppuswamy@linux.intel.com>,
	"Nakajima, Jun" <jun.nakajima@intel.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH] x86/tdx: Mark TSC reliable
Date: Wed, 9 Aug 2023 05:44:37 +0000	[thread overview]
Message-ID: <DM8PR11MB5750DEFF988068EFAFE28667E712A@DM8PR11MB5750.namprd11.prod.outlook.com> (raw)
In-Reply-To: <20230808200111.nz74tmschph435ri@box>


> 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.

  reply	other threads:[~2023-08-09  5:44 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-08 16:23 [PATCH] x86/tdx: Mark TSC reliable Kirill A. Shutemov
2023-08-08 17:13 ` Dave Hansen
2023-08-08 20:01   ` Kirill A. Shutemov
2023-08-09  5:44     ` Reshetova, Elena [this message]
2023-08-09  6:13       ` Kirill A. Shutemov
2023-08-22 23:39         ` Erdem Aktas
2023-08-24 15:49     ` Thomas Gleixner
2023-08-25 13:52       ` Kirill A. Shutemov
2023-08-25 17:09         ` Thomas Gleixner
2023-08-29 16:01           ` Nakajima, Jun
2023-08-30  7:33             ` Thomas Gleixner
2023-08-31 15:16               ` Nakajima, Jun
2023-08-24 19:31     ` Thomas Gleixner
2023-08-25 13:47       ` Kirill A. Shutemov
2023-08-25 15:16         ` Sean Christopherson
2023-09-07 17:25           ` Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DM8PR11MB5750DEFF988068EFAFE28667E712A@DM8PR11MB5750.namprd11.prod.outlook.com \
    --to=elena.reshetova@intel.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@intel.com \
    --cc=jun.nakajima@intel.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=sathyanarayanan.kuppuswamy@linux.intel.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.