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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <569E3ACE.5080506@linaro.org>
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