lkml.org 
[lkml]   [2021]   [Jun]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    SubjectRe: [RFC v2-fix-v2 1/1] x86: Introduce generic protected guest abstraction
    From
    Date
    On 6/2/21 12:20 PM, Sean Christopherson wrote:
    > On Tue, Jun 01, 2021, Kuppuswamy Sathyanarayanan wrote:
    >> diff --git a/arch/x86/include/asm/mem_encrypt.h b/arch/x86/include/asm/mem_encrypt.h
    >> index 9c80c68d75b5..1492b0eb29d0 100644
    >> --- a/arch/x86/include/asm/mem_encrypt.h
    >> +++ b/arch/x86/include/asm/mem_encrypt.h
    >> @@ -56,6 +56,8 @@ bool sev_es_active(void);
    >>
    >> #define __bss_decrypted __section(".bss..decrypted")
    >>
    >> +bool amd_protected_guest_has(unsigned long flag);
    >
    >
    > Why call one by the vendor (amd) and the other by the technology (tdx)?
    > sev_protected_guest_has() seems like the more logical name, e.g. if AMD CPUs
    > gain a new non-SEV technology then we'll have a mess.

    The original suggestion from Boris, IIRC, was for protected_guest_has()
    function (below) to be:

    if (intel)
    return intel_protected_guest_has();
    else if (amd)
    return amd_protected_guest_has();
    else
    return false;

    And then you could check for TDX or SME/SEV in the respective functions.

    >
    >> diff --git a/arch/x86/include/asm/tdx.h b/arch/x86/include/asm/tdx.h
    >> index f0c1912837c8..cbfe7479f2a3 100644
    >> --- a/arch/x86/include/asm/tdx.h
    >> +++ b/arch/x86/include/asm/tdx.h
    >> @@ -71,6 +71,8 @@ u64 __tdx_module_call(u64 fn, u64 rcx, u64 rdx, u64 r8, u64 r9,
    >> u64 __tdx_hypercall(u64 fn, u64 r12, u64 r13, u64 r14, u64 r15,
    >> struct tdx_hypercall_output *out);
    >>
    >> +bool tdx_protected_guest_has(unsigned long flag);
    >
    > ...
    >
    >> +static inline bool protected_guest_has(unsigned long flag)
    >> +{
    >> + if (is_tdx_guest())
    >> + return tdx_protected_guest_has(flag);
    >> + else if (mem_encrypt_active())
    >
    > Shouldn't this be sev_active()? mem_encrypt_active() will return true for SME,
    > too.

    I believe Boris was wanting to replace the areas where sme_active() was
    specifically checked, too. And so protected_guest_has() can be confusing...

    Maybe naming it protected_os_has() or protection_attr_active() might work.
    This would then work SME or MKTME as well.

    Thanks,
    Tom

    >
    >> + return amd_protected_guest_has(flag);
    >> +
    >> + return false;
    >> +}

    \
     
     \ /
      Last update: 2021-06-02 20:17    [W:4.724 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site