linux-kernel - Re: [PATCHv7.1 02/30] x86/tdx: Provide common base for SEAMCALL and TDCALL C wrappers

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:   Mon, 4 Apr 2022 06:51:25 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Kai Huang <kai.huang@...el.com>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        bp@...en8.de
Cc:     aarcange@...hat.com, ak@...ux.intel.com, brijesh.singh@....com,
        dan.j.williams@...el.com, dave.hansen@...ux.intel.com,
        david@...hat.com, hpa@...or.com, jgross@...e.com,
        jmattson@...gle.com, joro@...tes.org, jpoimboe@...hat.com,
        knsathya@...nel.org, linux-kernel@...r.kernel.org, luto@...nel.org,
        mingo@...hat.com, pbonzini@...hat.com, peterz@...radead.org,
        sathyanarayanan.kuppuswamy@...ux.intel.com, sdeep@...are.com,
        seanjc@...gle.com, tglx@...utronix.de, thomas.lendacky@....com,
        tony.luck@...el.com, vkuznets@...hat.com, wanpengli@...cent.com,
        x86@...nel.org
Subject: Re: [PATCHv7.1 02/30] x86/tdx: Provide common base for SEAMCALL and
 TDCALL C wrappers

On 4/3/22 20:19, Kai Huang wrote:
> Btw, I previous suggested perhaps we can just use -1ULL instead of above value
> for TDX_SEAMCALL_VMFAILINVALID, but didn't get response.  The reason is this
> value will only be used when detecting P-SEAMLDR using P-SEAMLDR's SEAMLDR.INFO
> SEAMCALL.  Note your above SW-defined error codes is based on error code
> definition for TDX module, but actually P-SEAMLDR has different error code
> definition:

I suggested moving away from the -1 because it didn't really carry any
additional information.  For folks that have the spec open day in and
day out, it's easy for you to go look up what the components of that -1
_mean_.

It sounds like there's a bug here (mixing up the P-SEAMLDR and TDX
module error ABIs), but that doesn't mean that moving to -1 is the right
answer.

Please just build up an error value the same way it was done for the
software-defined TDX module error codes.