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
| ||
|
Date: Tue, 19 Jan 2016 21:31:58 +0800 From: Shannon Zhao <shannon.zhao@...aro.org> To: Mark Rutland <mark.rutland@....com>, Stefano Stabellini <stefano.stabellini@...citrix.com> CC: 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 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? >>> In machine_restart we try efi_reboot first specifically to allow for >>> capsule updates. Similarly drivers/firmware/efi/reboot.c registers >>> efi_power_off late in order to override anything else, though that's >>> best-effort at present. >> >> That's very interesting. I think that Xen on ARM should follow what >> Linux does and what Xen already does on x86 and try efi_reset_system >> first on efi systems. > > I would agree. > > Thanks, > Mark. > -- Shannon
Powered by blists - more mailing lists