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: <87r3594hef.fsf@vitty.brq.redhat.com>
Date:   Thu, 15 Dec 2016 11:26:48 +0100
From:   Vitaly Kuznetsov <vkuznets@...hat.com>
To:     Olaf Hering <olaf@...fle.de>
Cc:     kys@...rosoft.com, gregkh@...uxfoundation.org,
        linux-kernel@...r.kernel.org, devel@...uxdriverproject.org
Subject: Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel

Olaf Hering <olaf@...fle.de> writes:

> 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?

Sorry guys I missed the discussion, I was on vacation.

I see a number of minor but at least one major issue against such move:
At least for some Hyper-V versions (2012R2 for example)
CHANNELMSG_UNLOAD_RESPONSE is delivered to the CPU which initially sent 
CHANNELMSG_REQUESTOFFERS and on kdump we may not have this CPU up as
we usually do kdump with nr_cpus=1 (and on the CPU which crashed). 

Minor issue is the necessity preserve the information about
message/events pages across kexec.

>
> 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?
>
> Olaf
>

-- 
  Vitaly