linux-kernel - Re: [PATCH v2] virt: tdx-guest: Add Quote generation support using TSM

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: <d7ce06dc-32c1-b957-9f32-1ba71b80fd75@intel.com>
Date:   Wed, 20 Sep 2023 11:11:36 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Kuppuswamy Sathyanarayanan 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        "Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Dan Williams <dan.j.williams@...el.com>,
        "H . Peter Anvin" <hpa@...or.com>, Tony Luck <tony.luck@...el.com>,
        Wander Lairson Costa <wander@...hat.com>,
        Erdem Aktas <erdemaktas@...gle.com>,
        Dionna Amalie Glaze <dionnaglaze@...gle.com>,
        Qinkun Bao <qinkun@...che.org>,
        Guorui Yu <GuoRui.Yu@...ux.alibaba.com>,
        linux-coco@...ts.linux.dev, x86@...nel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] virt: tdx-guest: Add Quote generation support using
 TSM_REPORTS

On 9/20/23 11:08, Kuppuswamy Sathyanarayanan wrote:
> My thinking is to allocate it when we really need it. We only need this memory if the
> GetQuote hypercall is successful. We can also allocate it at the top and there is
> nothing wrong with it, but it will not be used in failure cases. Since top declarations
> are not a requirement, why allocate it early? 

Do folks *REALLY* want this patch set to be a trailblazer where we can
all nitpick the nuances of how we want to deal with this snazzy new
__free() mechanism?

Or, do you want it to be old and boring and do it the way we've done it
forever?

Your choice.