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
| ||
|
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.
Powered by blists - more mailing lists