linux-kernel - Re: [PATCH v2 16/16] ARM64: XEN: Initialize Xen specific UEFI runtime services

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: <alpine.DEB.2.02.1601191415560.9400@kaball.uk.xensource.com>
Date:	Tue, 19 Jan 2016 14:20:33 +0000
From:	Stefano Stabellini <stefano.stabellini@...citrix.com>
To:	Shannon Zhao <shannon.zhao@...aro.org>
CC:	Mark Rutland <mark.rutland@....com>,
	Stefano Stabellini <stefano.stabellini@...citrix.com>,
	Shannon Zhao <zhaoshenglong@...wei.com>,
	<ard.biesheuvel@...aro.org>,
	<linux-arm-kernel@...ts.infradead.org>,
	<stefano.stabellini@...rix.com>, <david.vrabel@...rix.com>,
	<catalin.marinas@....com>, <will.deacon@....com>,
	<julien.grall@...rix.com>, <xen-devel@...ts.xen.org>,
	<devicetree@...r.kernel.org>, <linux-efi@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <peter.huangpeng@...wei.com>,
	Jan Beulich <JBeulich@...ell.com>,
	Ian Campbell <Ian.Campbell@...rix.com>
Subject: Re: [PATCH v2 16/16] ARM64: XEN: Initialize Xen specific UEFI runtime
 services

On Tue, 19 Jan 2016, Shannon Zhao wrote:
> On 2016/1/19 21:03, Mark Rutland wrote:
> > On Tue, Jan 19, 2016 at 12:03:59PM +0000, Stefano Stabellini wrote:
> > > On Mon, 18 Jan 2016, Mark Rutland wrote:
> > > > On Mon, Jan 18, 2016 at 05:45:24PM +0000, Stefano Stabellini wrote:
> > > > > On Mon, 18 Jan 2016, Mark Rutland wrote:
> > > > > > On Fri, Jan 15, 2016 at 02:55:29PM +0800, Shannon Zhao wrote:
> > > > > > > +void __init xen_efi_runtime_setup(void)
> > > > > > > +{
> > > > > > > +	efi.get_time                 = xen_efi_get_time;
> > > > > > > +	efi.set_time                 = xen_efi_set_time;
> > > > > > > +	efi.get_wakeup_time          = xen_efi_get_wakeup_time;
> > > > > > > +	efi.set_wakeup_time          = xen_efi_set_wakeup_time;
> > > > > > > +	efi.get_variable             = xen_efi_get_variable;
> > > > > > > +	efi.get_next_variable        = xen_efi_get_next_variable;
> > > > > > > +	efi.set_variable             = xen_efi_set_variable;
> > > > > > > +	efi.query_variable_info      = xen_efi_query_variable_info;
> > > > > > > +	efi.update_capsule           = xen_efi_update_capsule;
> > > > > > > +	efi.query_capsule_caps       = xen_efi_query_capsule_caps;
> > > > > > > +	efi.get_next_high_mono_count =
> > > > > > > xen_efi_get_next_high_mono_count;
> > > > > > > +	efi.reset_system             = NULL;
> > > > > > > +}
> > > > > > 
> > > > > > How do capsules work in the absence of an EFI system reset?
> > > > > 
> > > > > Actually I don't think that capsules are available in Xen on ARM64
> > > > > yet,
> > > > > see "TODO - disabled until implemented on ARM" in
> > > > > xen/common/efi/runtime.c.
> > > > > 
> > > > > FYI system reset is available, but it is provided via a different
> > > > > mechanism (HYPERVISOR_sched_op(xen_restart...)
> > > > 
> > > > Will that trigger Xen to do the right thing to trigger capsule updates
> > > > when implemented in Xen? Or do we need a xen_efi_reset_system?
> > > 
> > > On ARM, to reboot the hardware, Xen calls the native PSCI system_reset
> > > method. On x86, Xen calls efi_reset_system on EFI systems, and has
> > > several fall backs if that doesn't work as expected (see
> > > xen/arch/x86/shutdown.c:machine_restart).
> > > 
> > > But on a second look it doesn't look like that the capsule hypercalls
> > > are implemented correctly even on x86 (there is an "XXX fall through for
> > > now" comment in the code). I guess they are not available on Xen at all
> > > unfortunately.
> > 
> > That is incredibly unfortunate. It effectively renders the firmware
> > non-updateable when using Xen.
> > 
> > > > Does that override PSCI?
> > > 
> > > It does not, HYPERVISOR_sched_op(xen_restart,) is in addition to it. It
> > > ends up calling the same function within Xen as PSCI system_reset.
> > 
> > I meant within Dom0.
> > 
> > Presumably Dom0 calls HYPERVISOR_sched_op(xen_restart,), and doesn't
> > ever call PSCI SYSTEM_RESET?
> > 
> I think executing reset in Dom0 will reset not only Dom0 but also the Xen
> hypervisor, right?

Dom0 and DomUs call an HYPERVISOR_sched_op for machine reboot and
shutdown (by setting pm_power_off and arm_pm_restart), but a virtual
PSCI interface is also available and can be used. In the case of DomUs
the virtul machine is rebooted or shut down, in the case of Dom0, the
physical machine is rebooted or shut down.

The native PSCI methods are never exposed to Dom0 (or any DomUs).