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]
Message-ID: <CAPcyv4haWYhqk_xLD56QnB0ahK+fynOmqGdSD907UW-=7B176g@mail.gmail.com>
Date:   Wed, 9 Jun 2021 08:09:52 -0700
From:   Dan Williams <dan.j.williams@...el.com>
To:     Andi Kleen <ak@...ux.intel.com>
Cc:     "Kuppuswamy, Sathyanarayanan" 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Andy Lutomirski <luto@...nel.org>,
        Dave Hansen <dave.hansen@...el.com>,
        Tony Luck <tony.luck@...el.com>,
        Kirill Shutemov <kirill.shutemov@...ux.intel.com>,
        Kuppuswamy Sathyanarayanan <knsathya@...nel.org>,
        Raj Ashok <ashok.raj@...el.com>,
        Sean Christopherson <seanjc@...gle.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC v2-fix-v4 1/1] x86/tdx: Skip WBINVD instruction for TDX guest

On Tue, Jun 8, 2021 at 9:27 PM Andi Kleen <ak@...ux.intel.com> wrote:
>
>
> here is no resume path.
>
> > Host is free to go into S3 independent of any guest state.
>
> Actually my understanding is that none of the systems which support TDX
> support S3. S3 has been deprecated for a long time.

Ok, I wanted to imply any power state that might power-off caches.

>
>
> >   A hostile
> > host is free to do just enough cache management so that it can resume
> > from S3 while arranging for TDX guest dirty data to be lost. Does a
> > TDX guest go fatal if the cache loses power?
>
> That would be a machine check, and yes it would be fatal.

Sounds good, so incorporating this and Andy's feedback:

"TDX guests, like other typical guests, use standard ACPI mechanisms
to signal sleep state entry (including reboot) to the host. The ACPI
specification mandates WBINVD on any sleep state entry with the
expectation that the platform is only responsible for maintaining the
state of memory over sleep states, not preserving dirty data in any
CPU caches. ACPI cache flushing requirements pre-date the advent of
virtualization. Given guest sleep state entry does not affect any host
power rails it is not required to flush caches. The host is
responsible for maintaining cache state over its own bare metal sleep
state transitions that power-off the cache. A TDX guest, unlike a
typical guest, will machine check if the CPU cache is powered off."

Andi, is that machine check behavior relative to power states
mentioned in the docs?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