linux-kernel - Re: [PATCH v3 01/11] xen/manage: keep track of the on-going suspend mode

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 3 Jun 2021 16:11:46 -0400
From:   Boris Ostrovsky <boris.ostrovsky@...cle.com>
To:     Anchal Agarwal <anchalag@...zon.com>
Cc:     "tglx@...utronix.de" <tglx@...utronix.de>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "bp@...en8.de" <bp@...en8.de>, "hpa@...or.com" <hpa@...or.com>,
        "jgross@...e.com" <jgross@...e.com>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "sstabellini@...nel.org" <sstabellini@...nel.org>,
        "konrad.wilk@...cle.com" <konrad.wilk@...cle.com>,
        "roger.pau@...rix.com" <roger.pau@...rix.com>,
        "axboe@...nel.dk" <axboe@...nel.dk>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "rjw@...ysocki.net" <rjw@...ysocki.net>,
        "len.brown@...el.com" <len.brown@...el.com>,
        "pavel@....cz" <pavel@....cz>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "xen-devel@...ts.xenproject.org" <xen-devel@...ts.xenproject.org>,
        "vkuznets@...hat.com" <vkuznets@...hat.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "dwmw@...zon.co.uk" <dwmw@...zon.co.uk>
Subject: Re: [PATCH v3 01/11] xen/manage: keep track of the on-going suspend
 mode


On 6/2/21 3:37 PM, Anchal Agarwal wrote:
> On Tue, Jun 01, 2021 at 10:18:36AM -0400, Boris Ostrovsky wrote:
>>
> The resume won't fail because in the image the xen_vcpu and xen_vcpu_info are
> same. These are the same values that got in there during saving of the
> hibernation image. So whatever xen_vcpu got as a value during boot time registration on resume is
> essentially lost once the jump into the saved kernel image happens. Interesting
> part is if KASLR is not enabled boot time vcpup mfn is same as in the image.


Do you start the your guest right after you've hibernated it? What happens if you create (and keep running) a few other guests in-between? mfn would likely be different then I'd think.


> Once you enable KASLR this value changes sometimes and whenever that happens
> resume gets stuck. Does that make sense?
>
> No it does not resume successfully if hypercall fails because I was trying to
> explicitly reset vcpu and invoke hypercall.
> I am just wondering why does restore logic fails to work here or probably I am
> missing a critical piece here.


If you are not using KASLR then xen_vcpu_info is at the same address every time you boot. So whatever you registered before hibernating stays the same when you boot second time and register again, and so successful comparison in xen_vcpu_setup() works. (Mostly by chance.)


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.


>>> Another line of thought is something what kexec does to come around this problem
>>> is to abuse soft_reset and issue it during syscore_resume or may be before the image get loaded.
>>> I haven't experimented with that yet as I am assuming there has to be a way to re-register vcpus during resume.
>>
>> Right, that sounds like it should work.
>>
> You mean soft reset or re-register vcpu?


Doing something along the lines of a soft reset. It should allow you to re-register. Not sure how you can use it without Xen changes though. 



-boris