Re: [Xen-devel] [RFC v1 0/8] Prototype for kexec signature verification within Xen

>>> Eric DeVolder 01/14/19 8:48 PM >>> >On April 20, 2018, I posted to xen-devel an RFC inquiring about >support for signature verification of kexec within Xen: > >https://lists.xenproject.org/archives/html/xen-devel/2018-04/msg01655.html > >Since then, I've worked towards a solution. For the

Re: [Xen-devel] [RFC v1 1/8] kexec: add kexec_file_load to libxenctrl

>>> Eric DeVolder 01/14/19 8:49 PM >>> >@@ -213,8 +214,9 @@ typedef struct xen_kexec_load { >uint64_t _pad; >} segments; >uint64_t entry_maddr; /* image entry point machine address. */ >-} xen_kexec_load_t; >+} xen_kexec_load_t, xen_kexec_file_load_t; >DEFINE_XEN_GUEST_HANDLE(xen_kexec_load_t);

Re: [Xen-devel] RFC Xen signature verification for kexec

>>> On 24.04.18 at 12:13, <daniel.ki...@oracle.com> wrote: > On Tue, Apr 24, 2018 at 10:46:38AM +0100, George Dunlap wrote: >> On Mon, Apr 23, 2018 at 11:33 AM, Jan Beulich <jbeul...@suse.com> wrote: >> >>>> On 23.04.18 at 12:25, <daniel.ki...@ora

Re: [Xen-devel] RFC Xen signature verification for kexec

>>> On 23.04.18 at 12:25, <daniel.ki...@oracle.com> wrote: > On Mon, Apr 23, 2018 at 12:55:45AM -0600, Jan Beulich wrote: >> >>> On 20.04.18 at 21:12, <eric.devol...@oracle.com> wrote: >> > Two options for signature verification in Xen &g

Re: [Xen-devel] RFC Xen signature verification for kexec

>>> On 20.04.18 at 21:12, wrote: > Two options for signature verification in Xen > > This proposal outlines two options under consideration for enhancing > Xen to support signature verification of kexec loaded images. The > first option is essentially to mirror Linux

Re: [Xen-devel] [PATCH 2/2] Allow kdump with crash_kexec_post_notifiers

>>> On 13.07.16 at 14:53, wrote: > On 13/07/16 13:20, Petr Tesarik wrote: >> If a crash kernel is loaded, do not crash the running domain. This is >> needed if the kernel is loaded with crash_kexec_post_notifiers, because >> panic notifiers are run before __crash_kexec()

Re: [Xen-devel] More on kexec/purgatory handover

On 13.05.15 at 11:53, david.vra...@citrix.com wrote: On 13/05/15 09:12, Jan Beulich wrote: On 13.05.15 at 09:35, ebied...@xmission.com wrote: Fundamentally if you are transfering control in long mode you have to set up some page table. I giant identity mapped page table that can use 1G

Re: [Xen-devel] More on kexec/purgatory handover

On 13.05.15 at 14:12, ptesa...@suse.cz wrote: On Wed, 13 May 2015 11:01:24 +0100 Jan Beulich jbeul...@suse.com wrote: Okay, if the tools do this in v2, then I think the compatibility v1 path should indeed do so too (in the hypervisor). Are you working on a patch? Not yet, but I'm going

Re: More on kexec/purgatory handover

On 13.05.15 at 07:26, ebied...@xmission.com wrote: The low 640k was weird. We copied it off in purgatory so that it could be capture in a dump. The linux kernel itself winds up using that memory fundamentally because to fire up subsequent processors you have to have memory in the low 640k

Re: More on kexec/purgatory handover

On 13.05.15 at 09:35, ebied...@xmission.com wrote: Fundamentally if you are transfering control in long mode you have to set up some page table. I giant identity mapped page table that can use 1G or 2M pages takes up very little memory, and can be very simply and easily before the transfer

Re: [PATCH] xen/kexec: Clear unused registers before jumping into an image

On 15.11.13 at 21:07, David Vrabel david.vra...@citrix.com wrote: On 15/11/13 15:56, Daniel Kiper wrote: Clear unused registers before jumping into an image. This way loaded image could not assume that any register has an specific info about earlier running Xen hypervisor. However, it also

Re: [PATCH] xen/kexec: Clear unused registers before jumping into an image

On 18.11.13 at 12:08, Daniel Kiper daniel.ki...@oracle.com wrote: On Mon, Nov 18, 2013 at 09:29:41AM +, Jan Beulich wrote: On 15.11.13 at 21:07, David Vrabel david.vra...@citrix.com wrote: On 15/11/13 15:56, Daniel Kiper wrote: Clear unused registers before jumping into an image

Re: [PATCHv10 0/9] Xen: extend kexec hypercall for use with pv-ops kernels

