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, 27 May 2021 15:25:16 +0000
From:   "Luck, Tony" <tony.luck@...el.com>
To:     Kuppuswamy Sathyanarayanan 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Andy Lutomirski <luto@...nel.org>,
        "Hansen, Dave" <dave.hansen@...el.com>
CC:     Andi Kleen <ak@...ux.intel.com>,
        Kirill Shutemov <kirill.shutemov@...ux.intel.com>,
        Kuppuswamy Sathyanarayanan <knsathya@...nel.org>,
        "Williams, Dan J" <dan.j.williams@...el.com>,
        "Raj, Ashok" <ashok.raj@...el.com>,
        Sean Christopherson <seanjc@...gle.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [RFC v2-fix-v2 1/1] x86/tdx: Add __tdx_module_call() and
 __tdx_hypercall() helper functions

> Guests communicate with VMMs with hypercalls. Historically, these
> are implemented using instructions that are known to cause VMEXITs
> like vmcall, vmlaunch, etc. However, with TDX, VMEXITs no longer
> expose guest state to the host.  This prevents the old hypercall
> mechanisms from working. So to communicate with VMM, TDX
> specification defines a new instruction called "tdcall".

You use all caps TDCALL everywhere else in this commit message.
Looks odd to have quoted lower case here.

> In a TDX based VM, since VMM is an untrusted entity, a intermediary
> layer (TDX module) exists between host and guest to facilitate the
> secure communication. TDX guests communicate with the TDX module and
> with the VMM using a new instruction: TDCALL.

Seems both repeat what was in the first paragraph, but also fail to
explain how this TDCALL is different from that first TDCALL.

> Implement common helper functions to communicate with the TDX Module
> and VMM (using TDCALL instruction).
>   
> __tdx_hypercall()    - request services from the VMM.
> __tdx_module_call()  - communicate with the TDX Module.

Looking at the code, the hypercall can return an error if TDCALL fails,
but module_call forces a panic with UD2 on error. This difference isn't
explained anywhere.

-Tony

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