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]

Date:   Wed, 7 Dec 2016 15:04:29 +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 12:51 AM
> To: KY Srinivasan <kys@...rosoft.com>; vkuznets@...hat.com
> Cc: gregkh@...uxfoundation.org; linux-kernel@...r.kernel.org;
> devel@...uxdriverproject.org
> Subject: move hyperv CHANNELMSG_UNLOAD from crashed kernel to
> kdump kernel
> 
> KY,
> 
> if a hyperv VM crashes alot of work must be done to prepare the
> environment for the kdump kernel. This approach is different compared to
> all the other VM types, or baremetal. Since the just crashed kernel is
> per definition unreliable all that work should be done within the kdump
> kernel because I think a reliable environment exists only there.
> 
> Was it ever considered to do the CHANNELMSG_UNLOAD /
> CHANNELMSG_UNLOAD_RESPONSE work during boot, instead of doing it
> before
> starting the kexec/kdump kernel?
> 
> What would it take to prepare the runtime environment during boot?
> Does the newly booted kernel need any info from the previous kernel,
> something that cant be determined during boot? If yes, how can such info
> be passed from the old kernel to the new kernel?

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.

K. Y
> 
> Olaf