On 08.11.13 at 14:13, David Vrabel david.vra...@citrix.com wrote: Keir, Sorry, forgot to CC you on this series. Can we have your opinion on whether this kexec series can be merged? And if not, what further work and/or testing is required? Just to clarify - unless I missed something,

Re: [Xen-devel] [PATCHv10 0/9] Xen: extend kexec hypercall for use with pv-ops kernels

On 08.11.13 at 15:01, Andrew Cooper andrew.coop...@citrix.com wrote: On 08/11/13 13:19, Jan Beulich wrote: On 08.11.13 at 14:13, David Vrabel david.vra...@citrix.com wrote: Keir, Sorry, forgot to CC you on this series. Can we have your opinion on whether this kexec series can be merged

Re: [PATCH 2/9] kexec: add public interface for improved load/unload sub-ops

On 12.09.13 at 21:49, David Vrabel david.vra...@citrix.com wrote: +#else /* __XEN_INTERFACE_VERSION__ 0x00040400 */ + +#define KEXEC_CMD_kexec_load KEXEC_CMD_kexec_load_v1 +#define KEXEC_CMD_kexec_unload KEXEC_CMD_kexec_unload_v1 +typedef struct xen_kexec_load { +int type; +

Re: [PATCH 2/9] kexec: add public interface for improved load/unload sub-ops

On 13.09.13 at 14:37, David Vrabel david.vra...@citrix.com wrote: On 13/09/13 11:26, Jan Beulich wrote: On 12.09.13 at 21:49, David Vrabel david.vra...@citrix.com wrote: +#else /* __XEN_INTERFACE_VERSION__ 0x00040400 */ + +#define KEXEC_CMD_kexec_load KEXEC_CMD_kexec_load_v1 +#define

Re: [Xen-devel] [PATCH 5/8] kexec: extend hypercall with improved load/unload ops

