linux-kernel - Re: [PATCH] x86/tdx: Mark TSC reliable

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 31 Aug 2023 15:16:04 +0000
From:   "Nakajima, Jun" <jun.nakajima@...el.com>
To:     Thomas Gleixner <tglx@...utronix.de>
CC:     "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        "Hansen, Dave" <dave.hansen@...el.com>,
        Borislav Petkov <bp@...en8.de>,
        "Lutomirski, Andy" <luto@...nel.org>,
        Kuppuswamy Sathyanarayanan 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        "Reshetova, Elena" <elena.reshetova@...el.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "linux-coco@...ts.linux.dev" <linux-coco@...ts.linux.dev>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86/tdx: Mark TSC reliable


> On Aug 30, 2023, at 12:33 AM, Thomas Gleixner <tglx@...utronix.de> wrote:
> 
> On Tue, Aug 29 2023 at 16:01, Jun Nakajima wrote:
>>> On Aug 25, 2023, at 10:09 AM, Thomas Gleixner <tglx@...utronix.de> wrote:
>>>> The newer spec says "Virtual TSC values are consistent among all the TD’s
>>>> VCPUs at the level supported by the CPU".
>>> 
>>> That means what? It's not a guarantee for consistency either. :(
>> 
>> Actually (in TDX Module 1.5 spec), the sentence is "Virtual TSC values
>> are consistent among all the TD’s VCPUs at the level supported by the
>> CPU, see below”.
>> 
>> And the below:
>> ---
>> The host VMM is required to do the following:
>> • Set up the same IA32_TSC_ADJUST values on all LPs before initializing the Intel TDX module.
>> • Make sure IA32_TSC_ADJUST is not modified from its initial value before calling SEAMCALL.
>> 
>> The Intel TDX module checks the above as part of TDH.VP.ENTER and any
>> other SEAMCALL leaf function that reads TSC.
> 
> What happens when the check detects that the host modified TSC ADJUST?

Such a SEAMCALL, e.g., TDH.VP.ENTER will fail with an error code (TDX_INCONSISTENT_MSR and MSR index of TSC ADJUST).

> 
> What validates the VMCS TSC offset field?

TDX module. The VMCSs of TDs are in private (protected) memory and accessed by the TDX module only. 
The host has no direct access to them.

> 
>> The virtualized TSC is designed to have the following characteristics:
>> • The virtual TSC frequency is specified by the host VMM as an input
>> to TDH.MNG.INIT in units of 25MHz – it can be between 4 and 400
>> (corresponding to a range of 100MHz to 10GHz).
> 
> What validates that the frequency is correct?

Validation of the real/hardware TSC frequency is part of hardware validation.

> 
> How is ensured that the host does not change TSC scaling?

I guess you mean virtual TSC scaling, which is used for calculation of the TSC observed by the guest.
This is a VMCS field set by the TDX module, based on the configured virtual TSC frequency and the real TSC frequency. So, the host cannot change it (as it has no direct access to the VMCS).


---
Jun