linux-kernel - RE: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel

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

Message-ID: <DM5PR03MB2490056E887D6B844283BB98A0850@DM5PR03MB2490.namprd03.prod.outlook.com>
Date:   Wed, 7 Dec 2016 16:10:46 +0000
From:   KY Srinivasan <kys@...rosoft.com>
To:     Olaf Hering <olaf@...fle.de>,
        "vkuznets@...hat.com" <vkuznets@...hat.com>
CC:     "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "devel@...uxdriverproject.org" <devel@...uxdriverproject.org>
Subject: RE: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel



> -----Original Message-----
> From: Olaf Hering [mailto:olaf@...fle.de]
> Sent: Wednesday, December 7, 2016 7:47 AM
> To: KY Srinivasan <kys@...rosoft.com>; vkuznets@...hat.com
> Cc: gregkh@...uxfoundation.org; linux-kernel@...r.kernel.org;
> devel@...uxdriverproject.org
> Subject: RE: move hyperv CHANNELMSG_UNLOAD from crashed kernel to
> kdump kernel
> 
> Am 7. Dezember 2016 16:04:29 MEZ, schrieb KY Srinivasan
> <kys@...rosoft.com>:
> 
> >Yes; I had played with this approach a while ago. The issue is that the
> >host knows about a
> >bunch of in memory state that will be different in the kexec kernel.
> >For instance if we did all
> >the cleanup as part of the boot sequence, we will need access to all
> >the interrupt/messaging
> >infrastructure that was set up in the previous kernel.
> 
> 
> Where is that stored?  Perhaps it should be put into one place,  so that the
> new kernel can find and use it.

All the state required to handle interrupts is needed as well as the state needed
to issue unload. Look at vmbus_isr() for the needed interrupt handling state. The entire
code path from the isr routine will have to be executed. Is there a mechanism for stashing away state
that can be retrieved in the context of the execed kernel.

K. Y
> 
> Olaf