linux-kernel - Re: [RFC PATCH v2 66/69] KVM: TDX: Add "basic" support for building and running Trust Domains

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] [day] [month] [year] [list]

Message-ID: <c54ba892-de31-1ebf-25ee-a40a44a15ac1@intel.com>
Date:   Sun, 24 Oct 2021 20:59:30 +0800
From:   Xiaoyao Li <xiaoyao.li@...el.com>
To:     Sagi Shahar <sagis@...gle.com>,
        Isaku Yamahata <isaku.yamahata@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H . Peter Anvin" <hpa@...or.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        Joerg Roedel <joro@...tes.org>,
        Erdem Aktas <erdemaktas@...gle.com>,
        Connor Kuehl <ckuehl@...hat.com>,
        Sean Christopherson <seanjc@...gle.com>, x86@...nel.org,
        linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Cc:     isaku.yamahata@...il.com, Kai Huang <kai.huang@...ux.intel.com>,
        Chao Gao <chao.gao@...el.com>,
        Isaku Yamahata <isaku.yamahata@...ux.intel.com>,
        Yuan Yao <yuan.yao@...el.com>
Subject: Re: [RFC PATCH v2 66/69] KVM: TDX: Add "basic" support for building
 and running Trust Domains

On 10/22/2021 5:44 AM, Sagi Shahar wrote:
>   On Fri, Jul 2, 2021 at 3:06 PM, Isaku Yamahata
> <isaku.yamahata@...el.com> wrote:
>> Subject: [RFC PATCH v2 66/69] KVM: TDX: Add "basic" support for
>> building and running Trust Domains
>>
>>
>> +static int tdx_map_gpa(struct kvm_vcpu *vcpu)
>> +{
>> +       gpa_t gpa = tdvmcall_p1_read(vcpu);
>> +       gpa_t size = tdvmcall_p2_read(vcpu);
>> +
>> +       if (!IS_ALIGNED(gpa, 4096) || !IS_ALIGNED(size, 4096) ||
>> +           (gpa + size) < gpa ||
>> +           (gpa + size) > vcpu->kvm->arch.gfn_shared_mask << (PAGE_SHIFT + 1))
>> +               tdvmcall_set_return_code(vcpu, TDG_VP_VMCALL_INVALID_OPERAND);
>> +       else
>> +               tdvmcall_set_return_code(vcpu, TDG_VP_VMCALL_SUCCESS);
>> +
>> +       return 1;
>> +}
> 
> This function looks like a no op in case of success. Is this
> intentional? Is this mapping handled somewhere else later on?
> 

Yes, it's intentional.

The mapping will be exactly set up in EPT violation handler when the GPA 
is really accessed.