On 6/3/21 7:27 PM, Anchal Agarwal wrote: > On Thu, Jun 03, 2021 at 04:11:46PM -0400, Boris Ostrovsky wrote: > >> But if KASLR is on then this comparison not failing should cause xen_vcpu >> pointer in the loaded image to become bogus because xen_vcpu is now >> registered for a different xen_vcpu_info address during boot. >> > The reason for that I think is once you jump into the image that information > is > getting lost. But there is some residue somewhere that's causing the resume > to > fail. I haven't been able to pinpoint the exact field value that may be > causing > that issue.
xen_vcpu now points to address which is not where the hypervisor thinks vcpu_info should be. > Correct me if I am wrong here, but even if hypothetically I put a hack to > tell the kernel > somehow re-register vcpu it won't pass because there is no hypercall to > unregister it in first place? Right. You will be shown the door in map_vcpu_info(): if ( !mfn_eq(v->vcpu_info_mfn, INVALID_MFN) ) return -EINVAL; > Can the resumed kernel use the new values in that > case [Now this is me just throwing wild guesses!!] I don't think so --- hypervisor is now pointing to a random location in your image. -boris
