linux-kernel - Re: [RFC v2-fix-v2 1/1] x86: Introduce generic protected guest abstractionn

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: <12bba26f-5605-fabf-53ea-f0bc1bb9db44@amd.com>
Date:   Fri, 4 Jun 2021 18:31:03 -0500
From:   Tom Lendacky <thomas.lendacky@....com>
To:     Borislav Petkov <bp@...en8.de>
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>,
        Andi Kleen <ak@...ux.intel.com>,
        Kirill Shutemov <kirill.shutemov@...ux.intel.com>,
        Kuppuswamy Sathyanarayanan <knsathya@...nel.org>,
        Dan Williams <dan.j.williams@...el.com>,
        Raj Ashok <ashok.raj@...el.com>,
        Sean Christopherson <seanjc@...gle.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC v2-fix-v2 1/1] x86: Introduce generic protected guest
 abstractionn

On 6/4/21 5:15 PM, Borislav Petkov wrote:
> On Fri, Jun 04, 2021 at 05:01:31PM -0500, Tom Lendacky wrote:
>> The first is analogous to sme_active(), the second to sev_active() and the
>> third to mem_encrypt_active(). Just my opinion, though...
> 
> Yeah, or cc_has() where "cc" means "confidential computing". Or "coco"...
> 
> Yeah, no good idea yet.
> 
>> I don't think you want a WARN_ON_ONCE() here. The code will be written to
>> work with either SEV or TDX, so we shouldn't warn on a check for a TDX
>> supported feature when running on AMD (or vice-versa).
> 
> That's an AMD-specific path so it would warn only when a flag is used
> which is unknown/unused yet on AMD.

But the check can happen on Intel or AMD. We have lots of checks for
sme_active() in common code that are executed on Intel today, but they
just return false. It's the same principle, you don't want to WARN on
those, just return false. E.g.:

	/* some common code path */
	if (cc_has(XYZ))
		do_y();

If Intel has XYZ but AMD does not, you don't want to WARN, just return false.

Thanks,
Tom

>