On 16.04.13 at 19:13, David Vrabel david.vra...@citrix.com wrote: -static int kexec_exec(XEN_GUEST_HANDLE_PARAM(void) uarg) +static int kexec_load(XEN_GUEST_HANDLE_PARAM(void) uarg) { -xen_kexec_exec_t exec; -xen_kexec_image_t *image; -int base, bit, pos, ret = -EINVAL; +

Re: [Xen-devel] [PATCH 5/8] kexec: extend hypercall with improved load/unload ops

On 17.04.13 at 12:11, David Vrabel david.vra...@citrix.com wrote: On 17/04/13 09:55, Jan Beulich wrote: On 16.04.13 at 19:13, David Vrabel david.vra...@citrix.com wrote: -static int kexec_exec(XEN_GUEST_HANDLE_PARAM(void) uarg) +static int kexec_load(XEN_GUEST_HANDLE_PARAM(void) uarg

Re: [Xen-devel] [PATCH 4/8] kexec: add infrastructure for handling kexec images

On 09.04.13 at 18:17, David Vrabel david.vra...@citrix.com wrote: On 09/04/13 08:44, Jan Beulich wrote: On 08.04.13 at 20:59, David Vrabel david.vra...@citrix.com wrote: +ret = kimage_add_page(image, page_to_mfn(page) PAGE_SHIFT); Constructs like this aren't portable. You ought

Re: [Xen-devel] [PATCH 1/8] x86: give FIX_EFI_MPF its own fixmap entry

On 08.04.13 at 20:59, David Vrabel david.vra...@citrix.com wrote: FIX_EFI_MPF was the same as FIX_KEXEC_BASE_0 which is going away. So add its own entry. To be honest, no matter how small the wastage, I'd prefer reusing another entry over creating a new one. FIX_TBOOT_MAP_ADDRESS seems like a

Re: [Xen-devel] [PATCH 4/8] kexec: add infrastructure for handling kexec images

On 08.04.13 at 20:59, David Vrabel david.vra...@citrix.com wrote: +ret = kimage_add_page(image, page_to_mfn(page) PAGE_SHIFT); Constructs like this aren't portable. You ought to use page_to_maddr(), and have the called function have paddr_t instead of unsigned long as the respective

Re: [Xen-devel] [PATCH 3/8] kexec: add public interface for improved load/unload sub-ops

On 08.03.13 at 13:28, Daniel Kiper daniel.ki...@oracle.com wrote: On Fri, Mar 08, 2013 at 11:52:21AM +, David Vrabel wrote: On 08/03/13 10:50, Daniel Kiper wrote: On Thu, Feb 21, 2013 at 05:48:09PM +, David Vrabel wrote: From: David Vrabel david.vra...@citrix.com Add replacement

Re: [Xen-devel] [PATCH 0/4] kexec-tools: add support for Xen 4.3

On 21.02.13 at 18:57, David Vrabel david.vra...@citrix.com wrote: The series adds support for the new hypercall ABI which should be provided by Xen 4.3. Images are loaded into Xen directly with no kernel involvement. Do not apply until the hypervisor side patches are applied to Xen.

Re: [Xen-devel] [PATCH 0/8] kexec: extended kexec hypercall for use with pv-ops kernels

On 21.02.13 at 18:48, David Vrabel david.vra...@citrix.com wrote: The series improves the kexec hypercall by making Xen responsible for loading and relocating the image. This allows kexec to be usable by pv-ops kernels and should allow kexec to be usable from a HVM or PVH privileged domain.

Re: [Xen-devel] [PATCH 3/8] kexec: add public interface for improved load/unload sub-ops

On 21.02.13 at 18:48, David Vrabel david.vra...@citrix.com wrote: --- a/xen/include/public/kexec.h +++ b/xen/include/public/kexec.h @@ -116,12 +116,12 @@ typedef struct xen_kexec_exec { * type == KEXEC_TYPE_DEFAULT or KEXEC_TYPE_CRASH [in] * image == relocation information for kexec

Re: [Xen-devel] [PATCH 5/8] kexec: extend hypercall with improved load/unload ops

On 21.02.13 at 18:48, David Vrabel david.vra...@citrix.com wrote: Crash images are copied directly into the crash region on load. Default images are copied into Xen heap pages and a list of source and destination machine addresses is created. This is list is used in kexec_reloc() to relocate

Re: [Xen-devel] [PATCH 3/8] kexec: add public interface for improved load/unload sub-ops

On 22.02.13 at 12:50, David Vrabel david.vra...@citrix.com wrote: On 22/02/13 08:33, Jan Beulich wrote: On 21.02.13 at 18:48, David Vrabel david.vra...@citrix.com wrote: --- a/xen/include/public/kexec.h +++ b/xen/include/public/kexec.h @@ -116,12 +116,12 @@ typedef struct xen_kexec_exec

Re: [Xen-devel] [PATCH 5/8] kexec: extend hypercall with improved load/unload ops

On 22.02.13 at 12:54, David Vrabel david.vra...@citrix.com wrote: I take your point though and will change it to use the dom heap. Is there a way to verify that all the map/unmaps are correctly done and it isn't just working by chance? Some sort of debug option? Not currently (other than

Re: [Xen-devel] [RFC PATCH 0/3] Improve kexec support in Xen hypervisor

On 16.01.13 at 18:48, David Vrabel david.vra...@citrix.com wrote: Full compatibility is possible and not that hard. Is it actually worth it though? Will there be people updating Xen to 4.3 and unable to update their kernel or userspace tools? I think we simply shouldn't even be considering

Re: [Xen-devel] [RFC PATCH 0/3] Improve kexec support in Xen hypervisor

On 17.01.13 at 11:46, Jan Beulich jbeul...@suse.com wrote: On 16.01.13 at 18:48, David Vrabel david.vra...@citrix.com wrote: Full compatibility is possible and not that hard. Is it actually worth it though? Will there be people updating Xen to 4.3 and unable to update their kernel

Re: [PATCH v3 02/11] x86/kexec: Add extra pointers to transition page table PGD, PUD, PMD and PTE

On 04.01.13 at 18:25, Daniel Kiper daniel.ki...@oracle.com wrote: Right, so where is virtual mapping of control page established? I could not find relevant code in SLES kernel which does that. In the hypervisor (xen/arch/x86/machine_kexec.c:machine_kexec_load()).

Re: [PATCH v3 02/11] x86/kexec: Add extra pointers to transition page table PGD, PUD, PMD and PTE

On 07.01.13 at 13:52, Daniel Kiper daniel.ki...@oracle.com wrote: On Mon, Jan 07, 2013 at 09:48:20AM +, Jan Beulich wrote: On 04.01.13 at 18:25, Daniel Kiper daniel.ki...@oracle.com wrote: Right, so where is virtual mapping of control page established? I could not find relevant code

Re: [Xen-devel] [PATCH v3 00/11] xen: Initial kexec/kdump implementation

On 04.01.13 at 15:22, Daniel Kiper daniel.ki...@oracle.com wrote: On Wed, Jan 02, 2013 at 11:26:43AM +, Andrew Cooper wrote: /sbin/kexec can load the Xen crash kernel itself by issuing hypercalls using /dev/xen/privcmd. This would remove the need for the dom0 kernel to distinguish

Re: [Xen-devel] [PATCH v3 00/11] xen: Initial kexec/kdump implementation

On 02.01.13 at 12:26, Andrew Cooper andrew.coop...@citrix.com wrote: On 27/12/12 18:02, Eric W. Biederman wrote: It probably make sense to split them apart a little even. Thinking about this split, there might be a way to simply it even more. /sbin/kexec can load the Xen crash kernel

Re: [PATCH v3 02/11] x86/kexec: Add extra pointers to transition page table PGD, PUD, PMD and PTE

On 27.12.12 at 03:18, Daniel Kiper daniel.ki...@oracle.com wrote: Some implementations (e.g. Xen PVOPS) could not use part of identity page table to construct transition page table. It means that they require separate PUDs, PMDs and PTEs for virtual and physical (identity) mapping. To

Re: [PATCH v2 01/11] kexec: introduce kexec_ops struct

On 23.11.12 at 02:56, Andrew Cooper andrew.coop...@citrix.com wrote: On 23/11/2012 01:38, H. Peter Anvin wrote: I still don't really get why it can't be isolated from dom0, which would make more sense to me, even for a Xen crash. The crash region (as specified by crashkernel= on the Xen

Re: [PATCH v2 01/11] kexec: introduce kexec_ops struct

On 22.11.12 at 18:37, H. Peter Anvin h...@zytor.com wrote: I actually talked to Ian Jackson at LCE, and mentioned among other things the bogosity of requiring a PUD page for three-level paging in Linux -- a bogosity which has spread from Xen into native. It's a page wasted for no good

Re: [PATCH v2 01/11] kexec: introduce kexec_ops struct

On 23.11.12 at 11:37, Daniel Kiper daniel.ki...@oracle.com wrote: On Fri, Nov 23, 2012 at 09:53:37AM +, Jan Beulich wrote: On 23.11.12 at 02:56, Andrew Cooper andrew.coop...@citrix.com wrote: On 23/11/2012 01:38, H. Peter Anvin wrote: I still don't really get why it can't be isolated

Re: [PATCH v2 02/11] x86/kexec: Add extra pointers to transition page table PGD, PUD, PMD and PTE

On 20.11.12 at 16:04, Daniel Kiper daniel.ki...@oracle.com wrote: Some implementations (e.g. Xen PVOPS) could not use part of identity page table to construct transition page table. It means that they require separate PUDs, PMDs and PTEs for virtual and physical (identity) mapping. To

Re: [PATCH v2 1/6] xen: Always calculate max_cpus value

On 13.08.12 at 10:12, Daniel Kiper daniel.ki...@oracle.com wrote: On Fri, Aug 10, 2012 at 03:39:29PM +0100, Jan Beulich wrote: On 10.08.12 at 15:25, Daniel Kiper daniel.ki...@oracle.com wrote: max_cpus is not available since 20374 changeset (Miscellaneous data placement adjustments

Re: [PATCH v2 1/6] xen: Always calculate max_cpus value

On 10.08.12 at 15:25, Daniel Kiper daniel.ki...@oracle.com wrote: max_cpus is not available since 20374 changeset (Miscellaneous data placement adjustments). It was moved to __initdata section. This section is freed after Xen initialization. Assume that max_cpus is always equal to

Re: [Xen-devel] incorrect layout of globals from head_64.S during kexec boot

On 05.07.12 at 23:06, Olaf Hering o...@aepfle.de wrote: My question is: were to put additional debug to trace the copying of the data section to its final destination? Is this a task of kexec -l or does that happen during decompressing? I suspect the latter. This is the console output before

Re: [Xen-devel] incorrect layout of globals from head_64.S during kexec boot

On 06.07.12 at 14:07, Olaf Hering o...@aepfle.de wrote: But adding some debug to inspect *output in parse_elf() shows that the second entry in program headers is already shifted by 44 bytes in my testing, the others are shifted by the same amount. Unfortunately it's not clear what is shifted

Re: [Xen-devel] incorrect layout of globals from head_64.S during kexec boot

On 06.07.12 at 15:31, Olaf Hering o...@aepfle.de wrote: On Fri, Jul 06, Jan Beulich wrote: On 06.07.12 at 14:07, Olaf Hering o...@aepfle.de wrote: But adding some debug to inspect *output in parse_elf() shows that the second entry in program headers is already shifted by 44 bytes in my

Re: [Xen-devel] incorrect layout of globals from head_64.S during kexec boot

On 06.07.12 at 16:14, Olaf Hering o...@aepfle.de wrote: On Fri, Jul 06, Olaf Hering wrote: I will cleanup my debug changes and post the output. What I see is that the content of the uncompressed vmlinux is appearently already corrupted after decompress(). After I made small changes to

Re: [Xen-devel] [PATCH 1/5] xen: Always calculate max_cpus value

On 05.07.12 at 17:00, Daniel Kiper daniel.ki...@oracle.com wrote: max_cpus is not available since 20374 changeset (Miscellaneous data placement adjustments). It was moved to __initdata section. This section is freed after Xen initialization. Assume that max_cpus is always equal to