linux-kernel - Re: [PATCH v3 01/11] kexec: introduce kexec firmware support

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

Date:	Thu, 27 Dec 2012 16:18:56 -0800 (PST)
From:	Daniel Kiper <daniel.kiper@...cle.com>
To:	<ebiederm@...ssion.com>
Cc:	<kexec@...ts.infradead.org>, <xen-devel@...ts.xensource.com>,
	<konrad.wilk@...cle.com>, <tglx@...utronix.de>,
	<maxim.uvarov@...cle.com>, <andrew.cooper3@...rix.com>,
	<hpa@...or.com>, <jbeulich@...e.com>, <mingo@...hat.com>,
	<x86@...nel.org>, <virtualization@...ts.linux-foundation.org>,
	<vgoyal@...hat.com>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 01/11] kexec: introduce kexec firmware support

> Daniel Kiper <daniel.kiper@...cle.com> writes:
>
> > Some kexec/kdump implementations (e.g. Xen PVOPS) could not use default
> > Linux infrastructure and require some support from firmware and/or hypervisor.
> > To cope with that problem kexec firmware infrastructure was introduced.
> > It allows a developer to use all kexec/kdump features of given firmware
> > or hypervisor.
>
> As this stands this patch is wrong.
>
> You need to pass an additional flag from userspace through /sbin/kexec
> that says load the kexec image in the firmware.  A global variable here
> is not ok.
>
> As I understand it you are loading a kexec on xen panic image.  Which
> is semantically different from a kexec on linux panic image.  It is not
> ok to do have a silly global variable kexec_use_firmware.

Earlier we agreed that /sbin/kexec should call kexec syscall with
special flag. However, during work on Xen kexec/kdump v3 patch
I stated that this is insufficient because e.g. crash_kexec()
should execute different code in case of use of firmware support too.
Sadly syscall does not save this flag anywhere. Additionally, I stated
that kernel itself has the best knowledge which code path should be
used (firmware or plain Linux). If this decision will be left to userspace
then simple kexec syscall could crash system at worst case (e.g. when
plain Linux kexec will be used in case when firmware kaxec should be used).
However, if you wish I could add this flag to syscall. Additionally, I could
add function which enables firmware support and then kexec_use_firmware
variable will be global only in kexec.c module.

> Furthermore it is not ok to have a conditional
> code outside of header files.

I agree but how to dispatch execution e.g. in crash_kexec()
if we would like (I suppose) compile kexec firmware
support conditionally?

Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/