https://wiki.xenproject.org/api.php?action=feedcontributions&user=Rpersaud&feedformat=atomXen - User contributions [en]2024-03-28T23:12:07ZUser contributionsMediaWiki 1.31.3https://wiki.xenproject.org/index.php?title=Hyperlaunch&diff=19798Hyperlaunch2020-11-11T02:16:32Z<p>Rpersaud: /* Related work */</p>
<hr />
<div><br />
* Xen Summit 2019: [https://www.youtube.com/watch?v=OrtV6gyHW74 Keynote: Xen Dom0-less]<br />
* Embedded Linux Conference 2019: [https://www.youtube.com/watch?v=UfiP9eAV0WA Static Partitioning Made Simple]<br />
* Dec 2019 [https://lists.xen.org/archives/html/xen-devel/2020-01/msg02413.html design meeting in Cambridge] <br />
* May 2020 domB [https://lists.xenproject.org/archives/html/xen-devel/2020-05/msg00233.html design doc v1]<br />
* Xen Summit 2020 Talk video: [https://www.youtube.com/watch?v=CwWMtbdU5AA Xen System Boot: Launching VMs (DomB)]<br />
* Xen Summit 2020 Design Session video: [https://www.youtube.com/watch?v=jlyWfdW6D-E Next steps for Xen system boot: launching VMs (DomB)]<br />
<br />
<br />
== Related work ==<br />
<br />
<br />
* [https://github.com/TrenchBoot/documentation/tree/master/presentations TrenchBoot] and Dynamic Root of Trust for Measurement (DRTM)<br />
* OpenXT & Boot Integrity [https://openxt.org/ecosystems/ references]<br />
* Platform Security Summit 2018 [https://www.platformsecuritysummit.com/2018/videos/ videos]<br />
* Platform Security Summit 2019 [https://www.platformsecuritysummit.com/2019/videos/ videos]</div>Rpersaudhttps://wiki.xenproject.org/index.php?title=Hyperlaunch&diff=19797Hyperlaunch2020-11-11T02:12:25Z<p>Rpersaud: </p>
<hr />
<div><br />
* Xen Summit 2019: [https://www.youtube.com/watch?v=OrtV6gyHW74 Keynote: Xen Dom0-less]<br />
* Embedded Linux Conference 2019: [https://www.youtube.com/watch?v=UfiP9eAV0WA Static Partitioning Made Simple]<br />
* Dec 2019 [https://lists.xen.org/archives/html/xen-devel/2020-01/msg02413.html design meeting in Cambridge] <br />
* May 2020 domB [https://lists.xenproject.org/archives/html/xen-devel/2020-05/msg00233.html design doc v1]<br />
* Xen Summit 2020 Talk video: [https://www.youtube.com/watch?v=CwWMtbdU5AA Xen System Boot: Launching VMs (DomB)]<br />
* Xen Summit 2020 Design Session video: [https://www.youtube.com/watch?v=jlyWfdW6D-E Next steps for Xen system boot: launching VMs (DomB)]<br />
<br />
<br />
== Related work ==<br />
<br />
<br />
* [https://github.com/TrenchBoot/documentation/tree/master/presentations TrenchBoot] and Dynamic Root of Trust for Measurement (DRTM)<br />
* OpenXT & Boot Integrity [https://openxt.org/ecosystems/ references]<br />
* Platform Security Summit 2019 [https://www.platformsecuritysummit.com/2019/videos/ videos]<br />
* Platform Security Summit 2018 [https://www.platformsecuritysummit.com/2018/videos/ videos]</div>Rpersaudhttps://wiki.xenproject.org/index.php?title=Hyperlaunch&diff=19796Hyperlaunch2020-11-11T02:00:24Z<p>Rpersaud: Created page with "Xen dom0less enables Jailhouse-style static partitioning for Xen on embedded Arm systems. The domB mode of dom0less further disaggregates the Xen dom0-based boot process to r..."</p>
<hr />
<div>Xen dom0less enables Jailhouse-style static partitioning for Xen on embedded Arm systems. The domB mode of dom0less further disaggregates the Xen dom0-based boot process to reduce the trusted computing base (TCB), increase boot integrity and enable more flexibility for Xen-based systems with multiple driver domains.<br />
<br />
* Xen Summit 2019: [https://www.youtube.com/watch?v=OrtV6gyHW74 Keynote: Xen Dom0-less]<br />
* Embedded Linux Conference 2019: [https://www.youtube.com/watch?v=UfiP9eAV0WA Static Partitioning Made Simple]<br />
* Dec 2019 [https://lists.xen.org/archives/html/xen-devel/2020-01/msg02413.html design meeting in Cambridge] <br />
* May 2020 domB [https://lists.xenproject.org/archives/html/xen-devel/2020-05/msg00233.html design doc v1]<br />
* Xen Summit 2020 Talk video: [https://www.youtube.com/watch?v=CwWMtbdU5AA Xen System Boot: Launching VMs (DomB)]<br />
* Xen Summit 2020 Design Session video: [https://www.youtube.com/watch?v=jlyWfdW6D-E Next steps for Xen system boot: launching VMs (DomB)]<br />
<br />
<br />
== Related work ==<br />
<br />
<br />
* [https://github.com/TrenchBoot/documentation/tree/master/presentations TrenchBoot] and Dynamic Root of Trust for Measurement (DRTM)<br />
* OpenXT & Boot Integrity [https://openxt.org/ecosystems/ references]<br />
* Platform Security Summit 2019 [https://www.platformsecuritysummit.com/2019/videos/ videos]<br />
* Platform Security Summit 2018 [https://www.platformsecuritysummit.com/2018/videos/ videos]</div>Rpersaudhttps://wiki.xenproject.org/index.php?title=Argo:_Hypervisor-Mediated_Exchange_(HMX)_for_Xen&diff=19792Argo: Hypervisor-Mediated Exchange (HMX) for Xen2020-08-05T14:04:21Z<p>Rpersaud: /* V4V (historical) */</p>
<hr />
<div><br />
<br />
== Hypervisor Mediated Exchange (HMX) ==<br />
<br />
The technologies provided by VMMs for communication between VMs have a critical impact on VM isolation properties, on the confidence components can have in the delivery of data and in the integrity of the data that is received. The video below identifies aspects of inter-VM communication system architecture that support important properties that are valuable for building secure systems. Terminology is introduced to enable classification of the existing body of art and survey relevant communication technologies in modern hypervisor, OS and microkernel systems. An example is presented — Argo, an inter-VM communication mechanism developed for the Xen hypervisor — and how it is distinguished from other communication channels on the Xen platform and elsewhere.<br />
<br />
* [https://www.platformsecuritysummit.com/2018/speaker/clark/ PSEC 2018 talk by Christopher Clark] (May 2018)<br />
* Xen Summit 2019 [https://www.youtube.com/watch?v=cnC0Tg3jqJQ video] and [https://static.sched.com/hosted_files/xensummit19/92/Argo%20and%20HMX%20-%20OpenXT%20-%20Christopher%20Clark%20-%20Xen%20Summit%202019.pdf slides] (June 2019)<br />
<br />
== V4V (historical) ==<br />
<br />
V4V was created for Citrix XenClient and derivatives are currently deployed in production systems for [https://github.com/openxt OpenXT] and millions of HP/Bromium laptops with [https://github.com/uxen-virt uXen] and vSentry/SureClick. <br />
<br />
* Jean Guyader: [https://lists.xenproject.org/archives/html/xen-devel/2012-05/msg01876.html xen-devel thread on V4V requirements] (May 2012)<br />
* Ross Philipson: [https://lists.xenproject.org/archives/html/xen-devel/2013-05/msg02711.html PATCH (V9) Add V4V to Xen] (May 2013)<br />
<br />
== Argo ==<br />
<br />
Argo was derived from V4V, hypervisor patches were submitted to xen-devel in 2018 and merged in 2019 for Xen 4.12.<br />
<br />
Note: [https://github.com/OpenXT/linux-xen-argo Linux driver for Argo] is not yet upstream.<br />
<br />
'''Upstream'''<br />
<br />
* [https://xenbits.xen.org/docs/unstable/designs/argo.html Xen 4.12 design doc] (March 2019)<br />
<br />
'''History'''<br />
<br />
* [[Media:DRAFT_RFC_Argo_and_HMX_2018-06-19-23-45.pdf| v0.1 design documentation for Argo]] (June 2018)<br />
* [https://docs.google.com/document/d/1VUPdWwd1raDOPhjReVVkmb6YoQB3X5oU12E4ExjO1n0/view Minutes of x86 community call] (September 2018)<br />
* [https://lists.xen.org/archives/html/xen-devel/2018-12/msg00005.html v1 patch series] (November 2018)<br />
* [https://lists.xen.org/archives/html/xen-devel/2019-01/msg00310.html v3 patch series] (January 6 2019)<br />
* [https://lists.xenproject.org/archives/html/xen-devel/2019-01/msg01051.html v4 patch series] (January 14, 2019)<br />
<br />
== Related Work ==<br />
<br />
* Xinhua Zhang: [https://www.cs.uic.edu/~xzhang/vchan/ Xen libvchan] (2014)<br />
* Roman Kagan: [http://events17.linuxfoundation.org/sites/events/files/slides/VMBus%20%28Hyper-V%29%20devices%20in%20QEMU%252FKVM_0.pdf VMBus (Hyper-V) devices in QEMU/KVM] (2015)<br />
* Michael S. Tsirkin: [https://www.linux-kvm.org/images/0/03/Virtio_fall_2017.pdf The future of virtio: riddles, myths and surprises] (2017)</div>Rpersaudhttps://wiki.xenproject.org/index.php?title=Argo:_Hypervisor-Mediated_Exchange_(HMX)_for_Xen&diff=19791Argo: Hypervisor-Mediated Exchange (HMX) for Xen2020-08-05T14:03:51Z<p>Rpersaud: /* V4V (historical) */</p>
<hr />
<div><br />
<br />
== Hypervisor Mediated Exchange (HMX) ==<br />
<br />
The technologies provided by VMMs for communication between VMs have a critical impact on VM isolation properties, on the confidence components can have in the delivery of data and in the integrity of the data that is received. The video below identifies aspects of inter-VM communication system architecture that support important properties that are valuable for building secure systems. Terminology is introduced to enable classification of the existing body of art and survey relevant communication technologies in modern hypervisor, OS and microkernel systems. An example is presented — Argo, an inter-VM communication mechanism developed for the Xen hypervisor — and how it is distinguished from other communication channels on the Xen platform and elsewhere.<br />
<br />
* [https://www.platformsecuritysummit.com/2018/speaker/clark/ PSEC 2018 talk by Christopher Clark] (May 2018)<br />
* Xen Summit 2019 [https://www.youtube.com/watch?v=cnC0Tg3jqJQ video] and [https://static.sched.com/hosted_files/xensummit19/92/Argo%20and%20HMX%20-%20OpenXT%20-%20Christopher%20Clark%20-%20Xen%20Summit%202019.pdf slides] (June 2019)<br />
<br />
== V4V (historical) ==<br />
<br />
V4V was created for Citrix XenClient and derivatives are currently deployed in production systems for [https://github.com/openxt OpenXT] and HP/Bromium laptops with [https://github.com/uxen-virt uXen] and vSentry/SureClick. <br />
<br />
* Jean Guyader: [https://lists.xenproject.org/archives/html/xen-devel/2012-05/msg01876.html xen-devel thread on V4V requirements] (May 2012)<br />
* Ross Philipson: [https://lists.xenproject.org/archives/html/xen-devel/2013-05/msg02711.html PATCH (V9) Add V4V to Xen] (May 2013)<br />
<br />
== Argo ==<br />
<br />
Argo was derived from V4V, hypervisor patches were submitted to xen-devel in 2018 and merged in 2019 for Xen 4.12.<br />
<br />
Note: [https://github.com/OpenXT/linux-xen-argo Linux driver for Argo] is not yet upstream.<br />
<br />
'''Upstream'''<br />
<br />
* [https://xenbits.xen.org/docs/unstable/designs/argo.html Xen 4.12 design doc] (March 2019)<br />
<br />
'''History'''<br />
<br />
* [[Media:DRAFT_RFC_Argo_and_HMX_2018-06-19-23-45.pdf| v0.1 design documentation for Argo]] (June 2018)<br />
* [https://docs.google.com/document/d/1VUPdWwd1raDOPhjReVVkmb6YoQB3X5oU12E4ExjO1n0/view Minutes of x86 community call] (September 2018)<br />
* [https://lists.xen.org/archives/html/xen-devel/2018-12/msg00005.html v1 patch series] (November 2018)<br />
* [https://lists.xen.org/archives/html/xen-devel/2019-01/msg00310.html v3 patch series] (January 6 2019)<br />
* [https://lists.xenproject.org/archives/html/xen-devel/2019-01/msg01051.html v4 patch series] (January 14, 2019)<br />
<br />
== Related Work ==<br />
<br />
* Xinhua Zhang: [https://www.cs.uic.edu/~xzhang/vchan/ Xen libvchan] (2014)<br />
* Roman Kagan: [http://events17.linuxfoundation.org/sites/events/files/slides/VMBus%20%28Hyper-V%29%20devices%20in%20QEMU%252FKVM_0.pdf VMBus (Hyper-V) devices in QEMU/KVM] (2015)<br />
* Michael S. Tsirkin: [https://www.linux-kvm.org/images/0/03/Virtio_fall_2017.pdf The future of virtio: riddles, myths and surprises] (2017)</div>Rpersaudhttps://wiki.xenproject.org/index.php?title=Argo:_Hypervisor-Mediated_Exchange_(HMX)_for_Xen&diff=19790Argo: Hypervisor-Mediated Exchange (HMX) for Xen2020-08-05T14:03:28Z<p>Rpersaud: /* V4V (historical) */</p>
<hr />
<div><br />
<br />
== Hypervisor Mediated Exchange (HMX) ==<br />
<br />
The technologies provided by VMMs for communication between VMs have a critical impact on VM isolation properties, on the confidence components can have in the delivery of data and in the integrity of the data that is received. The video below identifies aspects of inter-VM communication system architecture that support important properties that are valuable for building secure systems. Terminology is introduced to enable classification of the existing body of art and survey relevant communication technologies in modern hypervisor, OS and microkernel systems. An example is presented — Argo, an inter-VM communication mechanism developed for the Xen hypervisor — and how it is distinguished from other communication channels on the Xen platform and elsewhere.<br />
<br />
* [https://www.platformsecuritysummit.com/2018/speaker/clark/ PSEC 2018 talk by Christopher Clark] (May 2018)<br />
* Xen Summit 2019 [https://www.youtube.com/watch?v=cnC0Tg3jqJQ video] and [https://static.sched.com/hosted_files/xensummit19/92/Argo%20and%20HMX%20-%20OpenXT%20-%20Christopher%20Clark%20-%20Xen%20Summit%202019.pdf slides] (June 2019)<br />
<br />
== V4V (historical) ==<br />
<br />
V4V was created for Citrix XenClient and derivatives are currently deployed in production systems for [https://github.com/openxt OpenXT] and HP/Bromium [https://github.com/uxen-virt uXen] and vSentry/SureClick. <br />
<br />
* Jean Guyader: [https://lists.xenproject.org/archives/html/xen-devel/2012-05/msg01876.html xen-devel thread on V4V requirements] (May 2012)<br />
* Ross Philipson: [https://lists.xenproject.org/archives/html/xen-devel/2013-05/msg02711.html PATCH (V9) Add V4V to Xen] (May 2013)<br />
<br />
== Argo ==<br />
<br />
Argo was derived from V4V, hypervisor patches were submitted to xen-devel in 2018 and merged in 2019 for Xen 4.12.<br />
<br />
Note: [https://github.com/OpenXT/linux-xen-argo Linux driver for Argo] is not yet upstream.<br />
<br />
'''Upstream'''<br />
<br />
* [https://xenbits.xen.org/docs/unstable/designs/argo.html Xen 4.12 design doc] (March 2019)<br />
<br />
'''History'''<br />
<br />
* [[Media:DRAFT_RFC_Argo_and_HMX_2018-06-19-23-45.pdf| v0.1 design documentation for Argo]] (June 2018)<br />
* [https://docs.google.com/document/d/1VUPdWwd1raDOPhjReVVkmb6YoQB3X5oU12E4ExjO1n0/view Minutes of x86 community call] (September 2018)<br />
* [https://lists.xen.org/archives/html/xen-devel/2018-12/msg00005.html v1 patch series] (November 2018)<br />
* [https://lists.xen.org/archives/html/xen-devel/2019-01/msg00310.html v3 patch series] (January 6 2019)<br />
* [https://lists.xenproject.org/archives/html/xen-devel/2019-01/msg01051.html v4 patch series] (January 14, 2019)<br />
<br />
== Related Work ==<br />
<br />
* Xinhua Zhang: [https://www.cs.uic.edu/~xzhang/vchan/ Xen libvchan] (2014)<br />
* Roman Kagan: [http://events17.linuxfoundation.org/sites/events/files/slides/VMBus%20%28Hyper-V%29%20devices%20in%20QEMU%252FKVM_0.pdf VMBus (Hyper-V) devices in QEMU/KVM] (2015)<br />
* Michael S. Tsirkin: [https://www.linux-kvm.org/images/0/03/Virtio_fall_2017.pdf The future of virtio: riddles, myths and surprises] (2017)</div>Rpersaudhttps://wiki.xenproject.org/index.php?title=Argo:_Hypervisor-Mediated_Exchange_(HMX)_for_Xen&diff=19789Argo: Hypervisor-Mediated Exchange (HMX) for Xen2020-08-05T14:03:12Z<p>Rpersaud: /* V4V (historical) */</p>
<hr />
<div><br />
<br />
== Hypervisor Mediated Exchange (HMX) ==<br />
<br />
The technologies provided by VMMs for communication between VMs have a critical impact on VM isolation properties, on the confidence components can have in the delivery of data and in the integrity of the data that is received. The video below identifies aspects of inter-VM communication system architecture that support important properties that are valuable for building secure systems. Terminology is introduced to enable classification of the existing body of art and survey relevant communication technologies in modern hypervisor, OS and microkernel systems. An example is presented — Argo, an inter-VM communication mechanism developed for the Xen hypervisor — and how it is distinguished from other communication channels on the Xen platform and elsewhere.<br />
<br />
* [https://www.platformsecuritysummit.com/2018/speaker/clark/ PSEC 2018 talk by Christopher Clark] (May 2018)<br />
* Xen Summit 2019 [https://www.youtube.com/watch?v=cnC0Tg3jqJQ video] and [https://static.sched.com/hosted_files/xensummit19/92/Argo%20and%20HMX%20-%20OpenXT%20-%20Christopher%20Clark%20-%20Xen%20Summit%202019.pdf slides] (June 2019)<br />
<br />
== V4V (historical) ==<br />
<br />
V4V was created for Citrix XenClient and derivatives are currently deployed in production systems for [https://github.com/openxt OpenXT] and HP/Bromium [https://github.com/uxen-virt uXen] and SureClick. <br />
<br />
* Jean Guyader: [https://lists.xenproject.org/archives/html/xen-devel/2012-05/msg01876.html xen-devel thread on V4V requirements] (May 2012)<br />
* Ross Philipson: [https://lists.xenproject.org/archives/html/xen-devel/2013-05/msg02711.html PATCH (V9) Add V4V to Xen] (May 2013)<br />
<br />
== Argo ==<br />
<br />
Argo was derived from V4V, hypervisor patches were submitted to xen-devel in 2018 and merged in 2019 for Xen 4.12.<br />
<br />
Note: [https://github.com/OpenXT/linux-xen-argo Linux driver for Argo] is not yet upstream.<br />
<br />
'''Upstream'''<br />
<br />
* [https://xenbits.xen.org/docs/unstable/designs/argo.html Xen 4.12 design doc] (March 2019)<br />
<br />
'''History'''<br />
<br />
* [[Media:DRAFT_RFC_Argo_and_HMX_2018-06-19-23-45.pdf| v0.1 design documentation for Argo]] (June 2018)<br />
* [https://docs.google.com/document/d/1VUPdWwd1raDOPhjReVVkmb6YoQB3X5oU12E4ExjO1n0/view Minutes of x86 community call] (September 2018)<br />
* [https://lists.xen.org/archives/html/xen-devel/2018-12/msg00005.html v1 patch series] (November 2018)<br />
* [https://lists.xen.org/archives/html/xen-devel/2019-01/msg00310.html v3 patch series] (January 6 2019)<br />
* [https://lists.xenproject.org/archives/html/xen-devel/2019-01/msg01051.html v4 patch series] (January 14, 2019)<br />
<br />
== Related Work ==<br />
<br />
* Xinhua Zhang: [https://www.cs.uic.edu/~xzhang/vchan/ Xen libvchan] (2014)<br />
* Roman Kagan: [http://events17.linuxfoundation.org/sites/events/files/slides/VMBus%20%28Hyper-V%29%20devices%20in%20QEMU%252FKVM_0.pdf VMBus (Hyper-V) devices in QEMU/KVM] (2015)<br />
* Michael S. Tsirkin: [https://www.linux-kvm.org/images/0/03/Virtio_fall_2017.pdf The future of virtio: riddles, myths and surprises] (2017)</div>Rpersaudhttps://wiki.xenproject.org/index.php?title=Argo:_Hypervisor-Mediated_Exchange_(HMX)_for_Xen&diff=19788Argo: Hypervisor-Mediated Exchange (HMX) for Xen2020-08-05T13:50:57Z<p>Rpersaud: /* Hypervisor Mediated Exchange (HMX) */</p>
<hr />
<div><br />
<br />
== Hypervisor Mediated Exchange (HMX) ==<br />
<br />
The technologies provided by VMMs for communication between VMs have a critical impact on VM isolation properties, on the confidence components can have in the delivery of data and in the integrity of the data that is received. The video below identifies aspects of inter-VM communication system architecture that support important properties that are valuable for building secure systems. Terminology is introduced to enable classification of the existing body of art and survey relevant communication technologies in modern hypervisor, OS and microkernel systems. An example is presented — Argo, an inter-VM communication mechanism developed for the Xen hypervisor — and how it is distinguished from other communication channels on the Xen platform and elsewhere.<br />
<br />
* [https://www.platformsecuritysummit.com/2018/speaker/clark/ PSEC 2018 talk by Christopher Clark] (May 2018)<br />
* Xen Summit 2019 [https://www.youtube.com/watch?v=cnC0Tg3jqJQ video] and [https://static.sched.com/hosted_files/xensummit19/92/Argo%20and%20HMX%20-%20OpenXT%20-%20Christopher%20Clark%20-%20Xen%20Summit%202019.pdf slides] (June 2019)<br />
<br />
== V4V (historical) ==<br />
<br />
V4V was created for Citrix XenClient and derivatives are currently deployed in production systems for [https://github.com/openxt OpenXT] and HP/Bromium [https://github.com/uxen-virt uXen]. <br />
<br />
* Jean Guyader: [https://lists.xenproject.org/archives/html/xen-devel/2012-05/msg01876.html xen-devel thread on V4V requirements] (May 2012)<br />
* Ross Philipson: [https://lists.xenproject.org/archives/html/xen-devel/2013-05/msg02711.html PATCH (V9) Add V4V to Xen] (May 2013)<br />
<br />
== Argo ==<br />
<br />
Argo was derived from V4V, hypervisor patches were submitted to xen-devel in 2018 and merged in 2019 for Xen 4.12.<br />
<br />
Note: [https://github.com/OpenXT/linux-xen-argo Linux driver for Argo] is not yet upstream.<br />
<br />
'''Upstream'''<br />
<br />
* [https://xenbits.xen.org/docs/unstable/designs/argo.html Xen 4.12 design doc] (March 2019)<br />
<br />
'''History'''<br />
<br />
* [[Media:DRAFT_RFC_Argo_and_HMX_2018-06-19-23-45.pdf| v0.1 design documentation for Argo]] (June 2018)<br />
* [https://docs.google.com/document/d/1VUPdWwd1raDOPhjReVVkmb6YoQB3X5oU12E4ExjO1n0/view Minutes of x86 community call] (September 2018)<br />
* [https://lists.xen.org/archives/html/xen-devel/2018-12/msg00005.html v1 patch series] (November 2018)<br />
* [https://lists.xen.org/archives/html/xen-devel/2019-01/msg00310.html v3 patch series] (January 6 2019)<br />
* [https://lists.xenproject.org/archives/html/xen-devel/2019-01/msg01051.html v4 patch series] (January 14, 2019)<br />
<br />
== Related Work ==<br />
<br />
* Xinhua Zhang: [https://www.cs.uic.edu/~xzhang/vchan/ Xen libvchan] (2014)<br />
* Roman Kagan: [http://events17.linuxfoundation.org/sites/events/files/slides/VMBus%20%28Hyper-V%29%20devices%20in%20QEMU%252FKVM_0.pdf VMBus (Hyper-V) devices in QEMU/KVM] (2015)<br />
* Michael S. Tsirkin: [https://www.linux-kvm.org/images/0/03/Virtio_fall_2017.pdf The future of virtio: riddles, myths and surprises] (2017)</div>Rpersaudhttps://wiki.xenproject.org/index.php?title=Argo:_Hypervisor-Mediated_Exchange_(HMX)_for_Xen&diff=19787Argo: Hypervisor-Mediated Exchange (HMX) for Xen2020-08-05T13:43:00Z<p>Rpersaud: /* V4V (historical) */</p>
<hr />
<div><br />
<br />
== Hypervisor Mediated Exchange (HMX) ==<br />
<br />
The technologies provided by VMMs for communication between VMs have a critical impact on VM isolation properties, on the confidence components can have in the delivery of data and in the integrity of the data that is received. The video below identifies aspects of inter-VM communication system architecture that support important properties that are valuable for building secure systems. Terminology is introduced to enable classification of the existing body of art and survey relevant communication technologies in modern hypervisor, OS and microkernel systems. An example is presented — Argo, an inter-VM communication mechanism developed for the Xen hypervisor — and how it is distinguished from other communication channels on the Xen platform and elsewhere.<br />
<br />
* [https://www.platformsecuritysummit.com/2018/speaker/clark/ PSEC 2018 talk by Christopher Clark] (May 2018)<br />
* [https://www.youtube.com/watch?v=cnC0Tg3jqJQ Xen Summit 2019 talk by Christopher Clark] (June 2019)<br />
<br />
== V4V (historical) ==<br />
<br />
V4V was created for Citrix XenClient and derivatives are currently deployed in production systems for [https://github.com/openxt OpenXT] and HP/Bromium [https://github.com/uxen-virt uXen]. <br />
<br />
* Jean Guyader: [https://lists.xenproject.org/archives/html/xen-devel/2012-05/msg01876.html xen-devel thread on V4V requirements] (May 2012)<br />
* Ross Philipson: [https://lists.xenproject.org/archives/html/xen-devel/2013-05/msg02711.html PATCH (V9) Add V4V to Xen] (May 2013)<br />
<br />
== Argo ==<br />
<br />
Argo was derived from V4V, hypervisor patches were submitted to xen-devel in 2018 and merged in 2019 for Xen 4.12.<br />
<br />
Note: [https://github.com/OpenXT/linux-xen-argo Linux driver for Argo] is not yet upstream.<br />
<br />
'''Upstream'''<br />
<br />
* [https://xenbits.xen.org/docs/unstable/designs/argo.html Xen 4.12 design doc] (March 2019)<br />
<br />
'''History'''<br />
<br />
* [[Media:DRAFT_RFC_Argo_and_HMX_2018-06-19-23-45.pdf| v0.1 design documentation for Argo]] (June 2018)<br />
* [https://docs.google.com/document/d/1VUPdWwd1raDOPhjReVVkmb6YoQB3X5oU12E4ExjO1n0/view Minutes of x86 community call] (September 2018)<br />
* [https://lists.xen.org/archives/html/xen-devel/2018-12/msg00005.html v1 patch series] (November 2018)<br />
* [https://lists.xen.org/archives/html/xen-devel/2019-01/msg00310.html v3 patch series] (January 6 2019)<br />
* [https://lists.xenproject.org/archives/html/xen-devel/2019-01/msg01051.html v4 patch series] (January 14, 2019)<br />
<br />
== Related Work ==<br />
<br />
* Xinhua Zhang: [https://www.cs.uic.edu/~xzhang/vchan/ Xen libvchan] (2014)<br />
* Roman Kagan: [http://events17.linuxfoundation.org/sites/events/files/slides/VMBus%20%28Hyper-V%29%20devices%20in%20QEMU%252FKVM_0.pdf VMBus (Hyper-V) devices in QEMU/KVM] (2015)<br />
* Michael S. Tsirkin: [https://www.linux-kvm.org/images/0/03/Virtio_fall_2017.pdf The future of virtio: riddles, myths and surprises] (2017)</div>Rpersaudhttps://wiki.xenproject.org/index.php?title=Argo:_Hypervisor-Mediated_Exchange_(HMX)_for_Xen&diff=19786Argo: Hypervisor-Mediated Exchange (HMX) for Xen2020-08-05T13:41:55Z<p>Rpersaud: /* Argo */</p>
<hr />
<div><br />
<br />
== Hypervisor Mediated Exchange (HMX) ==<br />
<br />
The technologies provided by VMMs for communication between VMs have a critical impact on VM isolation properties, on the confidence components can have in the delivery of data and in the integrity of the data that is received. The video below identifies aspects of inter-VM communication system architecture that support important properties that are valuable for building secure systems. Terminology is introduced to enable classification of the existing body of art and survey relevant communication technologies in modern hypervisor, OS and microkernel systems. An example is presented — Argo, an inter-VM communication mechanism developed for the Xen hypervisor — and how it is distinguished from other communication channels on the Xen platform and elsewhere.<br />
<br />
* [https://www.platformsecuritysummit.com/2018/speaker/clark/ PSEC 2018 talk by Christopher Clark] (May 2018)<br />
* [https://www.youtube.com/watch?v=cnC0Tg3jqJQ Xen Summit 2019 talk by Christopher Clark] (June 2019)<br />
<br />
== V4V (historical) ==<br />
<br />
V4V was created for Citrix XenClient and derivatives are currently deployed in production systems for [https://github.com/openxt OpenXT] and Bromium [https://bromium.com/opensource uXen]. <br />
<br />
* Jean Guyader: [https://lists.xenproject.org/archives/html/xen-devel/2012-05/msg01876.html xen-devel thread on V4V requirements] (May 2012)<br />
* Ross Philipson: [https://lists.xenproject.org/archives/html/xen-devel/2013-05/msg02711.html PATCH (V9) Add V4V to Xen] (May 2013)<br />
<br />
== Argo ==<br />
<br />
Argo was derived from V4V, hypervisor patches were submitted to xen-devel in 2018 and merged in 2019 for Xen 4.12.<br />
<br />
Note: [https://github.com/OpenXT/linux-xen-argo Linux driver for Argo] is not yet upstream.<br />
<br />
'''Upstream'''<br />
<br />
* [https://xenbits.xen.org/docs/unstable/designs/argo.html Xen 4.12 design doc] (March 2019)<br />
<br />
'''History'''<br />
<br />
* [[Media:DRAFT_RFC_Argo_and_HMX_2018-06-19-23-45.pdf| v0.1 design documentation for Argo]] (June 2018)<br />
* [https://docs.google.com/document/d/1VUPdWwd1raDOPhjReVVkmb6YoQB3X5oU12E4ExjO1n0/view Minutes of x86 community call] (September 2018)<br />
* [https://lists.xen.org/archives/html/xen-devel/2018-12/msg00005.html v1 patch series] (November 2018)<br />
* [https://lists.xen.org/archives/html/xen-devel/2019-01/msg00310.html v3 patch series] (January 6 2019)<br />
* [https://lists.xenproject.org/archives/html/xen-devel/2019-01/msg01051.html v4 patch series] (January 14, 2019)<br />
<br />
== Related Work ==<br />
<br />
* Xinhua Zhang: [https://www.cs.uic.edu/~xzhang/vchan/ Xen libvchan] (2014)<br />
* Roman Kagan: [http://events17.linuxfoundation.org/sites/events/files/slides/VMBus%20%28Hyper-V%29%20devices%20in%20QEMU%252FKVM_0.pdf VMBus (Hyper-V) devices in QEMU/KVM] (2015)<br />
* Michael S. Tsirkin: [https://www.linux-kvm.org/images/0/03/Virtio_fall_2017.pdf The future of virtio: riddles, myths and surprises] (2017)</div>Rpersaudhttps://wiki.xenproject.org/index.php?title=Argo:_Hypervisor-Mediated_Exchange_(HMX)_for_Xen&diff=19785Argo: Hypervisor-Mediated Exchange (HMX) for Xen2020-08-05T13:41:28Z<p>Rpersaud: /* Argo */</p>
<hr />
<div><br />
<br />
== Hypervisor Mediated Exchange (HMX) ==<br />
<br />
The technologies provided by VMMs for communication between VMs have a critical impact on VM isolation properties, on the confidence components can have in the delivery of data and in the integrity of the data that is received. The video below identifies aspects of inter-VM communication system architecture that support important properties that are valuable for building secure systems. Terminology is introduced to enable classification of the existing body of art and survey relevant communication technologies in modern hypervisor, OS and microkernel systems. An example is presented — Argo, an inter-VM communication mechanism developed for the Xen hypervisor — and how it is distinguished from other communication channels on the Xen platform and elsewhere.<br />
<br />
* [https://www.platformsecuritysummit.com/2018/speaker/clark/ PSEC 2018 talk by Christopher Clark] (May 2018)<br />
* [https://www.youtube.com/watch?v=cnC0Tg3jqJQ Xen Summit 2019 talk by Christopher Clark] (June 2019)<br />
<br />
== V4V (historical) ==<br />
<br />
V4V was created for Citrix XenClient and derivatives are currently deployed in production systems for [https://github.com/openxt OpenXT] and Bromium [https://bromium.com/opensource uXen]. <br />
<br />
* Jean Guyader: [https://lists.xenproject.org/archives/html/xen-devel/2012-05/msg01876.html xen-devel thread on V4V requirements] (May 2012)<br />
* Ross Philipson: [https://lists.xenproject.org/archives/html/xen-devel/2013-05/msg02711.html PATCH (V9) Add V4V to Xen] (May 2013)<br />
<br />
== Argo ==<br />
<br />
Argo was derived from V4V, hypervisor patches were submitted to xen-devel in 2018 and merged in 2019 for Xen 4.12.<br />
<br />
Note: [https://github.com/OpenXT/linux-xen-argo Linux driver for Argo] is not yet upstream.<br />
<br />
'''Upstream version'''<br />
<br />
* [https://xenbits.xen.org/docs/unstable/designs/argo.html Xen 4.12 design doc] (March 2019)<br />
<br />
'''History'''<br />
<br />
* [[Media:DRAFT_RFC_Argo_and_HMX_2018-06-19-23-45.pdf| v0.1 design documentation for Argo]] (June 2018)<br />
* [https://docs.google.com/document/d/1VUPdWwd1raDOPhjReVVkmb6YoQB3X5oU12E4ExjO1n0/view Minutes of x86 community call] (September 2018)<br />
* [https://lists.xen.org/archives/html/xen-devel/2018-12/msg00005.html v1 patch series] (November 2018)<br />
* [https://lists.xen.org/archives/html/xen-devel/2019-01/msg00310.html v3 patch series] (January 6 2019)<br />
* [https://lists.xenproject.org/archives/html/xen-devel/2019-01/msg01051.html v4 patch series] (January 14, 2019)<br />
<br />
== Related Work ==<br />
<br />
* Xinhua Zhang: [https://www.cs.uic.edu/~xzhang/vchan/ Xen libvchan] (2014)<br />
* Roman Kagan: [http://events17.linuxfoundation.org/sites/events/files/slides/VMBus%20%28Hyper-V%29%20devices%20in%20QEMU%252FKVM_0.pdf VMBus (Hyper-V) devices in QEMU/KVM] (2015)<br />
* Michael S. Tsirkin: [https://www.linux-kvm.org/images/0/03/Virtio_fall_2017.pdf The future of virtio: riddles, myths and surprises] (2017)</div>Rpersaudhttps://wiki.xenproject.org/index.php?title=Argo:_Hypervisor-Mediated_Exchange_(HMX)_for_Xen&diff=19784Argo: Hypervisor-Mediated Exchange (HMX) for Xen2020-08-05T13:37:45Z<p>Rpersaud: /* Argo */</p>
<hr />
<div><br />
<br />
== Hypervisor Mediated Exchange (HMX) ==<br />
<br />
The technologies provided by VMMs for communication between VMs have a critical impact on VM isolation properties, on the confidence components can have in the delivery of data and in the integrity of the data that is received. The video below identifies aspects of inter-VM communication system architecture that support important properties that are valuable for building secure systems. Terminology is introduced to enable classification of the existing body of art and survey relevant communication technologies in modern hypervisor, OS and microkernel systems. An example is presented — Argo, an inter-VM communication mechanism developed for the Xen hypervisor — and how it is distinguished from other communication channels on the Xen platform and elsewhere.<br />
<br />
* [https://www.platformsecuritysummit.com/2018/speaker/clark/ PSEC 2018 talk by Christopher Clark] (May 2018)<br />
* [https://www.youtube.com/watch?v=cnC0Tg3jqJQ Xen Summit 2019 talk by Christopher Clark] (June 2019)<br />
<br />
== V4V (historical) ==<br />
<br />
V4V was created for Citrix XenClient and derivatives are currently deployed in production systems for [https://github.com/openxt OpenXT] and Bromium [https://bromium.com/opensource uXen]. <br />
<br />
* Jean Guyader: [https://lists.xenproject.org/archives/html/xen-devel/2012-05/msg01876.html xen-devel thread on V4V requirements] (May 2012)<br />
* Ross Philipson: [https://lists.xenproject.org/archives/html/xen-devel/2013-05/msg02711.html PATCH (V9) Add V4V to Xen] (May 2013)<br />
<br />
== Argo ==<br />
<br />
Argo was derived from V4V and patches were submitted to xen-devel in 2018 and merged in 2019 for Xen 4.12.<br />
<br />
* [[Media:DRAFT_RFC_Argo_and_HMX_2018-06-19-23-45.pdf| v0.1 design documentation for Argo]] (June 2018)<br />
* [https://docs.google.com/document/d/1VUPdWwd1raDOPhjReVVkmb6YoQB3X5oU12E4ExjO1n0/view Minutes of x86 community call] (September 2018)<br />
* [https://lists.xen.org/archives/html/xen-devel/2018-12/msg00005.html v1 patch series] (November 2018)<br />
* [https://lists.xen.org/archives/html/xen-devel/2019-01/msg00310.html v3 patch series] (January 6 2019)<br />
* [https://lists.xenproject.org/archives/html/xen-devel/2019-01/msg01051.html v4 patch series] (January 14, 2019)<br />
* [https://xenbits.xen.org/docs/unstable/designs/argo.html Xen 4.12 design doc] (March 2019)<br />
<br />
== Related Work ==<br />
<br />
* Xinhua Zhang: [https://www.cs.uic.edu/~xzhang/vchan/ Xen libvchan] (2014)<br />
* Roman Kagan: [http://events17.linuxfoundation.org/sites/events/files/slides/VMBus%20%28Hyper-V%29%20devices%20in%20QEMU%252FKVM_0.pdf VMBus (Hyper-V) devices in QEMU/KVM] (2015)<br />
* Michael S. Tsirkin: [https://www.linux-kvm.org/images/0/03/Virtio_fall_2017.pdf The future of virtio: riddles, myths and surprises] (2017)</div>Rpersaudhttps://wiki.xenproject.org/index.php?title=Argo:_Hypervisor-Mediated_Exchange_(HMX)_for_Xen&diff=19783Argo: Hypervisor-Mediated Exchange (HMX) for Xen2020-08-05T13:37:14Z<p>Rpersaud: /* Argo */</p>
<hr />
<div><br />
<br />
== Hypervisor Mediated Exchange (HMX) ==<br />
<br />
The technologies provided by VMMs for communication between VMs have a critical impact on VM isolation properties, on the confidence components can have in the delivery of data and in the integrity of the data that is received. The video below identifies aspects of inter-VM communication system architecture that support important properties that are valuable for building secure systems. Terminology is introduced to enable classification of the existing body of art and survey relevant communication technologies in modern hypervisor, OS and microkernel systems. An example is presented — Argo, an inter-VM communication mechanism developed for the Xen hypervisor — and how it is distinguished from other communication channels on the Xen platform and elsewhere.<br />
<br />
* [https://www.platformsecuritysummit.com/2018/speaker/clark/ PSEC 2018 talk by Christopher Clark] (May 2018)<br />
* [https://www.youtube.com/watch?v=cnC0Tg3jqJQ Xen Summit 2019 talk by Christopher Clark] (June 2019)<br />
<br />
== V4V (historical) ==<br />
<br />
V4V was created for Citrix XenClient and derivatives are currently deployed in production systems for [https://github.com/openxt OpenXT] and Bromium [https://bromium.com/opensource uXen]. <br />
<br />
* Jean Guyader: [https://lists.xenproject.org/archives/html/xen-devel/2012-05/msg01876.html xen-devel thread on V4V requirements] (May 2012)<br />
* Ross Philipson: [https://lists.xenproject.org/archives/html/xen-devel/2013-05/msg02711.html PATCH (V9) Add V4V to Xen] (May 2013)<br />
<br />
== Argo ==<br />
<br />
Argo was derived from V4V and patches were submitted to xen-devel in 2018 and merged in 2019 for Xen 4.12.<br />
<br />
<br />
* [https://xenbits.xen.org/docs/unstable/designs/argo.html Xen 4.12 design doc] (March 2019)<br />
* [[Media:DRAFT_RFC_Argo_and_HMX_2018-06-19-23-45.pdf| v0.1 design documentation for Argo]] (June 2018)<br />
* [https://docs.google.com/document/d/1VUPdWwd1raDOPhjReVVkmb6YoQB3X5oU12E4ExjO1n0/view Minutes of x86 community call] (September 2018)<br />
* [https://lists.xen.org/archives/html/xen-devel/2018-12/msg00005.html v1 patch series] (November 2018)<br />
* [https://lists.xen.org/archives/html/xen-devel/2019-01/msg00310.html v3 patch series] (January 6 2019)<br />
* [https://lists.xenproject.org/archives/html/xen-devel/2019-01/msg01051.html v4 patch series] (January 14, 2019)<br />
<br />
== Related Work ==<br />
<br />
* Xinhua Zhang: [https://www.cs.uic.edu/~xzhang/vchan/ Xen libvchan] (2014)<br />
* Roman Kagan: [http://events17.linuxfoundation.org/sites/events/files/slides/VMBus%20%28Hyper-V%29%20devices%20in%20QEMU%252FKVM_0.pdf VMBus (Hyper-V) devices in QEMU/KVM] (2015)<br />
* Michael S. Tsirkin: [https://www.linux-kvm.org/images/0/03/Virtio_fall_2017.pdf The future of virtio: riddles, myths and surprises] (2017)</div>Rpersaudhttps://wiki.xenproject.org/index.php?title=Argo:_Hypervisor-Mediated_Exchange_(HMX)_for_Xen&diff=19782Argo: Hypervisor-Mediated Exchange (HMX) for Xen2020-08-05T13:32:36Z<p>Rpersaud: /* Hypervisor Mediated Exchange (HMX) */</p>
<hr />
<div><br />
<br />
== Hypervisor Mediated Exchange (HMX) ==<br />
<br />
The technologies provided by VMMs for communication between VMs have a critical impact on VM isolation properties, on the confidence components can have in the delivery of data and in the integrity of the data that is received. The video below identifies aspects of inter-VM communication system architecture that support important properties that are valuable for building secure systems. Terminology is introduced to enable classification of the existing body of art and survey relevant communication technologies in modern hypervisor, OS and microkernel systems. An example is presented — Argo, an inter-VM communication mechanism developed for the Xen hypervisor — and how it is distinguished from other communication channels on the Xen platform and elsewhere.<br />
<br />
* [https://www.platformsecuritysummit.com/2018/speaker/clark/ PSEC 2018 talk by Christopher Clark] (May 2018)<br />
* [https://www.youtube.com/watch?v=cnC0Tg3jqJQ Xen Summit 2019 talk by Christopher Clark] (June 2019)<br />
<br />
== V4V (historical) ==<br />
<br />
V4V was created for Citrix XenClient and derivatives are currently deployed in production systems for [https://github.com/openxt OpenXT] and Bromium [https://bromium.com/opensource uXen]. <br />
<br />
* Jean Guyader: [https://lists.xenproject.org/archives/html/xen-devel/2012-05/msg01876.html xen-devel thread on V4V requirements] (May 2012)<br />
* Ross Philipson: [https://lists.xenproject.org/archives/html/xen-devel/2013-05/msg02711.html PATCH (V9) Add V4V to Xen] (May 2013)<br />
<br />
== Argo ==<br />
<br />
Argo is derived from V4V and patches will be submitted to xen-devel in 2018.<br />
<br />
* [[Media:DRAFT_RFC_Argo_and_HMX_2018-06-19-23-45.pdf| v0.1 design documentation for Argo]] (June 2018)<br />
* [https://docs.google.com/document/d/1VUPdWwd1raDOPhjReVVkmb6YoQB3X5oU12E4ExjO1n0/view Minutes of x86 community call] (September 2018)<br />
* [https://lists.xen.org/archives/html/xen-devel/2018-12/msg00005.html v1 patch series] (November 2018)<br />
* [https://lists.xen.org/archives/html/xen-devel/2019-01/msg00310.html v3 patch series] (January 6 2019)<br />
* [https://lists.xenproject.org/archives/html/xen-devel/2019-01/msg01051.html v4 patch series] (January 14, 2019)<br />
<br />
== Related Work ==<br />
<br />
* Xinhua Zhang: [https://www.cs.uic.edu/~xzhang/vchan/ Xen libvchan] (2014)<br />
* Roman Kagan: [http://events17.linuxfoundation.org/sites/events/files/slides/VMBus%20%28Hyper-V%29%20devices%20in%20QEMU%252FKVM_0.pdf VMBus (Hyper-V) devices in QEMU/KVM] (2015)<br />
* Michael S. Tsirkin: [https://www.linux-kvm.org/images/0/03/Virtio_fall_2017.pdf The future of virtio: riddles, myths and surprises] (2017)</div>Rpersaudhttps://wiki.xenproject.org/index.php?title=Xen_EFI&diff=19661Xen EFI2019-11-22T02:37:55Z<p>Rpersaud: /* Compatibility of Host UEFI Firmware, Xen and UEFI Runtime Services */</p>
<hr />
<div>= Xen in EFI =<br />
<br />
Xen 4.3 and later can be built as EFI binaries. Xen 4.5 can be built as an EFI binary under ARM.<br />
Xen 4.9 can be built with Multiboot2 support which GRUB2 2.02 uses.<br />
<br />
Linux 3.17 and later when built with <code>CONFIG_XEN_EFI</code> can be booted under Xen in EFI platform.<br />
<br />
Xen does support verifying of payloads, such as the initial kernel and its ramdisk via the Shim protocol (GUID: 0x605dab50, 0xe046, 0x4300, {0xab, 0xb6, 0x3d, 0xd8, 0x10, 0xdd, 0x8b, 0x23).<br />
<br />
For shim repo, please see [https://github.com/mjg59/shim shim]. <br />
<br />
= Compiling Xen as EFI =<br />
<br />
== Compiling under x86 ==<br />
<br />
During the compilation process most of the Xen hypervisor code is compiled using the normal compiler (GCC). Only during the link-time do we employ the EFI linker to built an EFI binary.<br />
<br />
<br />
As of Ubuntu 16.04 the binutils is compiled with PE (EFI) support. To verify run <b>ld -V</b>.<br />
You are looking for <b>i386pe</b> in it, as so:<br />
<br />
<pre><br />
$ ld -V<br />
GNU ld version 2.26.1-1.2.fc25<br />
Supported emulations:<br />
elf_x86_64<br />
elf32_x86_64<br />
elf_i386<br />
elf_iamcu<br />
i386linux<br />
elf_l1om<br />
elf_k1om<br />
i386pep<br />
i386pe<br />
</pre><br />
<br />
Alternatively you can build the [http://wiki.OSDev.org/UEFI#Developing_with_GNU-EFI GCC crosstool chain] documented in the [http://wiki.OSDev.org OSDev.org wiki.]<br />
<br />
Or you can recompile your binutils (Fedora Core 25):<br />
<br />
* dnf download --source binutils<br />
* rpm -hiv binutil*.srpm<br />
* cd /usr/src/redhat/SPECS<br />
* sudo dnf builddep --spec binutils.spec<br />
* patch -p1 < pe_binutils.patch<br />
<br />
The pe_binutils.patch looks as follow:<br />
<br />
<pre><br />
--- binutils.spec.orig 2017-01-31 09:24:18.988130013 -0500<br />
+++ binutils.spec 2017-01-31 09:25:38.975347558 -0500<br />
@@ -22,7 +22,7 @@<br />
Summary: A GNU collection of binary utilities<br />
Name: %{?cross}binutils%{?_with_debug:-debug}<br />
Version: 2.26.1<br />
-Release: 1%{?dist}<br />
+Release: 1.2%{?dist}<br />
License: GPLv3+<br />
Group: Development/Tools<br />
URL: http://sources.redhat.com/binutils<br />
@@ -263,6 +263,11 @@<br />
;;<br />
esac<br />
<br />
+case %{binutils_target} in x86_64*|i?86*|arm*|aarch64*)<br />
+ CARGS="$CARGS --enable-targets=x86_64-pep"<br />
+ ;;<br />
+esac<br />
+<br />
%if 0%{?_with_debug:1}<br />
CFLAGS="$CFLAGS -O0 -ggdb2 -Wno-error -D_FORTIFY_SOURCE=0"<br />
%define enable_shared 0<br />
@@ -519,6 +524,9 @@<br />
%endif # %{isnative}<br />
<br />
%changelog<br />
+* Tue Jan 31 2017 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> 2.26-1.1.2<br />
+- Add PE support.<br />
+<br />
* Mon Aug 15 2016 Nick Clifton <nickc@redhat.com> 2.26.1-1<br />
- Rebase on FSF binutils 2.26.1 release.<br />
- Retire: binutils-2.26-formatting.patch<br />
</pre><br />
<br />
* rpmbuild -ba binutils.spec<br />
* cd ../RPMS/x86_64/<br />
* rpm -U binut*.rpm<br />
<br />
In either way, you will have an ''xen.efi'' file.<br />
<br />
== Compiling under ARM ==<br />
<br />
From: [http://xenbits.xenproject.org/docs/unstable/misc/efi.html efi.html]:<br />
<blockquote>For arm64, the PE/COFF header is open-coded in assembly, so no toolchain support for PE/COFF is required. Also, the PE/COFF header co-exists with the normal Image format, so a single binary may be booted as an Image file or as an EFI application.</blockquote><br />
<br />
= Booting Xen under EFI platform =<br />
<br />
There are two ways of booting Xen:<br />
* From the EFI platform - which shows up in BIOS boot menu.<br />
* Using an bootloader (such as GRUB2)<br />
<br />
== Xen as EFI binary (loading) ==<br />
<br />
Xen.efi as an EFI binary can be executed by the EFI firmware immediately. As the firmware does not provide an command line (nor would you want to have it), Xen expects an configuration file<br />
to tell it what initial domain (and ramdisk) to load afterwards. This [http://xenbits.xenproject.org/docs/unstable/misc/efi.html configuration file]<br />
must reside in the same directory as the ''xen.efi''. Also the payloads (vmlinuz and ramdisk) MUST also reside in said directory.<br />
<br />
The boot mechanism is simple:<br />
<br />
EFI firmware => Xen.efi [loads vmlinuz and ramdisk and executes vmlinuz]<br />
<br />
To install it please follow these directions:<br />
<br />
* sudo mkdir /boot/efi/EFI/xen<br />
* sudo cp /boot/vmlinuz* /boot/efi/EFI/xen<br />
* sudo cp /boot/initr* /boot/efi/EFI/xen/<br />
[Both the Linux kernel and initramdisk MUST reside in the same directory as xen.efi]<br />
<br />
* sudo cp /boot/xen/xen.efi /boot/efi/EFI/xen<br />
* Create the xen.cfg file:<br />
<pre><br />
cat << EOF > /boot/efi/EFI/xen/xen.cfg<br />
global]<br />
default=ubuntu<br />
<br />
[ubuntu]<br />
options=console=vga,com1 com1=115200,8n1 iommu=verbose ucode=scan flask=disabled conring_size=2097152 loglvl=all<br />
kernel=vmlinuz-4.8.0-41-generic root=UUID=3f1e35fb-9907-48d1-b621-42369d5ad88f ro quiet vt.handoff=7 console=hvc0<br />
ramdisk=initrd.img-4.8.0-41-generic<br />
<br />
[fedora]<br />
options=console=vga,com1 com1=115200,8n1 iommu=verbose ucode=scan flask=disabled conring_size=2097152 loglvl=all<br />
kernel=vmlinuz-4.9.3-200.fc25.x86_64 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/swap rd.lvm.lv=fedora/root console=hvc0 console=tty0<br />
ramdisk=initramfs-4.9.3-200.fc25.x86_64.img<br />
<br />
</pre><br />
<br />
Make sure to modify the 'UUID' to match yours. You can find that from<br />
<b>cat /proc/cmdline</b>.<br />
<br />
Also, modify the ''default'' to point to the right one.<br />
<br />
Naturally the 'vmlinuz' and 'initramfs' may differ. Double-check that please.<br />
<br />
* Add the xen.efi to the EFI boot manager:<br />
<pre>efibootmgr -w -L Xen -l "\EFI\Xen\xen.efi" -c</pre><br />
<br />
which will produce a new boot target (for example):<br />
<br />
<pre><br />
[root@localhost EFI]# ls /boot/efi/EFI/Xen<br />
vmlinuz-4.9.3-200.fc25.x86_64 initramfs-4.9.3-200.fc25.x86_64.img xen.cfg xen.efi<br />
[root@localhost Xen]# efibootmgr -w -L Xen -l "\EFI\Xen\xen.efi" -c<br />
BootCurrent: 0000<br />
Timeout: 0 seconds<br />
BootOrder: 0005,0001,0002,0003,0004,0000<br />
Boot0000* Fedora<br />
Boot0001* UEFI: ASUS DRW-24B1ST<br />
Boot0002* CD/DVD Drive <br />
Boot0003* Hard Drive <br />
Boot0004* Network Card <br />
Boot0005* Xen<br />
</pre><br />
<br />
== Xen as gz binary ==<br />
<br />
GRUB2 loader when built as an EFI binary can load various OS-es. The most common<br />
one is Linux where it uses the ''linuxefi'' GRUB module. However GRUB2 also has<br />
support for ''multiboot'' protocol which is what Xen uses. Sadly v1 of multiboot<br />
API does not have enough data to provide information to Xen under the EFI platform.<br />
<br />
GRUB 2.02 has also support for 'multiboot2' which can pass the EFI ImageHandler<br />
to the underlaying payload. This allows:<br />
<br />
EFI firmware => GRUB2.EFI -> multiboot2 -> [xen.gz, vmlinuz, ramdisk]<br />
<br />
And GRUB2 would be responsible for reading from the ESP the various files and<br />
loading them in the memory.<br />
<br />
Xen 4.9 and later implements both multiboot and multiboot2. Prior versions<br />
only implemented multiboot.<br />
<br />
If you are using an older version you can use the GRUB2 ''chainloader'' workaround. Example:<br />
<br />
<pre><br />
menuentry "Xen EFI" {<br />
insmod part_gpt<br />
insmod search_fs_uuid<br />
insmod chain<br />
chainloader (hd0,gpt1)/EFI/XEN/xen.efi<br />
}<br />
</pre><br />
<br />
To build GRUB2 from scratch and utilize it please follow these instructions:<br />
<br />
* git clone https://git.savannah.gnu.org/git/grub.git<br />
* cd grub<br />
* ./autogen.sh<br />
* ./configure --target=x86_64 --with-platform=efi<br />
* make<br />
* sudo make install<br />
[It will install the files in /usr/local so won't conflict with the installed version]<br />
* sudo mkdir -p /usr/local/etc/default<br />
* Setup an default GRUB entries:<br />
<pre><br />
cat << EOF > /usr/local/etc/default/grub<br />
GRUB_DEFAULT=0<br />
GRUB_TIMEOUT=10<br />
GRUB_CMDLINE_LINUX="console=hvc0 loglevel=8 initcall_debug"<br />
GRUB_CMDLINE_XEN="loglvl=all guest_loglvl=all console=com1,vga com1=115200,8n1"<br />
GRUB_TERMINAL=serial<br />
GRUB_SERIAL_COMMAND="serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1"<br />
EOF<br />
</pre><br />
[This is optional]<br />
* sudo chmod 400 /usr/local/etc/grub.d/10_linux<br />
[This is optional, but this way you will only have Xen entries]<br />
* Script to combine the different grub modules in one EFI file:<br />
<pre><br />
cat << EOF > $HOME/build-grub<br />
#!/bin/bash <br />
<br />
GRUB_MODULES=" all_video boot btrfs cat chain configfile echo \<br />
efifwsetup efinet ext2 fat font gfxmenu gfxterm gzio halt \<br />
hfsplus iso9660 jpeg loadenv loopback lvm mdraid09 mdraid1x \<br />
minicmd normal part_apple part_msdos part_gpt \<br />
password_pbkdf2 png \<br />
reboot search search_fs_uuid search_fs_file search_label \<br />
serial sleep syslinuxcfg test tftp video xfs \<br />
linux backtrace usb usbserial_common \<br />
usbserial_pl2303 usbserial_ftdi usbserial_usbdebug multiboot multiboot2"<br />
<br />
echo $GRUB_MODULES<br />
./grub/grub-mkimage -v -O x86_64-efi -o grub2.efi -p /EFI/grub2 \<br />
-d grub/grub-core ${GRUB_MODULES}<br />
EOF<br />
</pre><br />
* chmod 755 $HOME/build-grub<br />
* $HOME/build-grub<br />
[That creates the grub2.efi with 'multiboot2' support along with other modules]<br />
* sudo mkdir /boot/efi/EFI/grub2<br />
* sudo cp $HOME/grub2.efi /boot/efi/EFI/grub2<br />
* ./grub-mkconfig -o /boot/efi/EFI/grub2/grub.cfg<br />
[Inspect the grub.cfg. Make sure that it has 'multiboot2' and 'module2' for Xen.<br />
You may need the patch titled: <b>[PATCH] Use grub-file to figure out whether multiboot2 should be used for Xen.gz</b><br />
See [https://lists.xen.org/archives/html/xen-devel/2017-03/txtCeHTNmz1hZ.txt]<br />
* sudo efibootmgr -w -L GRUB2 -l "\EFI\grub2\grub2.efi" -c<br />
[To create an EFI boot manager 'GRUB2' entry]<br />
<br />
And you are good to go.<br />
<br />
= Compatibility of UEFI Host Firmware, Xen and UEFI Runtime Services =<br />
<br />
On some devices with UEFI firmware that does not strictly conform to UEFI specifications, Xen may fail to boot when UEFI Runtime Services is enabled. The Xen command line option '''efi=no-rs''' can be used to disable UEFI Runtime Services, which may allow Xen to boot on some machines with non-compliant host UEFI firmware, at the cost of losing access to UEFI Runtime Services.<br />
<br />
Ideally, such UEFI firmware non-compliance would be identified during OEM/ODM pre-release testing with Xen and other bare-metal hypervisors and operating systems. In practice, it is difficult to obtain UEFI firmware fixes for hardware devices that are already released. If you are unable to obtain compliant UEFI host firmware from your device OEM, Xen 4.13 provides an opt-in (''expert'') build-time config option (CONFIG_EFI_SET_VIRTUAL_ADDRESS_MAP=y) to improve compatibility between non-compliant UEFI host firmware, Xen and UEFI Runtime Services. <br />
<br />
Boot compatibility was reportedly improved for the following devices, with variability between multiboot2 and xen.efi:<br />
<br />
* Thinkpad W540<br />
* Thinkpad X230, firmware 2.77<br />
* Thinkpad P52, firmware 1.25<br />
<br />
Please update the above list with device make, model and firmware version.</div>Rpersaudhttps://wiki.xenproject.org/index.php?title=Xen_EFI&diff=19660Xen EFI2019-11-22T01:46:20Z<p>Rpersaud: </p>
<hr />
<div>= Xen in EFI =<br />
<br />
Xen 4.3 and later can be built as EFI binaries. Xen 4.5 can be built as an EFI binary under ARM.<br />
Xen 4.9 can be built with Multiboot2 support which GRUB2 2.02 uses.<br />
<br />
Linux 3.17 and later when built with <code>CONFIG_XEN_EFI</code> can be booted under Xen in EFI platform.<br />
<br />
Xen does support verifying of payloads, such as the initial kernel and its ramdisk via the Shim protocol (GUID: 0x605dab50, 0xe046, 0x4300, {0xab, 0xb6, 0x3d, 0xd8, 0x10, 0xdd, 0x8b, 0x23).<br />
<br />
For shim repo, please see [https://github.com/mjg59/shim shim]. <br />
<br />
= Compiling Xen as EFI =<br />
<br />
== Compiling under x86 ==<br />
<br />
During the compilation process most of the Xen hypervisor code is compiled using the normal compiler (GCC). Only during the link-time do we employ the EFI linker to built an EFI binary.<br />
<br />
<br />
As of Ubuntu 16.04 the binutils is compiled with PE (EFI) support. To verify run <b>ld -V</b>.<br />
You are looking for <b>i386pe</b> in it, as so:<br />
<br />
<pre><br />
$ ld -V<br />
GNU ld version 2.26.1-1.2.fc25<br />
Supported emulations:<br />
elf_x86_64<br />
elf32_x86_64<br />
elf_i386<br />
elf_iamcu<br />
i386linux<br />
elf_l1om<br />
elf_k1om<br />
i386pep<br />
i386pe<br />
</pre><br />
<br />
Alternatively you can build the [http://wiki.OSDev.org/UEFI#Developing_with_GNU-EFI GCC crosstool chain] documented in the [http://wiki.OSDev.org OSDev.org wiki.]<br />
<br />
Or you can recompile your binutils (Fedora Core 25):<br />
<br />
* dnf download --source binutils<br />
* rpm -hiv binutil*.srpm<br />
* cd /usr/src/redhat/SPECS<br />
* sudo dnf builddep --spec binutils.spec<br />
* patch -p1 < pe_binutils.patch<br />
<br />
The pe_binutils.patch looks as follow:<br />
<br />
<pre><br />
--- binutils.spec.orig 2017-01-31 09:24:18.988130013 -0500<br />
+++ binutils.spec 2017-01-31 09:25:38.975347558 -0500<br />
@@ -22,7 +22,7 @@<br />
Summary: A GNU collection of binary utilities<br />
Name: %{?cross}binutils%{?_with_debug:-debug}<br />
Version: 2.26.1<br />
-Release: 1%{?dist}<br />
+Release: 1.2%{?dist}<br />
License: GPLv3+<br />
Group: Development/Tools<br />
URL: http://sources.redhat.com/binutils<br />
@@ -263,6 +263,11 @@<br />
;;<br />
esac<br />
<br />
+case %{binutils_target} in x86_64*|i?86*|arm*|aarch64*)<br />
+ CARGS="$CARGS --enable-targets=x86_64-pep"<br />
+ ;;<br />
+esac<br />
+<br />
%if 0%{?_with_debug:1}<br />
CFLAGS="$CFLAGS -O0 -ggdb2 -Wno-error -D_FORTIFY_SOURCE=0"<br />
%define enable_shared 0<br />
@@ -519,6 +524,9 @@<br />
%endif # %{isnative}<br />
<br />
%changelog<br />
+* Tue Jan 31 2017 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> 2.26-1.1.2<br />
+- Add PE support.<br />
+<br />
* Mon Aug 15 2016 Nick Clifton <nickc@redhat.com> 2.26.1-1<br />
- Rebase on FSF binutils 2.26.1 release.<br />
- Retire: binutils-2.26-formatting.patch<br />
</pre><br />
<br />
* rpmbuild -ba binutils.spec<br />
* cd ../RPMS/x86_64/<br />
* rpm -U binut*.rpm<br />
<br />
In either way, you will have an ''xen.efi'' file.<br />
<br />
== Compiling under ARM ==<br />
<br />
From: [http://xenbits.xenproject.org/docs/unstable/misc/efi.html efi.html]:<br />
<blockquote>For arm64, the PE/COFF header is open-coded in assembly, so no toolchain support for PE/COFF is required. Also, the PE/COFF header co-exists with the normal Image format, so a single binary may be booted as an Image file or as an EFI application.</blockquote><br />
<br />
= Booting Xen under EFI platform =<br />
<br />
There are two ways of booting Xen:<br />
* From the EFI platform - which shows up in BIOS boot menu.<br />
* Using an bootloader (such as GRUB2)<br />
<br />
== Xen as EFI binary (loading) ==<br />
<br />
Xen.efi as an EFI binary can be executed by the EFI firmware immediately. As the firmware does not provide an command line (nor would you want to have it), Xen expects an configuration file<br />
to tell it what initial domain (and ramdisk) to load afterwards. This [http://xenbits.xenproject.org/docs/unstable/misc/efi.html configuration file]<br />
must reside in the same directory as the ''xen.efi''. Also the payloads (vmlinuz and ramdisk) MUST also reside in said directory.<br />
<br />
The boot mechanism is simple:<br />
<br />
EFI firmware => Xen.efi [loads vmlinuz and ramdisk and executes vmlinuz]<br />
<br />
To install it please follow these directions:<br />
<br />
* sudo mkdir /boot/efi/EFI/xen<br />
* sudo cp /boot/vmlinuz* /boot/efi/EFI/xen<br />
* sudo cp /boot/initr* /boot/efi/EFI/xen/<br />
[Both the Linux kernel and initramdisk MUST reside in the same directory as xen.efi]<br />
<br />
* sudo cp /boot/xen/xen.efi /boot/efi/EFI/xen<br />
* Create the xen.cfg file:<br />
<pre><br />
cat << EOF > /boot/efi/EFI/xen/xen.cfg<br />
global]<br />
default=ubuntu<br />
<br />
[ubuntu]<br />
options=console=vga,com1 com1=115200,8n1 iommu=verbose ucode=scan flask=disabled conring_size=2097152 loglvl=all<br />
kernel=vmlinuz-4.8.0-41-generic root=UUID=3f1e35fb-9907-48d1-b621-42369d5ad88f ro quiet vt.handoff=7 console=hvc0<br />
ramdisk=initrd.img-4.8.0-41-generic<br />
<br />
[fedora]<br />
options=console=vga,com1 com1=115200,8n1 iommu=verbose ucode=scan flask=disabled conring_size=2097152 loglvl=all<br />
kernel=vmlinuz-4.9.3-200.fc25.x86_64 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/swap rd.lvm.lv=fedora/root console=hvc0 console=tty0<br />
ramdisk=initramfs-4.9.3-200.fc25.x86_64.img<br />
<br />
</pre><br />
<br />
Make sure to modify the 'UUID' to match yours. You can find that from<br />
<b>cat /proc/cmdline</b>.<br />
<br />
Also, modify the ''default'' to point to the right one.<br />
<br />
Naturally the 'vmlinuz' and 'initramfs' may differ. Double-check that please.<br />
<br />
* Add the xen.efi to the EFI boot manager:<br />
<pre>efibootmgr -w -L Xen -l "\EFI\Xen\xen.efi" -c</pre><br />
<br />
which will produce a new boot target (for example):<br />
<br />
<pre><br />
[root@localhost EFI]# ls /boot/efi/EFI/Xen<br />
vmlinuz-4.9.3-200.fc25.x86_64 initramfs-4.9.3-200.fc25.x86_64.img xen.cfg xen.efi<br />
[root@localhost Xen]# efibootmgr -w -L Xen -l "\EFI\Xen\xen.efi" -c<br />
BootCurrent: 0000<br />
Timeout: 0 seconds<br />
BootOrder: 0005,0001,0002,0003,0004,0000<br />
Boot0000* Fedora<br />
Boot0001* UEFI: ASUS DRW-24B1ST<br />
Boot0002* CD/DVD Drive <br />
Boot0003* Hard Drive <br />
Boot0004* Network Card <br />
Boot0005* Xen<br />
</pre><br />
<br />
== Xen as gz binary ==<br />
<br />
GRUB2 loader when built as an EFI binary can load various OS-es. The most common<br />
one is Linux where it uses the ''linuxefi'' GRUB module. However GRUB2 also has<br />
support for ''multiboot'' protocol which is what Xen uses. Sadly v1 of multiboot<br />
API does not have enough data to provide information to Xen under the EFI platform.<br />
<br />
GRUB 2.02 has also support for 'multiboot2' which can pass the EFI ImageHandler<br />
to the underlaying payload. This allows:<br />
<br />
EFI firmware => GRUB2.EFI -> multiboot2 -> [xen.gz, vmlinuz, ramdisk]<br />
<br />
And GRUB2 would be responsible for reading from the ESP the various files and<br />
loading them in the memory.<br />
<br />
Xen 4.9 and later implements both multiboot and multiboot2. Prior versions<br />
only implemented multiboot.<br />
<br />
If you are using an older version you can use the GRUB2 ''chainloader'' workaround. Example:<br />
<br />
<pre><br />
menuentry "Xen EFI" {<br />
insmod part_gpt<br />
insmod search_fs_uuid<br />
insmod chain<br />
chainloader (hd0,gpt1)/EFI/XEN/xen.efi<br />
}<br />
</pre><br />
<br />
To build GRUB2 from scratch and utilize it please follow these instructions:<br />
<br />
* git clone https://git.savannah.gnu.org/git/grub.git<br />
* cd grub<br />
* ./autogen.sh<br />
* ./configure --target=x86_64 --with-platform=efi<br />
* make<br />
* sudo make install<br />
[It will install the files in /usr/local so won't conflict with the installed version]<br />
* sudo mkdir -p /usr/local/etc/default<br />
* Setup an default GRUB entries:<br />
<pre><br />
cat << EOF > /usr/local/etc/default/grub<br />
GRUB_DEFAULT=0<br />
GRUB_TIMEOUT=10<br />
GRUB_CMDLINE_LINUX="console=hvc0 loglevel=8 initcall_debug"<br />
GRUB_CMDLINE_XEN="loglvl=all guest_loglvl=all console=com1,vga com1=115200,8n1"<br />
GRUB_TERMINAL=serial<br />
GRUB_SERIAL_COMMAND="serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1"<br />
EOF<br />
</pre><br />
[This is optional]<br />
* sudo chmod 400 /usr/local/etc/grub.d/10_linux<br />
[This is optional, but this way you will only have Xen entries]<br />
* Script to combine the different grub modules in one EFI file:<br />
<pre><br />
cat << EOF > $HOME/build-grub<br />
#!/bin/bash <br />
<br />
GRUB_MODULES=" all_video boot btrfs cat chain configfile echo \<br />
efifwsetup efinet ext2 fat font gfxmenu gfxterm gzio halt \<br />
hfsplus iso9660 jpeg loadenv loopback lvm mdraid09 mdraid1x \<br />
minicmd normal part_apple part_msdos part_gpt \<br />
password_pbkdf2 png \<br />
reboot search search_fs_uuid search_fs_file search_label \<br />
serial sleep syslinuxcfg test tftp video xfs \<br />
linux backtrace usb usbserial_common \<br />
usbserial_pl2303 usbserial_ftdi usbserial_usbdebug multiboot multiboot2"<br />
<br />
echo $GRUB_MODULES<br />
./grub/grub-mkimage -v -O x86_64-efi -o grub2.efi -p /EFI/grub2 \<br />
-d grub/grub-core ${GRUB_MODULES}<br />
EOF<br />
</pre><br />
* chmod 755 $HOME/build-grub<br />
* $HOME/build-grub<br />
[That creates the grub2.efi with 'multiboot2' support along with other modules]<br />
* sudo mkdir /boot/efi/EFI/grub2<br />
* sudo cp $HOME/grub2.efi /boot/efi/EFI/grub2<br />
* ./grub-mkconfig -o /boot/efi/EFI/grub2/grub.cfg<br />
[Inspect the grub.cfg. Make sure that it has 'multiboot2' and 'module2' for Xen.<br />
You may need the patch titled: <b>[PATCH] Use grub-file to figure out whether multiboot2 should be used for Xen.gz</b><br />
See [https://lists.xen.org/archives/html/xen-devel/2017-03/txtCeHTNmz1hZ.txt]<br />
* sudo efibootmgr -w -L GRUB2 -l "\EFI\grub2\grub2.efi" -c<br />
[To create an EFI boot manager 'GRUB2' entry]<br />
<br />
And you are good to go.<br />
<br />
= Compatibility of Host UEFI Firmware, Xen and UEFI Runtime Services =</div>Rpersaudhttps://wiki.xenproject.org/index.php?title=Design_Sessions_2019&diff=19584Design Sessions 20192019-09-05T01:56:23Z<p>Rpersaud: Add notes for nested virt session</p>
<hr />
<div>= Sessions with published notes =<br />
== Agreeing priorities for the next year ==<br />
<syntaxhighlight><br />
This is an attempt to agree on the top few (we can decide how many) development and <br />
community priorities for the next year. We should only include larger feature <br />
development (that may cover multiple series) with the aim to help code reviewers <br />
to coordinate review time to get these through the review cycle more quickly.<br />
<br />
Attendees are expected to <br />
a) Propose major developments in the works or pipeline <br />
b) Vote / provide input on how important these are<br />
</syntaxhighlight><br />
For notes, see <br />
* https://cryptpad.fr/pad/#/2/pad/edit/GI1eh1isXzpVQ9lLeHrnIp+n/<br />
<br />
== osstest before push to nonrewinding branch - aka Branch management ==<br />
<syntaxhighlight><br />
Right now, if a bad commit (that cause osstest test failures) get pushed to <br />
staging, they get entangled with other work and have to be fixed or reverted. <br />
Most modern CI systems run tests on proposed branches before those branches are <br />
pushed to some shared non-rewinding branch.<br />
<br />
Can we do the same for Xen and osstest ? How ?<br />
</syntaxhighlight><br />
<br />
For notes, see <br />
* https://lists.xenproject.org/archives/html/xen-devel/2019-07/threads.html#00709<br />
<br />
== Build System gripes ==<br />
See https://lists.xenproject.org/archives/html/xen-devel/2019-07/threads.html#00786<br />
<br />
== Further defences for speculative sidechannels ==<br />
<syntaxhighlight><br />
The discovery of speculative sidechannels has undermined a lot of the security <br />
boundaries that software took for granted. Some defences have already been introduced, <br />
but other areas could do with further hardening. Additionally, we should look for <br />
ways to reduce the overheads where possible.<br />
</syntaxhighlight><br />
Notes:<br />
* see https://lists.xenproject.org/archives/html/xen-devel/2019-07/threads.html#00832<br />
<br />
== Xen Toolstacks ==<br />
<syntaxhighlight><br />
At the moment, we have a binary xl, which can be run; and we have libxl, which links <br />
against libxc and various other libraries, which must match 100% the hypervisor version. <br />
We have python and partial golang bindings for some of these libraries, but these may <br />
break and need recompilation when upgrading to a new version of Xen. This session is <br />
to discuss what, if anything, to do as a result of this.<br />
<br />
A couple of options:<br />
<br />
Make a daemon which links against libxl and exposes that functionality in a <br />
backwards-compatible manner<br />
<br />
Make the Xen ABI fully backwards compatible, so that upgrades to Xen will work with <br />
older libraries<br />
</syntaxhighlight><br />
<br />
See <br />
* https://lists.xenproject.org/archives/html/xen-devel/2019-07/threads.html#00789<br />
* https://hackmd.io/0vZaSrKBT2iKWzpVMxDVvQ<br />
<br />
== Xen Distros ==<br />
<syntaxhighlight><br />
Xen is packaged on several different distributions: CentOS, Debian, Fedora, and <br />
Arch. This is an opportunity for distro package maintianers (at minimum George <br />
Dunlap, who maintains the CentOS Xen packages) and distro package users to get <br />
together and talk about best practices and how things can be improved.<br />
</syntaxhighlight><br />
<br />
See <br />
* https://lists.xenproject.org/archives/html/xen-devel/2019-07/threads.html#00791<br />
* https://hackmd.io/vmacVBYbQiORJ9H4_a9Ivw<br />
<br />
== Live Updating Xen == <br />
<syntaxhighlight><br />
Live-Updating Xen is replacing the running Xen hypervisor in-place on a system <br />
without guests noticing.<br />
<br />
This feature does not yet exist - it's very early days to get involved and design <br />
the solution. Following up from the talk on Wednesday, we'll use this slot to talk <br />
about use-cases, how much and what will be of interest to the community, and <br />
design discussions on the feature.<br />
</syntaxhighlight><br />
<br />
For notes, see <br />
* https://cryptpad.fr/pad/#/2/pad/edit/fCwXg1GmSXXG8bc4ridHAsnR/<br />
* https://wiki.xen.org/wiki/Live-Updating_Xen<br />
* https://lists.xenproject.org/archives/html/xen-devel/2019-07/threads.html#00834<br />
<br />
== Nested virtualization ==<br />
<syntaxhighlight><br />
Hardware-assisted nested virtualization is becoming more popular and Xen can be <br />
used in both "L0" and "L1" roles to provide interfaces to open/closed hypervisors <br />
and guest operating systems. This design session will focus on the long-term interfaces <br />
necessary to support performant and secure nesting on modern hardware platforms <br />
and I/O devices.<br />
<br />
Related work and Xen Summit talks:<br />
<br />
Nested VMX/SVM<br />
PV-Shim<br />
Xen Blanket<br />
uXen (Type-2 Xen)<br />
Xendbg and VMI for nested workloads<br />
<br />
</syntaxhighlight><br />
<br />
For notes, see:<br />
* https://lists.gt.net/xen/devel/560973<br />
<br />
<br />
== Virtio ==<br />
<syntaxhighlight><br />
There is an interest on Arm to support virtio on Xen. This would allow us to <br />
leverage existing PV protocols (e.g virgil 3d) and offering an easy way for <br />
users to migrate to Xen.<br />
<br />
The topics expected to be discussed during the sessions are:<br />
<br />
- Transport to be used<br />
- How to prevent backend to access all the guest memory<br />
- Sketch a plan and potential contributors<br />
</syntaxhighlight><br />
For notes, see <br />
* https://lists.xenproject.org/archives/html/xen-devel/2019-07/threads.html#01746<br />
<br />
== Technical debt in the Xen ecosystem (inc libxc/xenstored discussion) ==<br />
<syntaxhighlight><br />
Xen has evolved over time, but there are areas of technical debt which have built <br />
up and are getting in the way.<br />
</syntaxhighlight><br />
For notes, see <br />
* https://hackmd.io/-bCctH_TT4KOy_jF_UIFew<br />
<br />
== Rust and Xen ==<br />
<syntaxhighlight><br />
Discussing the usage of Rust with Xen. Rust is a safe systems language with a <br />
focus on zero-cost abstractions. A low level effort is underway to provide <br />
native bindings to the hypercall ABI to allow native simple recompiling of <br />
Rust programs as unikernels.<br />
</syntaxhighlight><br />
For notes, see <br />
* https://hackmd.io/Bffiwa9BQz2IbIV53h1Q0w<br />
<br />
== Community Issues / Improvements - Communication, Code of Conduct, etc. ==<br />
<syntaxhighlight><br />
This is a session in which a number of community related issues can should be <br />
discussed and agreed, for example<br />
<br />
- Do we need a Code of Conduct?<br />
- How can we make Xen Project more welcoming for newcomers?<br />
- How do we communicate better and more effectively on the mailing list<br />
- Feedback: we don't set expectations very well (e.g. around cover <br />
letters and in other areas)<br />
- We struggle with things such as bikeshedding<br />
- We don't seem to be good at resolving disagreements effectively (even <br />
though we have formal mechanisms in place)<br />
- Frequently communication on xen-devel@ comes across as unfriendly: is there a way <br />
to do this better? We don't have the same issues on IRC<br />
</syntaxhighlight><br />
For notes, see <br />
* Original proposal: https://lists.xenproject.org/archives/html/xen-devel/2019-06/threads.html#01518<br />
* Almost all committers were present<br />
* Agreements<br />
** Agreed to follow the original proposal which intends to split “unacceptable behaviour” from “aspirational ideal”<br />
** Agreed to use the LF Events CoC as a baseline - Action on Lars to draft this: see https://docs.google.com/document/d/1rlNWxfcYjkguavNTWoggZhE22n2bxNAuRBHNHE7oTAU/edit?usp=sharing<br />
** Agreed that this needs to be project wide (at least the CoC)<br />
** Also agreed to name it CoC (rather than something else as originally proposed by Lars)<br />
*** This requires to change language specific to events<br />
** An area for discussion which was not quite agreed upon pending an initial proposal was how we would approach the handling of issues<br />
*** A committee<br />
*** Probably 2-3 people of different backgrounds maybe from different subprojects<br />
*** Hidden by an e-mail alias and have to be people which can respond to issues quickly<br />
<br />
== Documentation improvements ==<br />
For notes, see https://cryptpad.fr/pad/#/2/pad/view/zZT0PWRUP5cLoRhsHVkZ1NknWjS3gM84Ai6oEYntx58/<br />
<br />
== LivePatch improvements and features ==<br />
<syntaxhighlight><br />
Development plans for LivePatch on Xen:<br />
<br />
Support for module parameters<br />
Additional hooks support<br />
Concept of expectations<br />
inline assembly patching<br />
Replaceable apply/revert actions<br />
Fixes and improvements for stacked modules<br />
</syntaxhighlight><br />
For notes, see<br />
* https://lists.xenproject.org/archives/html/xen-devel/2019-07/threads.html#00846<br />
<br />
== A Journey through Unikraft's Build System ==<br />
<syntaxhighlight><br />
The purpose of this session is to give a tutorial on how to write Unikraft Makefiles and <br />
Configuration files. This task is needed when developing or porting applications or libraries <br />
with Unikraft.<br />
</syntaxhighlight><br />
See<br />
* [[File:Unikraft-buildsystem-compressed.pdf]]<br />
<br />
== Dom0 Dissagregation with Unikraft ==<br />
See [[File:XPDDS19- Unikraft-xensummit-design-session-compressed.pdf]]<br />
<br />
= Sessions without published Notes =<br />
<br />
== Exposing hardware-backed CPU timers to limit overhead from Xen's software timers ==<br />
<syntaxhighlight><br />
Problem to Solve<br />
Software-based virtual timers implemented in Xen are a source of overhead and non-determinism <br />
for virtualized applications. For some industries and use cases, these observables effects <br />
prevent Xen from being used - performance guarantees and determinism trump almost all other <br />
matters in some applications.<br />
<br />
Ryan Thibodeaux and Christopher Clark seek to host a design session to discuss a proposal <br />
for exposing hardware-backed CPU timers to guests, with an initial emphasis on Intel CPUs <br />
and Linux guests. The approach considered would selectively expose the local APIC timers <br />
in each Intel CPU core, thereby allowing Linux guests to directly utilize high-resolution <br />
timers in hardware.<br />
<br />
The proposed approach would likely entail a new guest configuration option that would control <br />
access to hardware timers. It is expected that the feature would be available to specific <br />
configurations where side-effects and guest features are limited, e.g., CPU pinned guests <br />
using the NULL scheduler and without migration support.<br />
<br />
Attendee Contributions<br />
Ryan and Christopher seek feedback and guidance from both the Xen and Linux maintainers. <br />
Ryan and Christopher will present an initial approach to expose CPU / hardware-backed <br />
timers (likely including patches for both projects). It is expected that the audience <br />
will review the design concepts and help to identify risks and limitations of this approach.<br />
<br />
Ideally, the design session will conclude with a decision on the feasibility of an <br />
approach to improve timer performance and identify the configuration options to extend <br />
or add in support of this approach.<br />
<br />
Preparation<br />
Ryan Thibodeaux has already submitted a related patch to the Linux kernel project that <br />
allows a guest kernel to change (at boot) the minimum timer resolution in the kernel (see https://github.com/torvalds/linux/commit/2ec16bc0fc7ab544f2d405fd4fdd0d717c5ec0c5). <br />
This mirrors an existing feature in the Xen hypervisor (the "timer_slop" Xen option).<br />
</syntaxhighlight><br />
<br />
== Xen Adventures in Edge Computing ==<br />
<syntaxhighlight><br />
Since Xen's origin in cloud computing, the bare-metal hypervisor has been applied <br />
to desktops, network middleboxes, vehicles, aerospace, accelerator, graphics and <br />
other "edge" applications. Vendors have applied Xen in a range of system architectures, <br />
for performance, security, safety, reliability, power and other axes of optimization.<br />
<br />
In long-lived business workflows at the power-constrained edge, domain-specific Xen <br />
and guest configurations have different priorities than general-purpose Linux <br />
distributions and cloud platforms. As each vendor's product team earns hard-won <br />
platform lessons in their domain, how can reusable knowledge be shared with Xen, <br />
guest and hardware developers in neighboring domains?<br />
<br />
Until now, the answer has been fragmentation of the Xen ecosystem, with Xen Summit <br />
bridging some gaps. Can we borrow from the anti-fragmentation techniques of the <br />
KVM community, including the rust-vmm "building blocks" approach employed by RedHat, <br />
AWS, Google and Intel? Can OSS subsets of code, config, policy, build and test <br />
infrastructures can be shared by multi-domain, Xen-based embedded products?<br />
<br />
If you are working with Xen in unusual applications, this session may be of interest.<br />
</syntaxhighlight><br />
<br />
== Run-time control of Speculative mitigation facilities ==<br />
<syntaxhighlight><br />
Instead of existing "spec-ctrl" boot-time cmdline arguments. To be used together <br />
with Live Microcode update and Live Patching.<br />
</syntaxhighlight><br />
<br />
<br />
== A new book on Xen? ==<br />
<syntaxhighlight><br />
The last book about Xen is more than 10 years old. Let's see if there is interest <br />
for a new book on Xen and if so, what <br />
sort of content should be expected.<br />
</syntaxhighlight><br />
<br />
== Multi-domain build system ==<br />
<syntaxhighlight><br />
There are multiple build systems proposed to already available that target multi-domain <br />
builds suitable for use with Xen hypervisor in embedded systems. Still, at least since <br />
2017, those do not really collaborate and there is no community driven solution exists.<br />
<br />
Some time ago we at EPAM systems had a task to create such a tool for Automotive domain, <br />
that is how our Yocto-based xt-distro appeared.<br />
<br />
After using in development environment xt-distro for some time we started facing some <br />
limitations of our build system, we are thinking about xt-distro v2.0 and would like <br />
to bring as many interested parties into the design and development as possible, so <br />
the whole community benefits. This design session will focus on xt-distro, its <br />
achievements, limitations and ways forward.<br />
</syntaxhighlight><br />
<br />
== Xen hypercall ABI rework ==<br />
<syntaxhighlight><br />
The current hypercall ABI have some issues on Arm that would be warrant for a rework. Some of the issues are:<br />
<br />
- Use of guest virtual address is not safe<br />
- Hypercall taking a guest physical frame rather than a full address (problem with mix page granularity)<br />
- A guest can share a page with Xen and another guest (see XSA-295)<br />
During the session, I would expect collect potential other issues and trying to sketch a new ABI.<br />
</syntaxhighlight><br />
<br />
== Xen on RISC-V ==<br />
<syntaxhighlight><br />
Security increasingly depends on hardware, even as we learn the limits of current platforms. <br />
Open instruction set architectures like RISC-V promise to lower entry costs and accelerate <br />
hardware innovation, while reducing business overhead. Google's silicon root of trust for <br />
cloud, Titan is based on RISC-V.<br />
<br />
The Linux Foundation CHIPS Alliance supports open-source hardware with high-quality silicon <br />
IP, open toolchains and well-verified components. The Open Compute Project (OCP) Open <br />
Domain-Specific Architecture (ODSA) group is defining interfaces to package silicon <br />
"chiplets" from multiple vendors into domain-specific SoCs.<br />
<br />
15 years after inception, the Xen Project stewards a robust, multi-vendor, open-source <br />
ecosystem for bare-metal virtualization software. Is there room for Xen in the future <br />
landscape of heterogenous, open-source hardware, including RISC-V platforms?<br />
<br />
The RISC-V Hypervisor extension specification is progressing along and hopefully there <br />
won't be large breaking changes between the current draft version 0.4 and a frozen specification.<br />
<br />
Western Digital has been developing a QEMU implementation of the RISC-V Hypervisor <br />
extension (based on v0.3) and has ported a baremetal Hypervisor called Xvisor. WDC is <br />
working on a KVM port and has done some work towards a Xen port. WDC and Google are <br />
both members of https://chipsalliance.org.<br />
<br />
Let's discuss how a RISC-V port of Xen can be added to match v0.4 of the evolving <br />
specification. This will need to include a full port of Xen as well as adding support <br />
to use the Hypervisor extensions. This must be done with upstreaming in mind, to ensure <br />
that the RISC-V port will be accepted into mainline Xen, itself a moving target.<br />
<br />
(2017) RISC-V Hypervisor extension, https://content.riscv.org/wp-content/uploads/2017/12/Tue0942-riscv-hypervisor-waterman.pdf<br />
<br />
(2016) QEMU support for RISC-V, https://www.linux-kvm.org/images/6/6a/02x04B-QEMU-Support_for_the_RISC-V_Instruction_Set_Architecture.pdf<br />
<br />
</syntaxhighlight><br />
<br />
[[Category:Developers]]<br />
[[Category:Design Sessions]]<br />
[[Category:Events]]</div>Rpersaudhttps://wiki.xenproject.org/index.php?title=Linux_stub_domains&diff=19427Linux stub domains2019-07-17T22:22:41Z<p>Rpersaud: replace ascii diagram with image</p>
<hr />
<div>Linux stub domains are used in [https://qubes-os.org QubesOS] and [https://OpenXT.org OpenXT].<br />
<br />
* (2018) [https://youtube.com/watch?v=VV0SPxIpka4 Linux-based Device Model Stubdomains in Qubes OS], Marek Marczykowski-Górecki<br />
* (2018) [https://www.slideshare.net/xen_com_mgr/platform-security-summit-18-xen-security-weather-report-2018 Xen Security Weather Report 2018], Lars Kurth<br />
* (2017) [https://www.qubes-os.org/news/2017/10/18/msi-support/ MSI support for PCI device pass-through with stub domains], Simon Gaiser<br />
<br />
== Upstreaming ==<br />
<br />
''todo: add remaining patches''<br />
<br />
00/17 Add support for qemu-xen runnning in a Linux-based stubdomain:<br />
<br />
* Aug 2018, [https://lists.gt.net/xen/devel/524223 v2 patch]<br />
* Jul 2018, [https://lists.gt.net/xen/devel/523516#523516 v1 patch]<br />
<br />
05/17 libxl: Handle Linux stubdomain specific QEMU options:<br />
<br />
* Jan 2019, [https://lists.gt.net/xen/devel/543188 v3 patch]<br />
* Aug 2018, [https://lists.gt.net/xen/devel/524218 v2 patch]<br />
<br />
08/17 xl: add stubdomain related options to xl config parser<br />
<br />
* Jul 2018, [https://lists.gt.net/xen/devel/523881 v1 patch]<br />
<br />
== Interfaces between stubdom QEMU and dom0 ==<br />
<br />
* (June 2019) [https://groups.google.com/forum/m/#!topic/qubes-devel/ga1ToCnXz14 qemu-stubdom<=>dom0 interface changes]<br />
* (June 2019) [https://groups.google.com/forum/m/#!topic/qubes-devel/YrteVv_VyDw Requirements for PVH stubdoms]<br />
<br />
== Xen Summit 2019 Design Session ==<br />
<br />
=== Display architecture proposed by Brendan K ===<br />
<br />
* migrate from display changer on Qubes and OpenXT surfman, to upstream Xen interfaces (from EPAM)<br />
* use Linux 5.1 drm-front driver for displayif<br />
* share common codebase for: EPAM, Qubes, OpenXT, Redfield<br />
<br />
[[File:2019-07-common-linux-stubdom.png]]<br />
<br />
<br />
=== QMP discussion === <br />
<br />
Proposal: <br />
<br />
- LibXL and block backend: change "xenstore stuff" to "QMP stuff"<br />
<br />
Concerns: <br />
<br />
# QMP is not a simple protocol.<br />
# xenstore-based protocol is much simpler than a JSON-encapsulated protocol.<br />
# There have been multiple historical bugs in parsing of JSON in C. <br />
# If we extend QMP support in LibXL and are communicating with a ''potentially compromised'' QEMU process, it would be a security regression.<br />
<br />
Possible mitigations for a ''potentially compromised QEMU''<br />
<br />
# Reduce privileges given to the QEMU instance<br />
# Limit interfaces to the QEMU instance<br />
# Work with upstream QEMU to propose a new safer-than-JSON alternative marshalling format backend<br />
# Minimize what LibXL does with QMP messages: use an off-the-shelf JSON firewall/translator/filter in the untrusted guest, limited to the QEMU subset of JSON<br />
# Don't talk to QEMU after the device is started: mostly done today, but does not work for some corner cases: optical drive insert, device hotplug<br />
# Have an option to intentionally break all QMP communications<br />
<br />
Other notes:<br />
<br />
* Qubes uses dracut for build, OpenXT uses OE<br />
* For OpenXT/Qubes, many QEMU functions can build-time disabled<br />
* For Debian/SuSE distro, the generic QEMU binary has many functions enabled. It may be an option to ship "minimal QEMU" and "minimal kernel" configured binaries for distro stubdoms.<br />
<br />
Actions:<br />
<br />
* Marek to resubmit Linux stubdom patches to xen-devel, ask people to comment on which patches have consensus or open discussion items<br />
* Ian J can review patches in mid-August<br />
* Upstream Xen will merge the ones which are not contended<br />
* Work towards consensus on contended patches</div>Rpersaudhttps://wiki.xenproject.org/index.php?title=File:2019-07-common-linux-stubdom.png&diff=19426File:2019-07-common-linux-stubdom.png2019-07-17T21:42:13Z<p>Rpersaud: </p>
<hr />
<div>== Licensing ==<br />
{{CC-by-sa-3.0}}</div>Rpersaudhttps://wiki.xenproject.org/index.php?title=Linux_stub_domains&diff=19423Linux stub domains2019-07-13T20:09:56Z<p>Rpersaud: /* QMP discussion */</p>
<hr />
<div>Linux stub domains are used in [https://qubes-os.org QubesOS] and [https://OpenXT.org OpenXT].<br />
<br />
* (2018) [https://youtube.com/watch?v=VV0SPxIpka4 Linux-based Device Model Stubdomains in Qubes OS], Marek Marczykowski-Górecki<br />
* (2018) [https://www.slideshare.net/xen_com_mgr/platform-security-summit-18-xen-security-weather-report-2018 Xen Security Weather Report 2018], Lars Kurth<br />
* (2017) [https://www.qubes-os.org/news/2017/10/18/msi-support/ MSI support for PCI device pass-through with stub domains], Simon Gaiser<br />
<br />
== Upstreaming ==<br />
<br />
''todo: add remaining patches''<br />
<br />
00/17 Add support for qemu-xen runnning in a Linux-based stubdomain:<br />
<br />
* Aug 2018, [https://lists.gt.net/xen/devel/524223 v2 patch]<br />
* Jul 2018, [https://lists.gt.net/xen/devel/523516#523516 v1 patch]<br />
<br />
05/17 libxl: Handle Linux stubdomain specific QEMU options:<br />
<br />
* Jan 2019, [https://lists.gt.net/xen/devel/543188 v3 patch]<br />
* Aug 2018, [https://lists.gt.net/xen/devel/524218 v2 patch]<br />
<br />
08/17 xl: add stubdomain related options to xl config parser<br />
<br />
* Jul 2018, [https://lists.gt.net/xen/devel/523881 v1 patch]<br />
<br />
== Interfaces between stubdom QEMU and dom0 ==<br />
<br />
* (June 2019) [https://groups.google.com/forum/m/#!topic/qubes-devel/ga1ToCnXz14 qemu-stubdom<=>dom0 interface changes]<br />
* (June 2019) [https://groups.google.com/forum/m/#!topic/qubes-devel/YrteVv_VyDw Requirements for PVH stubdoms]<br />
<br />
== Xen Summit 2019 Design Session ==<br />
<br />
=== Display architecture proposed by Brendan K ===<br />
<br />
* migrate from display changer on Qubes and OpenXT surfman, to upstream Xen interfaces (from EPAM)<br />
* use Linux 5.1 drm-front driver for displayif<br />
* share common codebase<br />
<br />
+-----------------------------------------------------+<br />
| +-------------------------------------------------+ |<br />
| | | |<br />
| | | |<br />
| | | |<br />
| | +-------+ +---------+ +---------+ +-----+ | |<br />
| | |DRM DCL| | ALSA | | evdev | | qmp | | |<br />
| | +-------+ +---------+ +---------+ QEmu +-----+ | |<br />
| +-------------------------------------------------+ |<br />
| | | | | |<br />
| | | | | |<br />
| +---------+ +---------+ +---------+ +-----------+ |<br />
| | card0 | | ALSA/PA | | evdev | |argo_stream| |<br />
| +---------+ +---------+ +---------+ +-----------+ |<br />
+-----------------------------------------------------+<br />
| +---------+ +---------+ +---------+ +------+ |<br />
| | Xen DRM | | Xen Snd | | Xen KBD | Linux | Xen | |<br />
| | Front | | Front | | Front | Stubdom| Argo | |<br />
| +---------+ +---------+ +---------+ +------+ |<br />
+-----------------------------------------------------+<br />
<br />
=== QMP discussion === <br />
<br />
Proposal: <br />
<br />
- LibXL and block backend: change "xenstore stuff" to "QMP stuff"<br />
<br />
Concerns: <br />
<br />
# QMP is not a simple protocol.<br />
# xenstore-based protocol is much simpler than a JSON-encapsulated protocol.<br />
# There have been multiple historical bugs in parsing of JSON in C. <br />
# If we extend QMP support in LibXL and are communicating with a ''potentially compromised'' QEMU process, it would be a security regression.<br />
<br />
Possible mitigations for a ''potentially compromised QEMU''<br />
<br />
# Reduce privileges given to the QEMU instance<br />
# Limit interfaces to the QEMU instance<br />
# Work with upstream QEMU to propose a new safer-than-JSON alternative marshalling format backend<br />
# Minimize what LibXL does with QMP messages: use an off-the-shelf JSON firewall/translator/filter in the untrusted guest, limited to the QEMU subset of JSON<br />
# Don't talk to QEMU after the device is started: mostly done today, but does not work for some corner cases: optical drive insert, device hotplug<br />
# Have an option to intentionally break all QMP communications<br />
<br />
Other notes:<br />
<br />
* Qubes uses dracut for build, OpenXT uses OE<br />
* For OpenXT/Qubes, many QEMU functions can build-time disabled<br />
* For Debian/SuSE distro, the generic QEMU binary has many functions enabled. It may be an option to ship "minimal QEMU" and "minimal kernel" configured binaries for distro stubdoms.<br />
<br />
Actions:<br />
<br />
* Marek to resubmit Linux stubdom patches to xen-devel, ask people to comment on which patches have consensus or open discussion items<br />
* Ian J can review patches in mid-August<br />
* Upstream Xen will merge the ones which are not contended<br />
* Work towards consensus on contended patches</div>Rpersaudhttps://wiki.xenproject.org/index.php?title=Linux_stub_domains&diff=19422Linux stub domains2019-07-13T20:08:50Z<p>Rpersaud: /* Display architecture proposed by Brendan Kerrigan */</p>
<hr />
<div>Linux stub domains are used in [https://qubes-os.org QubesOS] and [https://OpenXT.org OpenXT].<br />
<br />
* (2018) [https://youtube.com/watch?v=VV0SPxIpka4 Linux-based Device Model Stubdomains in Qubes OS], Marek Marczykowski-Górecki<br />
* (2018) [https://www.slideshare.net/xen_com_mgr/platform-security-summit-18-xen-security-weather-report-2018 Xen Security Weather Report 2018], Lars Kurth<br />
* (2017) [https://www.qubes-os.org/news/2017/10/18/msi-support/ MSI support for PCI device pass-through with stub domains], Simon Gaiser<br />
<br />
== Upstreaming ==<br />
<br />
''todo: add remaining patches''<br />
<br />
00/17 Add support for qemu-xen runnning in a Linux-based stubdomain:<br />
<br />
* Aug 2018, [https://lists.gt.net/xen/devel/524223 v2 patch]<br />
* Jul 2018, [https://lists.gt.net/xen/devel/523516#523516 v1 patch]<br />
<br />
05/17 libxl: Handle Linux stubdomain specific QEMU options:<br />
<br />
* Jan 2019, [https://lists.gt.net/xen/devel/543188 v3 patch]<br />
* Aug 2018, [https://lists.gt.net/xen/devel/524218 v2 patch]<br />
<br />
08/17 xl: add stubdomain related options to xl config parser<br />
<br />
* Jul 2018, [https://lists.gt.net/xen/devel/523881 v1 patch]<br />
<br />
== Interfaces between stubdom QEMU and dom0 ==<br />
<br />
* (June 2019) [https://groups.google.com/forum/m/#!topic/qubes-devel/ga1ToCnXz14 qemu-stubdom<=>dom0 interface changes]<br />
* (June 2019) [https://groups.google.com/forum/m/#!topic/qubes-devel/YrteVv_VyDw Requirements for PVH stubdoms]<br />
<br />
== Xen Summit 2019 Design Session ==<br />
<br />
=== Display architecture proposed by Brendan K ===<br />
<br />
* migrate from display changer on Qubes and OpenXT surfman, to upstream Xen interfaces (from EPAM)<br />
* use Linux 5.1 drm-front driver for displayif<br />
* share common codebase<br />
<br />
+-----------------------------------------------------+<br />
| +-------------------------------------------------+ |<br />
| | | |<br />
| | | |<br />
| | | |<br />
| | +-------+ +---------+ +---------+ +-----+ | |<br />
| | |DRM DCL| | ALSA | | evdev | | qmp | | |<br />
| | +-------+ +---------+ +---------+ QEmu +-----+ | |<br />
| +-------------------------------------------------+ |<br />
| | | | | |<br />
| | | | | |<br />
| +---------+ +---------+ +---------+ +-----------+ |<br />
| | card0 | | ALSA/PA | | evdev | |argo_stream| |<br />
| +---------+ +---------+ +---------+ +-----------+ |<br />
+-----------------------------------------------------+<br />
| +---------+ +---------+ +---------+ +------+ |<br />
| | Xen DRM | | Xen Snd | | Xen KBD | Linux | Xen | |<br />
| | Front | | Front | | Front | Stubdom| Argo | |<br />
| +---------+ +---------+ +---------+ +------+ |<br />
+-----------------------------------------------------+<br />
<br />
=== QMP discussion === <br />
<br />
Proposal: <br />
<br />
- LibXL and block backend: change "xenstore stuff" to "QMP stuff"<br />
<br />
Concerns: <br />
<br />
# QMP is not a simple protocol.<br />
# xenstore-based protocol is much simpler than a JSON-encapsulated protocol.<br />
# There have been multiple historical bugs in parsing of JSON in C. <br />
# If we extend QMP support in LibXL and are communicating with a ''potentially compromised'' QEMU process, it would be a security regression.<br />
<br />
Possible mitigations for a ''potentially compromised QEMU''<br />
<br />
# Reduce privileges given to the QEMU instance<br />
# Limit interfaces to the QEMU instance<br />
# Work with upstream QEMU to propose a new safer-than-JSON alternative marshalling format backend<br />
# Minimize what LibXL does with QMP messages: use an off-the-shelf JSON firewall/translator/filter in the untrusted guest, limited to the QEMU subset of JSON<br />
# Don't talk to QEMU after the device is started: mostly done today, but does not work for some corner cases: optical drive insert, device hotplug<br />
# Have an option to intentionally break all QMP communications<br />
<br />
Other notes:<br />
<br />
* Qubes uses dracut for build, OpenXT uses OE<br />
* For OpenXT/Qubes, many QEMU functions can build-time disabled<br />
* For Debian/SuSE distro, the generic QEMU binary has many functions enabled. It may be an option to ship "minimal QEMU" and "minimal kernel" configured binaries for distro stubdoms.<br />
<br />
Actions:<br />
<br />
* Marek to resubmit Linux stubdom patches to xen-devel, ask people to comment on which patches have consensus or open discussion items<br />
* Ian J can review patches in mid-August<br />
* Upstream Xen to merge the ones which are not contended<br />
* Work towards consensus on contended patches</div>Rpersaudhttps://wiki.xenproject.org/index.php?title=Linux_stub_domains&diff=19421Linux stub domains2019-07-13T19:03:01Z<p>Rpersaud: Add notes from Xen Summit design session</p>
<hr />
<div>Linux stub domains are used in [https://qubes-os.org QubesOS] and [https://OpenXT.org OpenXT].<br />
<br />
* (2018) [https://youtube.com/watch?v=VV0SPxIpka4 Linux-based Device Model Stubdomains in Qubes OS], Marek Marczykowski-Górecki<br />
* (2018) [https://www.slideshare.net/xen_com_mgr/platform-security-summit-18-xen-security-weather-report-2018 Xen Security Weather Report 2018], Lars Kurth<br />
* (2017) [https://www.qubes-os.org/news/2017/10/18/msi-support/ MSI support for PCI device pass-through with stub domains], Simon Gaiser<br />
<br />
== Upstreaming ==<br />
<br />
''todo: add remaining patches''<br />
<br />
00/17 Add support for qemu-xen runnning in a Linux-based stubdomain:<br />
<br />
* Aug 2018, [https://lists.gt.net/xen/devel/524223 v2 patch]<br />
* Jul 2018, [https://lists.gt.net/xen/devel/523516#523516 v1 patch]<br />
<br />
05/17 libxl: Handle Linux stubdomain specific QEMU options:<br />
<br />
* Jan 2019, [https://lists.gt.net/xen/devel/543188 v3 patch]<br />
* Aug 2018, [https://lists.gt.net/xen/devel/524218 v2 patch]<br />
<br />
08/17 xl: add stubdomain related options to xl config parser<br />
<br />
* Jul 2018, [https://lists.gt.net/xen/devel/523881 v1 patch]<br />
<br />
== Interfaces between stubdom QEMU and dom0 ==<br />
<br />
* (June 2019) [https://groups.google.com/forum/m/#!topic/qubes-devel/ga1ToCnXz14 qemu-stubdom<=>dom0 interface changes]<br />
* (June 2019) [https://groups.google.com/forum/m/#!topic/qubes-devel/YrteVv_VyDw Requirements for PVH stubdoms]<br />
<br />
== Xen Summit 2019 Design Session ==<br />
<br />
=== Display architecture proposed by Brendan Kerrigan ===<br />
<br />
* migrate from display changer on Qubes and OpenXT surfman, to upstream Xen interfaces (from EPAM)<br />
* use Linux 5.1 drm-front driver for displayif<br />
* share common codebase<br />
<br />
+-----------------------------------------------------+<br />
| +-------------------------------------------------+ |<br />
| | | |<br />
| | | |<br />
| | | |<br />
| | +-------+ +---------+ +---------+ +-----+ | |<br />
| | |DRM DCL| | ALSA | | evdev | | qmp | | |<br />
| | +-------+ +---------+ +---------+ QEmu +-----+ | |<br />
| +-------------------------------------------------+ |<br />
| | | | | |<br />
| | | | | |<br />
| +---------+ +---------+ +---------+ +-----------+ |<br />
| | card0 | | ALSA/PA | | evdev | |argo_stream| |<br />
| +---------+ +---------+ +---------+ +-----------+ |<br />
+-----------------------------------------------------+<br />
| +---------+ +---------+ +---------+ +------+ |<br />
| | Xen DRM | | Xen Snd | | Xen KBD | Linux | Xen | |<br />
| | Front | | Front | | Front | Stubdom| Argo | |<br />
| +---------+ +---------+ +---------+ +------+ |<br />
+-----------------------------------------------------+<br />
<br />
=== QMP discussion === <br />
<br />
Proposal: <br />
<br />
- LibXL and block backend: change "xenstore stuff" to "QMP stuff"<br />
<br />
Concerns: <br />
<br />
# QMP is not a simple protocol.<br />
# xenstore-based protocol is much simpler than a JSON-encapsulated protocol.<br />
# There have been multiple historical bugs in parsing of JSON in C. <br />
# If we extend QMP support in LibXL and are communicating with a ''potentially compromised'' QEMU process, it would be a security regression.<br />
<br />
Possible mitigations for a ''potentially compromised QEMU''<br />
<br />
# Reduce privileges given to the QEMU instance<br />
# Limit interfaces to the QEMU instance<br />
# Work with upstream QEMU to propose a new safer-than-JSON alternative marshalling format backend<br />
# Minimize what LibXL does with QMP messages: use an off-the-shelf JSON firewall/translator/filter in the untrusted guest, limited to the QEMU subset of JSON<br />
# Don't talk to QEMU after the device is started: mostly done today, but does not work for some corner cases: optical drive insert, device hotplug<br />
# Have an option to intentionally break all QMP communications<br />
<br />
Other notes:<br />
<br />
* Qubes uses dracut for build, OpenXT uses OE<br />
* For OpenXT/Qubes, many QEMU functions can build-time disabled<br />
* For Debian/SuSE distro, the generic QEMU binary has many functions enabled. It may be an option to ship "minimal QEMU" and "minimal kernel" configured binaries for distro stubdoms.<br />
<br />
Actions:<br />
<br />
* Marek to resubmit Linux stubdom patches to xen-devel, ask people to comment on which patches have consensus or open discussion items<br />
* Ian J can review patches in mid-August<br />
* Upstream Xen to merge the ones which are not contended<br />
* Work towards consensus on contended patches</div>Rpersaudhttps://wiki.xenproject.org/index.php?title=Linux_stub_domains&diff=19420Linux stub domains2019-07-13T18:28:03Z<p>Rpersaud: </p>
<hr />
<div>Linux stub domains are used in [https://qubes-os.org QubesOS] and [https://OpenXT.org OpenXT].<br />
<br />
* (2018) [https://youtube.com/watch?v=VV0SPxIpka4 Linux-based Device Model Stubdomains in Qubes OS], Marek Marczykowski-Górecki<br />
* (2018) [https://www.slideshare.net/xen_com_mgr/platform-security-summit-18-xen-security-weather-report-2018 Xen Security Weather Report 2018], Lars Kurth<br />
* (2017) [https://www.qubes-os.org/news/2017/10/18/msi-support/ MSI support for PCI device pass-through with stub domains], Simon Gaiser<br />
<br />
== Upstreaming ==<br />
<br />
''todo: add remaining patches''<br />
<br />
00/17 Add support for qemu-xen runnning in a Linux-based stubdomain:<br />
<br />
* Aug 2018, [https://lists.gt.net/xen/devel/524223 v2 patch]<br />
* Jul 2018, [https://lists.gt.net/xen/devel/523516#523516 v1 patch]<br />
<br />
05/17 libxl: Handle Linux stubdomain specific QEMU options:<br />
<br />
* Jan 2019, [https://lists.gt.net/xen/devel/543188 v3 patch]<br />
* Aug 2018, [https://lists.gt.net/xen/devel/524218 v2 patch]<br />
<br />
08/17 xl: add stubdomain related options to xl config parser<br />
<br />
* Jul 2018, [https://lists.gt.net/xen/devel/523881 v1 patch]<br />
<br />
== Interfaces between stubdom QEMU and dom0 ==<br />
<br />
* (June 2019) [https://groups.google.com/forum/m/#!topic/qubes-devel/ga1ToCnXz14 qemu-stubdom<=>dom0 interface changes]<br />
* (June 2019) [https://groups.google.com/forum/m/#!topic/qubes-devel/YrteVv_VyDw Requirements for PVH stubdoms]<br />
<br />
== Xen Summit 2019 Design Session ==<br />
<br />
''(diagram for architecture proposed by Brendan Kerrigan)''<br />
<br />
+-----------------------------------------------------+<br />
| +-------------------------------------------------+ |<br />
| | | |<br />
| | | |<br />
| | | |<br />
| | +-------+ +---------+ +---------+ +-----+ | |<br />
| | |DRM DCL| | ALSA | | evdev | | qmp | | |<br />
| | +-------+ +---------+ +---------+ QEmu +-----+ | |<br />
| +-------------------------------------------------+ |<br />
| | | | | |<br />
| | | | | |<br />
| +---------+ +---------+ +---------+ +-----------+ |<br />
| | card0 | | ALSA/PA | | evdev | |argo_stream| |<br />
| +---------+ +---------+ +---------+ +-----------+ |<br />
+-----------------------------------------------------+<br />
| +---------+ +---------+ +---------+ +------+ |<br />
| | Xen DRM | | Xen Snd | | Xen KBD | Linux | Xen | |<br />
| | Front | | Front | | Front | Stubdom| Argo | |<br />
| +---------+ +---------+ +---------+ +------+ |<br />
+-----------------------------------------------------+</div>Rpersaudhttps://wiki.xenproject.org/index.php?title=Linux_stub_domains&diff=19419Linux stub domains2019-07-13T18:27:19Z<p>Rpersaud: Add qubes-devel discussion on QMP</p>
<hr />
<div>Linux stub domains are used in [https://qubes-os.org QubesOS] and [https://OpenXT.org OpenXT].<br />
<br />
* (2018) [https://youtube.com/watch?v=VV0SPxIpka4 Linux-based Device Model Stubdomains in Qubes OS], Marek Marczykowski-Górecki<br />
* (2018) [https://www.slideshare.net/xen_com_mgr/platform-security-summit-18-xen-security-weather-report-2018 Xen Security Weather Report 2018], Lars Kurth<br />
* (2017) [https://www.qubes-os.org/news/2017/10/18/msi-support/ MSI support for PCI device pass-through with stub domains], Simon Gaiser<br />
<br />
== Upstreaming ==<br />
<br />
''todo: add remaining patches''<br />
<br />
00/17 Add support for qemu-xen runnning in a Linux-based stubdomain:<br />
<br />
* Aug 2018, [https://lists.gt.net/xen/devel/524223 v2 patch]<br />
* Jul 2018, [https://lists.gt.net/xen/devel/523516#523516 v1 patch]<br />
<br />
05/17 libxl: Handle Linux stubdomain specific QEMU options:<br />
<br />
* Jan 2019, [https://lists.gt.net/xen/devel/543188 v3 patch]<br />
* Aug 2018, [https://lists.gt.net/xen/devel/524218 v2 patch]<br />
<br />
08/17 xl: add stubdomain related options to xl config parser<br />
<br />
* Jul 2018, [https://lists.gt.net/xen/devel/523881 v1 patch]<br />
<br />
== Xen Summit 2019 Design Session ==<br />
<br />
''(diagram for architecture proposed by Brendan Kerrigan)''<br />
<br />
+-----------------------------------------------------+<br />
| +-------------------------------------------------+ |<br />
| | | |<br />
| | | |<br />
| | | |<br />
| | +-------+ +---------+ +---------+ +-----+ | |<br />
| | |DRM DCL| | ALSA | | evdev | | qmp | | |<br />
| | +-------+ +---------+ +---------+ QEmu +-----+ | |<br />
| +-------------------------------------------------+ |<br />
| | | | | |<br />
| | | | | |<br />
| +---------+ +---------+ +---------+ +-----------+ |<br />
| | card0 | | ALSA/PA | | evdev | |argo_stream| |<br />
| +---------+ +---------+ +---------+ +-----------+ |<br />
+-----------------------------------------------------+<br />
| +---------+ +---------+ +---------+ +------+ |<br />
| | Xen DRM | | Xen Snd | | Xen KBD | Linux | Xen | |<br />
| | Front | | Front | | Front | Stubdom| Argo | |<br />
| +---------+ +---------+ +---------+ +------+ |<br />
+-----------------------------------------------------+<br />
<br />
== Interfaces between stubdom QEMU and dom0 ==<br />
<br />
* (June 2019) [https://groups.google.com/forum/m/#!topic/qubes-devel/ga1ToCnXz14 qemu-stubdom<=>dom0 interface changes]<br />
* (June 2019) [https://groups.google.com/forum/m/#!topic/qubes-devel/YrteVv_VyDw Requirements for PVH stubdoms]</div>Rpersaudhttps://wiki.xenproject.org/index.php?title=Linux_stub_domains&diff=19418Linux stub domains2019-07-10T21:52:11Z<p>Rpersaud: diagram for discussion</p>
<hr />
<div>Linux stub domains are used in [https://qubes-os.org QubesOS] and [https://OpenXT.org OpenXT].<br />
<br />
* (2018) [https://youtube.com/watch?v=VV0SPxIpka4 Linux-based Device Model Stubdomains in Qubes OS], Marek Marczykowski-Górecki<br />
* (2018) [https://www.slideshare.net/xen_com_mgr/platform-security-summit-18-xen-security-weather-report-2018 Xen Security Weather Report 2018], Lars Kurth<br />
* (2017) [https://www.qubes-os.org/news/2017/10/18/msi-support/ MSI support for PCI device pass-through with stub domains], Simon Gaiser<br />
<br />
== Upstreaming ==<br />
<br />
''todo: add remaining patches''<br />
<br />
00/17 Add support for qemu-xen runnning in a Linux-based stubdomain:<br />
<br />
* Aug 2018, [https://lists.gt.net/xen/devel/524223 v2 patch]<br />
* Jul 2018, [https://lists.gt.net/xen/devel/523516#523516 v1 patch]<br />
<br />
05/17 libxl: Handle Linux stubdomain specific QEMU options:<br />
<br />
* Jan 2019, [https://lists.gt.net/xen/devel/543188 v3 patch]<br />
* Aug 2018, [https://lists.gt.net/xen/devel/524218 v2 patch]<br />
<br />
08/17 xl: add stubdomain related options to xl config parser<br />
<br />
* Jul 2018, [https://lists.gt.net/xen/devel/523881 v1 patch]<br />
<br />
== Xen Summit 2019 Design Session ==<br />
<br />
''(diagram for architecture proposed by Brendan Kerrigan)''<br />
<br />
+-----------------------------------------------------+<br />
| +-------------------------------------------------+ |<br />
| | | |<br />
| | | |<br />
| | | |<br />
| | +-------+ +---------+ +---------+ +-----+ | |<br />
| | |DRM DCL| | ALSA | | evdev | | qmp | | |<br />
| | +-------+ +---------+ +---------+ QEmu +-----+ | |<br />
| +-------------------------------------------------+ |<br />
| | | | | |<br />
| | | | | |<br />
| +---------+ +---------+ +---------+ +-----------+ |<br />
| | card0 | | ALSA/PA | | evdev | |argo_stream| |<br />
| +---------+ +---------+ +---------+ +-----------+ |<br />
+-----------------------------------------------------+<br />
| +---------+ +---------+ +---------+ +------+ |<br />
| | Xen DRM | | Xen Snd | | Xen KBD | Linux | Xen | |<br />
| | Front | | Front | | Front | Stubdom| Argo | |<br />
| +---------+ +---------+ +---------+ +------+ |<br />
+-----------------------------------------------------+</div>Rpersaudhttps://wiki.xenproject.org/index.php?title=Linux_stub_domains&diff=19408Linux stub domains2019-07-09T20:33:48Z<p>Rpersaud: Upstreaming for Linux stubdoms</p>
<hr />
<div>Linux stub domains are used in [https://qubes-os.org QubesOS] and [https://OpenXT.org OpenXT].<br />
<br />
* (2018) [https://youtube.com/watch?v=VV0SPxIpka4 Linux-based Device Model Stubdomains in Qubes OS], Marek Marczykowski-Górecki<br />
* (2018) [https://www.slideshare.net/xen_com_mgr/platform-security-summit-18-xen-security-weather-report-2018 Xen Security Weather Report 2018], Lars Kurth<br />
* (2017) [https://www.qubes-os.org/news/2017/10/18/msi-support/ MSI support for PCI device pass-through with stub domains], Simon Gaiser<br />
<br />
== Upstreaming ==<br />
<br />
''todo: add remaining patches''<br />
<br />
00/17 Add support for qemu-xen runnning in a Linux-based stubdomain:<br />
<br />
* Aug 2018, [https://lists.gt.net/xen/devel/524223 v2 patch]<br />
* Jul 2018, [https://lists.gt.net/xen/devel/523516#523516 v1 patch]<br />
<br />
05/17 libxl: Handle Linux stubdomain specific QEMU options:<br />
<br />
* Jan 2019, [https://lists.gt.net/xen/devel/543188 v3 patch]<br />
* Aug 2018, [https://lists.gt.net/xen/devel/524218 v2 patch]<br />
<br />
08/17 xl: add stubdomain related options to xl config parser<br />
<br />
* Jul 2018, [https://lists.gt.net/xen/devel/523881 v1 patch]</div>Rpersaudhttps://wiki.xenproject.org/index.php?title=Device_Model_Stub_Domains&diff=19407Device Model Stub Domains2019-07-09T19:55:54Z<p>Rpersaud: /* What Are Device Model Stub Domains? */</p>
<hr />
<div>= What Are Device Model Stub Domains? =<br />
<br />
A stub domain is a specialized system domain running on a Xen host used in order to disaggregate the control domain ("domain 0"). Many stub domains are based on the Mini-OS tiny OS (see <code>extras/mini-os</code> in the Xen source code). Some work has been done on [[Linux stub domains]].<br />
<br />
In the specific case of a device model stub domain this system domain is used to run the Qemu device model associated with an HVM domain. Often the Qemu device model would be a normal process running in the domain 0 environment.<br />
<br />
Device model stub domains were first implemented by Samuel Thibault in Xen 3.3 in 2008.<br />
<br />
= Why Device Model Stub Domains? =<br />
<br />
There are several advantages to running a device model in a stub domain instead of as a process in domain 0.<br />
<br />
* Security <br />
<br />
: A device model stub domain is automatically deprivileged (using <code>XEN_DOMCTL_set_target</code>) such that it only has privilege over the specific HVM domain that it is related to.<br />
<br />
: While a process in domain 0 can be constrained, for example by using SELinux or chroot techniques these are more complex to deploy.<br />
<br />
* Scalability<br />
<br />
: A device model stub domain is not constrained by the resources allocated to the control domain and nor does it contend with other uses of those resources. Instead has its own resources allocated to it.<br />
<br />
* Isolation<br />
<br />
: A stub domain does not contending with other processes in domain 0 (including other device models, control tools, regular user processes) etc. This improves the isolation within the system and ensures e.g. that guest performance is not impacted by load in the control domain.<br />
<br />
* Performance<br />
<br />
: When a device model runs as a process in the control domain it not only has to contend with other processes but is actually subject to double scheduling. That is when it is time for the device model to do some work it has to first wait for the control domain to be scheduled by the hypervisor and then wait for the control domain scheduler to schedule the specific process. Since a stub domain runs only a single process this second schedule is avoided.<br />
<br />
: Running workloads which make extensive use of emulated devices show significant benefits when using a device model stub domain.<br />
<br />
: Even workloads which do not use emulated devices may show benefits e.g. in boot time before switching to non-emulated I/O paths.<br />
<br />
For more information, background and performance numbers on device model stub domains please see Samuel Thibalt's original [http://www.xen.org/files/xensummitboston08/SamThibault_XenSummit.pdf XenSummit presentation] and the associated [http://blog.xen.org/index.php/2008/08/28/xen-33-feature-stub-domains/ blog post].<br />
<br />
= Building The Device Model Stub Domain Binary =<br />
<br />
The device model stub domain is built by default and is normally installed as <code>/usr/lib/xen/boot/ioemu-stubdom.gz</code>.<br />
<br />
If you want to build just the stub domains without building the hypervisor and tools etc then you can use the <code>install-stubdom</code> Makefile target:<br />
<br />
$ make install-stubdom<br />
<br />
= Enabling Device Model Stub Domain For A Guest =<br />
<br />
Using the current <tt>xl</tt> toolstack the a device model stub domain can be enabled for a guest by using the <code>device_model_stubdomain_override</code> option in your guest configuration file:<br />
<br />
device_model_stubdomain_override = 1<br />
<br />
In older toolstacks (<tt>xm/xend</tt> as well as <tt>xl</tt> in Xen 4.1) you can enable a device model stub domain for a guest by specifying the magic string <code>stubdom-dm</code> as your device model:<br />
<br />
device_model = "stubdom-dm"<br />
<br />
If you wish you may freely mix the use of stub domain device model and dom0 process device model on a per domain basis within a single system.<br />
<br />
Note that the frontend drivers in minios are not hardened against malicious backends; so if you are using both device model stub domains and driver domains, the guests with device model stub domains are vulnerable to a malicious driver domain. Of course without a driver domain, the backend runs in dom0 with complete privilege, so driver domains are still a robustness improvement.<br />
<br />
[[Category:Xen]][[Category:Users]][[Category:HowTo]]<br />
[[Category:Security]][[Category:Minios]]</div>Rpersaudhttps://wiki.xenproject.org/index.php?title=Archived/Developer_Meeting/March2019_-_Safety_Certification&diff=19235Archived/Developer Meeting/March2019 - Safety Certification2019-04-03T18:50:46Z<p>Rpersaud: add safety cert category</p>
<hr />
<div>= About the Meeting =<br />
<br />
== Dates ==<br />
March 25 - 26, 2019<br />
Exact agenda TBD, but I expect a 9:00 start and a 17:00 end each day<br />
<br />
== Agenda and Schedule ==<br />
<span style="color:blue"><br />
The evolving agenda can be found at '''[https://docs.google.com/document/d/1aKjxDLkEnPZ_0gHgAv4xy9iPv6hVBkIC_wiA0rZzRms/edit?usp=sharing here]'''<br />
</span><br />
<br />
== Meeting Dates and Location ==<br />
Location: [https://goo.gl/maps/nEZD9DqZ3cQ2 map]<br />
<br />
Citrix Systems<br><br />
101 Cambridge Science Park Rd<br><br />
Cambridge CB4 0FY<br><br />
UK<br />
<br />
== Remote participation ==<br />
We should be able to allow remote participation for some of the meetings, but you need to register, such that we can ensure we can dial you in<br />
<br />
<span style="color:blue"><br />
== Registration (both in person and for remote participation) ==<br />
<span style="color:blue"><br />
Please fill out the following '''[https://docs.google.com/forms/d/e/1FAIpQLSc0WjJIF1t4_KkQobgi40D-nuKycz-h14HAvtfD6Q5SqipO0Q/viewform form]'''<br />
</span><br />
<br />
= Visa Invitation Letters =<br />
Please contact lars dot kurth at citrix dot com to get an invitation letter. Note that it will take 3 business days to generate a letter. Please provide the following information: Name as per passport, Passport No, Date of Birth, Place of birth, Date of passport Issue, Date of passport expiry, Place of passport issue, Expected Arrival Date, Expected Date when you leave the UK<br />
<br />
= Travel Information =<br />
<br />
== Accommodation Options ==<br />
The Citrix office is about 3.5km (a bit more than 2 miles) from Cambridge City centre. The map below gives a rough overview, showing the event location, railway stations and a number of popular hotels.<br />
[[File:CamHotels.jpg|600px]]<br />
=== Orchard Park ===<br />
There are a number of hotels in the Orchard Park area. This is a residential suburb of Cambridge. Hotels are usually less than GBP 50-120 a night. By taxi, it will take you about 8-10 minutes to the office. Walking is possible. If you plan to stay in this area, the best options are<br />
* [https://www.premierinn.com/gb/en/hotels/england/cambridgeshire/cambridge/cambridge-a14-j32.html?cid=GLBC_CAMBAR Premier Inn] (GBP 50)<br />
* [https://www.ihg.com/holidayinn/hotels/gb/en/cambridge/cbgim/hoteldetail Holiday Inn] (GBP 120)<br />
<br />
=== Arbury Road/Chesterton Road ===<br />
There are a number of smaller Bed and Breakfasts and Guest houses in the area, most costing around 80 GBP a night. Some of these are very good (look for ratings above 4.5) and are close enough to the city centre as well as the Citrix office. By taxi, it will take you about 8-10 minutes to the office. Walking is possible.<br />
<br />
=== City Centre ===<br />
There are a number of options in the City Centre. You are looking at around GBP 120-150 per night unless stated otherwise and a 10-15 minute taxi ride to Citrix. If you have not been to Cambridge before, we highly recommend to stay in the city centre.<br />
* [https://www.marriott.co.uk/hotels/travel/cbgak-university-arms-hotel-autograph-collection/ University Arms (Marriott)]<br />
* [https://www.thevarsityhotel.co.uk/ The Varsity]<br />
* [https://www3.hilton.com/en/hotels/united-kingdom/hilton-cambridge-city-centre-STNHCHI/index.html Hilton Cambridge City Centre]<br />
* [https://doubletree3.hilton.com/en/hotels/united-kingdom/doubletree-by-hilton-hotel-cambridge-city-centre-STNCBDI/index.html Doubletree by Hilton]<br />
* [https://www.premierinn.com/gb/en/hotels/england/cambridgeshire/cambridge/cambridge-city-east.html Premier Inn City East] (GBP 60)<br />
<br />
== Travelling to and from Cambridge ==<br />
<br />
=== From London Heathrow ===<br />
* '''Tube and Train:''' Take the tube to Kings Cross (1 hour) and then train to Cambridge (45 mins). The fast train to Cambridge runs every 30 minutes. You will need to buy separate return tickets for the tube (about 5 pounds) and train (about 20 pounds).<br />
* '''Bus:''' There is a direct coach service to Cambridge ([https://www.cambridgeshire.gov.uk/residents/travel-roads-and-parking/buses/bus-timetables/ Jetlink]). This runs every hour and costs 23 pounds. More details are available from [https://www.cambridgeshire.gov.uk/residents/travel-roads-and-parking/buses/bus-timetables/ Jetlink]. Go to stop 18 at Terminal 4, or stop 9 at the central bus station. <br />
* '''Fixed price taxi:''' there are a number of fixed price taxi services which are worth considering. Note that you will have to '''pre-book''':<br />
** [http://www.expressairporttransport.co.uk/Taxi-Cambridge-To-Heathrow-Airport Express Airport Transport (GBP 79)]<br />
** [https://www.twelvetransfers.co.uk/destinations/london-uk-taxi-transfers/taxi-cambridge-heathrow-airport/ Twelve transfers (GBP 99)]<br />
** [https://www.panthertaxis.co.uk/airport-transfer-guide Panther taxis (GBP 110)]<br />
** [https://www.airport-pickups-london.com/Heathrow/taxi-from-heathrow-to-cambridge.asp Airport Pickups (GBP 115)]<br />
<br />
=== From London Gatwick ===<br />
* '''Tube and Train:''' Take the Thameslink train to Kings Cross (1 hour?) and then train to Cambridge (45 mins). The fast train to Cambridge runs every 30 minutes. You should be able to buy a return ticket covering both trains at about 25 pounds. There is a Gatwick express to London Victoria, but this is more expensive and you will need to take the tube from Victoria to Kings Cross.<br />
* '''Bus:''' There is a direct coach service to Cambridge ([https://www.cambridgeshire.gov.uk/residents/travel-roads-and-parking/buses/bus-timetables/ Jetlink]). This runs every hour and costs 30 pounds. More details are available from [https://www.cambridgeshire.gov.uk/residents/travel-roads-and-parking/buses/bus-timetables/ Jetlink]. Go to South Terminal stop 8, or North Terminal stop 3.<br />
* '''Fixed price taxi:'''<br />
** [https://www.twelvetransfers.co.uk/destinations/london-uk-taxi-transfers/taxi-cambridge-gatwick-airport/ Twelve transfers (GBP 119)]<br />
** [https://www.panthertaxis.co.uk/airport-transfer-guide Panther taxis (GBP 135)]<br />
** [https://www.airport-pickups-london.com/Gatwick/taxi-from-gatwick-to-cambridge.asp Airport Pickups (GBP 135)]<br />
<br />
===From London Stansted ===<br />
* '''Train:''' Take the train to Cambridge (45 mins). The cost is 13 pounds.<br />
* '''Bus:''' There is a direct coach service to Cambridge ([https://www.cambridgeshire.gov.uk/residents/travel-roads-and-parking/buses/bus-timetables/ Jetlink]). This runs every hour and costs 11 pounds. More details are available from [https://www.cambridgeshire.gov.uk/residents/travel-roads-and-parking/buses/bus-timetables/ Jetlink]. Go to bay 18.<br />
* '''Fixed price taxi:'''<br />
** [http://www.stanstedairporttaxi.com/ Stansted Airport Taxis (GBP 44)]<br />
** [https://www.panthertaxis.co.uk/airport-transfer-guide Panther taxis (GBP 55)]<br />
<br />
=== From London Luton ===<br />
* '''Bus:'''There is a direct coach service to Cambridge ([https://www.cambridgeshire.gov.uk/residents/travel-roads-and-parking/buses/bus-timetables/ Jetlink]). This runs every hour and costs 13 pounds. More details are available from [https://www.cambridgeshire.gov.uk/residents/travel-roads-and-parking/buses/bus-timetables/ Jetlink]. Go to stop B.<br />
* '''Fixed price taxi:'''<br />
** [https://www.1stairporttaxis.co.uk/taxi-from-luton-airport-to-cambridge.html 1ST Airport Taxis (GBP 57)]<br />
** [https://www.twelvetransfers.co.uk/destinations/london-uk-taxi-transfers/taxi-cambridge-luton-airport/ Twelve transfers (GBP 65)]<br />
** [https://www.panthertaxis.co.uk/airport-transfer-guide Panther taxis (GBP 73)]<br />
<br />
== Getting around in Cambridge ==<br />
Easy ways to get around, depending on your preference are: <br />
* '''Taxi''': with one of the following local providers. Note that '''all local taxi''' providers have an app to book cars and track bookings. For booking phone numbers and further information, see<br />
** [https://www.panthertaxis.co.uk Panther Taxis]<br />
** [http://www.camcab.co.uk/ Cam Cabs]<br />
** [https://www.a1cabco.co.uk A1 CabCo Cabs]<br />
* '''Uber''': is available in Cambridge<br />
* '''Bus''': see [https://www.cambridgeshire.gov.uk/residents/travel-roads-and-parking/buses/bus-timetables/ Jetlink]<br />
* '''Cycle''': see [https://www.visitcambridge.org/things-to-do/on-your-bike/cycle-hire information on cycle hire]<br />
<br />
<br />
[[Category:Community]]<br />
[[Category:Events]]<br />
[[Category:Embedded and Automotive PV Drivers]]<br />
[[Category:Community Meetings]]<br />
[[Category:Safety Certification]]</div>Rpersaudhttps://wiki.xenproject.org/index.php?title=Argo:_Hypervisor-Mediated_Exchange_(HMX)_for_Xen&diff=19091Argo: Hypervisor-Mediated Exchange (HMX) for Xen2019-01-15T21:24:47Z<p>Rpersaud: /* Argo */</p>
<hr />
<div><br />
<br />
== Hypervisor Mediated Exchange (HMX) ==<br />
<br />
The technologies provided by VMMs for communication between VMs have a critical impact on VM isolation properties, on the confidence components can have in the delivery of data and in the integrity of the data that is received. The video below identifies aspects of inter-VM communication system architecture that support important properties that are valuable for building secure systems. Terminology is introduced to enable classification of the existing body of art and survey relevant communication technologies in modern hypervisor, OS and microkernel systems. An example is presented — Argo, an inter-VM communication mechanism developed for the Xen hypervisor — and how it is distinguished from other communication channels on the Xen platform and elsewhere.<br />
<br />
[https://www.platformsecuritysummit.com/2018/speaker/clark/ PSEC 2018 talk by Christopher Clark] (May 2018)<br />
<br />
== V4V (historical) ==<br />
<br />
V4V was created for Citrix XenClient and derivatives are currently deployed in production systems for [https://github.com/openxt OpenXT] and Bromium [https://bromium.com/opensource uXen]. <br />
<br />
* Jean Guyader: [https://lists.xenproject.org/archives/html/xen-devel/2012-05/msg01876.html xen-devel thread on V4V requirements] (May 2012)<br />
* Ross Philipson: [https://lists.xenproject.org/archives/html/xen-devel/2013-05/msg02711.html PATCH (V9) Add V4V to Xen] (May 2013)<br />
<br />
== Argo ==<br />
<br />
Argo is derived from V4V and patches will be submitted to xen-devel in 2018.<br />
<br />
* [[Media:DRAFT_RFC_Argo_and_HMX_2018-06-19-23-45.pdf| v0.1 design documentation for Argo]] (June 2018)<br />
* [https://docs.google.com/document/d/1VUPdWwd1raDOPhjReVVkmb6YoQB3X5oU12E4ExjO1n0/view Minutes of x86 community call] (September 2018)<br />
* [https://lists.xen.org/archives/html/xen-devel/2018-12/msg00005.html v1 patch series] (November 2018)<br />
* [https://lists.xen.org/archives/html/xen-devel/2019-01/msg00310.html v3 patch series] (January 6 2019)<br />
* [https://lists.xenproject.org/archives/html/xen-devel/2019-01/msg01051.html v4 patch series] (January 14, 2019)<br />
<br />
== Related Work ==<br />
<br />
* Xinhua Zhang: [https://www.cs.uic.edu/~xzhang/vchan/ Xen libvchan] (2014)<br />
* Roman Kagan: [http://events17.linuxfoundation.org/sites/events/files/slides/VMBus%20%28Hyper-V%29%20devices%20in%20QEMU%252FKVM_0.pdf VMBus (Hyper-V) devices in QEMU/KVM] (2015)<br />
* Michael S. Tsirkin: [https://www.linux-kvm.org/images/0/03/Virtio_fall_2017.pdf The future of virtio: riddles, myths and surprises] (2017)</div>Rpersaudhttps://wiki.xenproject.org/index.php?title=Argo:_Hypervisor-Mediated_Exchange_(HMX)_for_Xen&diff=19078Argo: Hypervisor-Mediated Exchange (HMX) for Xen2019-01-09T19:10:29Z<p>Rpersaud: /* Argo */</p>
<hr />
<div><br />
<br />
== Hypervisor Mediated Exchange (HMX) ==<br />
<br />
The technologies provided by VMMs for communication between VMs have a critical impact on VM isolation properties, on the confidence components can have in the delivery of data and in the integrity of the data that is received. The video below identifies aspects of inter-VM communication system architecture that support important properties that are valuable for building secure systems. Terminology is introduced to enable classification of the existing body of art and survey relevant communication technologies in modern hypervisor, OS and microkernel systems. An example is presented — Argo, an inter-VM communication mechanism developed for the Xen hypervisor — and how it is distinguished from other communication channels on the Xen platform and elsewhere.<br />
<br />
[https://www.platformsecuritysummit.com/2018/speaker/clark/ PSEC 2018 talk by Christopher Clark] (May 2018)<br />
<br />
== V4V (historical) ==<br />
<br />
V4V was created for Citrix XenClient and derivatives are currently deployed in production systems for [https://github.com/openxt OpenXT] and Bromium [https://bromium.com/opensource uXen]. <br />
<br />
* Jean Guyader: [https://lists.xenproject.org/archives/html/xen-devel/2012-05/msg01876.html xen-devel thread on V4V requirements] (May 2012)<br />
* Ross Philipson: [https://lists.xenproject.org/archives/html/xen-devel/2013-05/msg02711.html PATCH (V9) Add V4V to Xen] (May 2013)<br />
<br />
== Argo ==<br />
<br />
Argo is derived from V4V and patches will be submitted to xen-devel in 2018.<br />
<br />
* [[Media:DRAFT_RFC_Argo_and_HMX_2018-06-19-23-45.pdf| v0.1 design documentation for Argo]] (June 2018)<br />
* [https://docs.google.com/document/d/1VUPdWwd1raDOPhjReVVkmb6YoQB3X5oU12E4ExjO1n0/view Minutes of x86 community call] (September 2018)<br />
* [https://lists.xen.org/archives/html/xen-devel/2018-12/msg00005.html v1 patch series] (November 2018)<br />
* [https://lists.xen.org/archives/html/xen-devel/2019-01/msg00310.html v3 patch series] (January 2019)<br />
<br />
== Related Work ==<br />
<br />
* Xinhua Zhang: [https://www.cs.uic.edu/~xzhang/vchan/ Xen libvchan] (2014)<br />
* Roman Kagan: [http://events17.linuxfoundation.org/sites/events/files/slides/VMBus%20%28Hyper-V%29%20devices%20in%20QEMU%252FKVM_0.pdf VMBus (Hyper-V) devices in QEMU/KVM] (2015)<br />
* Michael S. Tsirkin: [https://www.linux-kvm.org/images/0/03/Virtio_fall_2017.pdf The future of virtio: riddles, myths and surprises] (2017)</div>Rpersaudhttps://wiki.xenproject.org/index.php?title=Argo:_Hypervisor-Mediated_Exchange_(HMX)_for_Xen&diff=19071Argo: Hypervisor-Mediated Exchange (HMX) for Xen2018-12-17T14:27:29Z<p>Rpersaud: </p>
<hr />
<div><br />
<br />
== Hypervisor Mediated Exchange (HMX) ==<br />
<br />
The technologies provided by VMMs for communication between VMs have a critical impact on VM isolation properties, on the confidence components can have in the delivery of data and in the integrity of the data that is received. The video below identifies aspects of inter-VM communication system architecture that support important properties that are valuable for building secure systems. Terminology is introduced to enable classification of the existing body of art and survey relevant communication technologies in modern hypervisor, OS and microkernel systems. An example is presented — Argo, an inter-VM communication mechanism developed for the Xen hypervisor — and how it is distinguished from other communication channels on the Xen platform and elsewhere.<br />
<br />
[https://www.platformsecuritysummit.com/2018/speaker/clark/ PSEC 2018 talk by Christopher Clark] (May 2018)<br />
<br />
== V4V (historical) ==<br />
<br />
V4V was created for Citrix XenClient and derivatives are currently deployed in production systems for [https://github.com/openxt OpenXT] and Bromium [https://bromium.com/opensource uXen]. <br />
<br />
* Jean Guyader: [https://lists.xenproject.org/archives/html/xen-devel/2012-05/msg01876.html xen-devel thread on V4V requirements] (May 2012)<br />
* Ross Philipson: [https://lists.xenproject.org/archives/html/xen-devel/2013-05/msg02711.html PATCH (V9) Add V4V to Xen] (May 2013)<br />
<br />
== Argo ==<br />
<br />
Argo is derived from V4V and patches will be submitted to xen-devel in 2018.<br />
<br />
* [[Media:DRAFT_RFC_Argo_and_HMX_2018-06-19-23-45.pdf| v0.1 design documentation for Argo]] (June 2018)<br />
* [https://docs.google.com/document/d/1VUPdWwd1raDOPhjReVVkmb6YoQB3X5oU12E4ExjO1n0/view Minutes of x86 community call] (September 2018)<br />
* [https://lists.xen.org/archives/html/xen-devel/2018-12/msg00005.html v1 patch series] (November 2018)<br />
<br />
== Related Work ==<br />
<br />
* Xinhua Zhang: [https://www.cs.uic.edu/~xzhang/vchan/ Xen libvchan] (2014)<br />
* Roman Kagan: [http://events17.linuxfoundation.org/sites/events/files/slides/VMBus%20%28Hyper-V%29%20devices%20in%20QEMU%252FKVM_0.pdf VMBus (Hyper-V) devices in QEMU/KVM] (2015)<br />
* Michael S. Tsirkin: [https://www.linux-kvm.org/images/0/03/Virtio_fall_2017.pdf The future of virtio: riddles, myths and surprises] (2017)</div>Rpersaudhttps://wiki.xenproject.org/index.php?title=Characterizing_Vulnerabilities_in_Platform_Security&diff=19020Characterizing Vulnerabilities in Platform Security2018-10-10T20:49:08Z<p>Rpersaud: /* Prior Work Characterizing Vulnerabilities */ add 2 references</p>
<hr />
<div>This article provides some information on works related to characterizing Vulnerabilities within the Xen Project Hypervisor, as well as related projects.<br />
<br />
== Vulnerabilities handled by the Xen Project Security Team ==<br />
=== Vulnerability Scope Boundaries ===<br />
The Xen Project Security Response team follows the project's [https://xenproject.org/security-policy.html Security Response Process] and publishes security issue via [http://xenbits.xen.org/xsa/ xenbits.xen.org/xsa]. Security issues covered by the process include issues within the following vulnerability scope boundaries:<br />
* '''Xen hypervisor''' (see [https://xenbits.xen.org/docs/unstable/support-matrix.html support-matrix] for details)<br />
* '''Hypervisor toolstack(s)''' - e.g. [http://xenbits.xen.org/xsa/advisory-271.html XSA 271], [http://xenbits.xen.org/xsa/advisory-266.html XSA 266]<br />
* '''Linux kernel components affecting Xen''' - e.g. [http://xenbits.xen.org/xsa/advisory-274.html XSA 274], [http://xenbits.xen.org/xsa/advisory-270.html XSA 270],<br />
* '''Hardware vulnerabilities affecting Xen''' - e.g. [http://xenbits.xen.org/xsa/advisory-273.html XSA 273], [http://xenbits.xen.org/xsa/advisory-265.html XSA 265], [http://xenbits.xen.org/xsa/advisory-254.html XSA 254]<br />
* '''Some QEMU components''' (see [https://xenbits.xen.org/docs/unstable/support-matrix.html support-matrix] for details)<br />
<br />
In addition, some vulnerabilities will impact only a subset of Xen versions, a specific architecture (x86 Intel, x86 AMD, Arm 32, Arm 64) or specific configuration and/or virtualization mode (PV, HVM, PVH). Typically products based on Xen will be based on a specific version, subset of features and specific architecture. For example, many Xen based products and services will only support a subset of virtualization modes.<br />
<br />
=== Severity ===<br />
Unlike other open source project, the Xen Project always publishes XSAs for security bugs of low severity. The primary reason for this approach is that there are many different products for very different use-cases, ranging from server virtualisation/cloud computing, to desktop applications (such as Qubes OS), to embedded Xen distributions and that severity cannot usually be determined without considering the specific use-case and context.<br />
<br />
=== CVE Numbers and CVE Publication Dates ===<br />
Note that there is not always a 1-2-1 mapping between CVE numbers and XSAs. Sometimes multiple CVE numbers exist for a single XSA. This typically is the case in the following circumstances:<br />
* When multiple '''Hardware vulnerabilities affecting Xen''' can be addressed by the same mitigation (e.g. [http://xenbits.xen.org/xsa/advisory-273.html XSA 273])<br />
* When '''related attack vectors''' can be addressed by the same mitigation (e.g. [http://xenbits.xen.org/xsa/advisory-201.html XSA 201], [http://xenbits.xen.org/xsa/advisory-218.html XSA 218], [http://xenbits.xen.org/xsa/advisory-196.html XSA 196])<br />
<br />
Note that the mapping of CVE numbers to years may not match the XSA publication dates: this frequently happens towards the end of a calendar year.<br />
<br />
=== CVE databases ===<br />
CVE databases such as [https://www.cvedetails.com CVE Details] will consume vulnerability data published by the Xen Project and publish it under a Xen-specific vendor ID (e.g. [https://www.cvedetails.com/vulnerability-list/vendor_id-6276/XEN.html Xen vendor on CVE Details]). This means that vulnerabilities with very different vulnerability scope boundaries (e.g. Xen Hypervisor, Hypervisor toolstack(s), Linux kernel components affecting Xen, Hardware vulnerabilities affecting Xen, QEMU components) will all be listed under the Xen-specific vendor ID. Manual filtering of vulnerabilities is required when considering a specific scope, use-case or architecture.<br />
<br />
=== Upstreams ===<br />
Security teams of Xen Upstreams (e.g. Linux or QEMU) will notify the Xen Project Security Team of security issues they suspect will impact Xen. However, this usually depends on the wishes of the discoverer of an issue (for example, see [https://wiki.qemu.org/SecurityProcess QEMU Security Process]).<br />
<br />
== Considerations when Characterizing Xen Vulnerabilities or comparing Hypervisors ==<br />
When Characterizing Xen Vulnerabilities it is important to consider the following factors<br />
* Vulnerability Scope Boundaries<br />
* Use-case and Hypervisor Configurations, CPU Architecture and Virtualization modes that may be used<br />
<br />
When comparing Hypervisors (or in general similar software), it is important to note that different Hypervisors have different architectures and different approaches to Software Vulnerability Management. For example, it is common practice amongst many open source software projects to not handle low-severity security issues.<br />
<br />
== Prior Work Characterizing Vulnerabilities ==<br />
* 2012: Nelson Gonzalez, Charles Miers, Fernando Redígolo, Marcos Simplício, Tereza Carvalho, Mats Näslund, Makan Pourzandi - University of São Paulo, Ericsson Research, State University of Santa Catarina, Brazil: [https://link.springer.com/content/pdf/10.1186%2F2192-113X-1-11.pdf A quantitative analysis of current security concerns and solutions for cloud computing]<br />
* 2013: Diego Perez-Botero, Jakub Szefer and Ruby B Lee - Princeton University, Princeton, NJ, USA: [http://palms.ee.princeton.edu/system/files/scc2013.pdf Characterizing Hypervisor Vulnerabilities in Cloud Computing Servers]<br />
* 2016: Haibo Chen - Shanghai Jiao Tong University, China: [http://alchem.usc.edu/ceng-seminar/slides/2016/haibo_chen.pdf Virtualization Security: The Good, The Bad and The Ugly (slides)]<br />
* 2016: Ammarit Thongthua, Sudsanguan Ngamsuriyaroj - Mahidol University, Thailand: [https://ieeexplore.ieee.org/abstract/document/7600180 Assessment of Hypervisor Vulnerabilities]<br />
* 2017: Lei Shi, Yuming Wu, Yubin Xia, Nathan Dautenhahn, Haibo Chen, Binyu Zang, Haibing Guan, Jinming Li - Shanghai Jiao Tong University, China: [https://pdfs.semanticscholar.org/6897/774fa37f13f2d1e4a88c82c626b98fe67951.pdf Deconstructing Xen] ([http://wp.internetsociety.org/ndss/wp-content/uploads/sites/25/2017/09/ndss2017_02a-4_shi_slides.pdf slides]) <br />
<br />
[[Category:Security]]</div>Rpersaudhttps://wiki.xenproject.org/index.php?title=Argo:_Hypervisor-Mediated_Exchange_(HMX)_for_Xen&diff=19007Argo: Hypervisor-Mediated Exchange (HMX) for Xen2018-09-18T20:54:50Z<p>Rpersaud: /* Argo */</p>
<hr />
<div><br />
<br />
== Hypervisor Mediated Exchange (HMX) ==<br />
<br />
The technologies provided by VMMs for communication between VMs have a critical impact on VM isolation properties, on the confidence components can have in the delivery of data and in the integrity of the data that is received. The video below identifies aspects of inter-VM communication system architecture that support important properties that are valuable for building secure systems. Terminology is introduced to enable classification of the existing body of art and survey relevant communication technologies in modern hypervisor, OS and microkernel systems. An example is presented — Argo, an inter-VM communication mechanism developed for the Xen hypervisor — and how it is distinguished from other communication channels on the Xen platform and elsewhere.<br />
<br />
[https://www.platformsecuritysummit.com/2018/speaker/clark/ PSEC 2018 talk by Christopher Clark] (May 2018)<br />
<br />
== V4V (historical) ==<br />
<br />
V4V was created for Citrix XenClient and derivatives are currently deployed in production systems for [https://github.com/openxt OpenXT] and Bromium [https://bromium.com/opensource uXen]. <br />
<br />
* Jean Guyader: [https://lists.xenproject.org/archives/html/xen-devel/2012-05/msg01876.html xen-devel thread on V4V requirements] (May 2012)<br />
* Ross Philipson: [https://lists.xenproject.org/archives/html/xen-devel/2013-05/msg02711.html PATCH (V9) Add V4V to Xen] (May 2013)<br />
<br />
== Argo ==<br />
<br />
Argo is derived from V4V and patches will be submitted to xen-devel in 2018.<br />
<br />
* [[Media:DRAFT_RFC_Argo_and_HMX_2018-06-19-23-45.pdf| v0.1 design documentation for Argo]] (June 2018)<br />
* [https://docs.google.com/document/d/1VUPdWwd1raDOPhjReVVkmb6YoQB3X5oU12E4ExjO1n0/view Minutes of x86 community call] (September 2018)</div>Rpersaudhttps://wiki.xenproject.org/index.php?title=Argo:_Hypervisor-Mediated_Exchange_(HMX)_for_Xen&diff=19006Argo: Hypervisor-Mediated Exchange (HMX) for Xen2018-09-18T20:54:28Z<p>Rpersaud: /* Argo */ add minutes</p>
<hr />
<div><br />
<br />
== Hypervisor Mediated Exchange (HMX) ==<br />
<br />
The technologies provided by VMMs for communication between VMs have a critical impact on VM isolation properties, on the confidence components can have in the delivery of data and in the integrity of the data that is received. The video below identifies aspects of inter-VM communication system architecture that support important properties that are valuable for building secure systems. Terminology is introduced to enable classification of the existing body of art and survey relevant communication technologies in modern hypervisor, OS and microkernel systems. An example is presented — Argo, an inter-VM communication mechanism developed for the Xen hypervisor — and how it is distinguished from other communication channels on the Xen platform and elsewhere.<br />
<br />
[https://www.platformsecuritysummit.com/2018/speaker/clark/ PSEC 2018 talk by Christopher Clark] (May 2018)<br />
<br />
== V4V (historical) ==<br />
<br />
V4V was created for Citrix XenClient and derivatives are currently deployed in production systems for [https://github.com/openxt OpenXT] and Bromium [https://bromium.com/opensource uXen]. <br />
<br />
* Jean Guyader: [https://lists.xenproject.org/archives/html/xen-devel/2012-05/msg01876.html xen-devel thread on V4V requirements] (May 2012)<br />
* Ross Philipson: [https://lists.xenproject.org/archives/html/xen-devel/2013-05/msg02711.html PATCH (V9) Add V4V to Xen] (May 2013)<br />
<br />
== Argo ==<br />
<br />
Argo is derived from V4V and patches will be submitted to xen-devel in 2018.<br />
<br />
* [[Media:DRAFT_RFC_Argo_and_HMX_2018-06-19-23-45.pdf| v0.1 design documentation for Argo]] (June 2018)<br />
* [[https://docs.google.com/document/d/1VUPdWwd1raDOPhjReVVkmb6YoQB3X5oU12E4ExjO1n0/view Minutes of x86 community call]] (September 2018)</div>Rpersaudhttps://wiki.xenproject.org/index.php?title=Argo:_Hypervisor-Mediated_Exchange_(HMX)_for_Xen&diff=18999Argo: Hypervisor-Mediated Exchange (HMX) for Xen2018-09-11T17:38:03Z<p>Rpersaud: </p>
<hr />
<div><br />
<br />
== Hypervisor Mediated Exchange (HMX) ==<br />
<br />
The technologies provided by VMMs for communication between VMs have a critical impact on VM isolation properties, on the confidence components can have in the delivery of data and in the integrity of the data that is received. The video below identifies aspects of inter-VM communication system architecture that support important properties that are valuable for building secure systems. Terminology is introduced to enable classification of the existing body of art and survey relevant communication technologies in modern hypervisor, OS and microkernel systems. An example is presented — Argo, an inter-VM communication mechanism developed for the Xen hypervisor — and how it is distinguished from other communication channels on the Xen platform and elsewhere.<br />
<br />
[https://www.platformsecuritysummit.com/2018/speaker/clark/ PSEC 2018 talk by Christopher Clark] (May 2018)<br />
<br />
== V4V (historical) ==<br />
<br />
V4V was created for Citrix XenClient and derivatives are currently deployed in production systems for [https://github.com/openxt OpenXT] and Bromium [https://bromium.com/opensource uXen]. <br />
<br />
* Jean Guyader: [https://lists.xenproject.org/archives/html/xen-devel/2012-05/msg01876.html xen-devel thread on V4V requirements] (May 2012)<br />
* Ross Philipson: [https://lists.xenproject.org/archives/html/xen-devel/2013-05/msg02711.html PATCH (V9) Add V4V to Xen] (May 2013)<br />
<br />
== Argo ==<br />
<br />
Argo is derived from V4V and patches will be submitted to xen-devel in 2018.<br />
<br />
* [[Media:DRAFT_RFC_Argo_and_HMX_2018-06-19-23-45.pdf| v0.1 design documentation for Argo]] (June 2018)</div>Rpersaudhttps://wiki.xenproject.org/index.php?title=Argo:_Hypervisor-Mediated_Exchange_(HMX)_for_Xen&diff=18998Argo: Hypervisor-Mediated Exchange (HMX) for Xen2018-09-11T17:37:05Z<p>Rpersaud: /* Argo */</p>
<hr />
<div><br />
<br />
== Hypervisor Mediated Exchange (HMX) ==<br />
<br />
The technologies provided by VMMs for communication between VMs have a critical impact on VM isolation properties, on the confidence components can have in the delivery of data and in the integrity of the data that is received. The video below identifies aspects of inter-VM communication system architecture that support important properties that are valuable for building secure systems. Terminology is introduced to enable classification of the existing body of art and survey relevant communication technologies in modern hypervisor, OS and microkernel systems. An example is presented — Argo, an inter-VM communication mechanism developed for the Xen hypervisor — and how it is distinguished from other communication channels on the Xen platform and elsewhere.<br />
<br />
[https://www.platformsecuritysummit.com/2018/speaker/clark/ PSEC 2018 talk by Christopher Clark] (May 2018)<br />
<br />
== V4V ==<br />
<br />
V4V was created for Citrix XenClient and derivatives are currently deployed in production systems for [https://github.com/openxt OpenXT] and Bromium [https://bromium.com/opensource uXen]. <br />
<br />
* Jean Guyader: [https://lists.xenproject.org/archives/html/xen-devel/2012-05/msg01876.html xen-devel thread on V4V requirements] (May 2012)<br />
* Ross Philipson: [https://lists.xenproject.org/archives/html/xen-devel/2013-05/msg02711.html PATCH (V9) Add V4V to Xen] (May 2013)<br />
<br />
== Argo ==<br />
<br />
Argo is derived from V4V and patches will be submitted to xen-devel in 2018.<br />
<br />
* [[Media:DRAFT_RFC_Argo_and_HMX_2018-06-19-23-45.pdf| v0.1 design documentation for Argo]] (June 2018)</div>Rpersaudhttps://wiki.xenproject.org/index.php?title=File:DRAFT_RFC_Argo_and_HMX_2018-06-19-23-45.pdf&diff=18997File:DRAFT RFC Argo and HMX 2018-06-19-23-45.pdf2018-09-11T17:33:51Z<p>Rpersaud: </p>
<hr />
<div>== Licensing ==<br />
{{CC-by-sa-3.0}}</div>Rpersaudhttps://wiki.xenproject.org/index.php?title=Argo:_Hypervisor-Mediated_Exchange_(HMX)_for_Xen&diff=18996Argo: Hypervisor-Mediated Exchange (HMX) for Xen2018-09-11T17:32:27Z<p>Rpersaud: </p>
<hr />
<div><br />
<br />
== Hypervisor Mediated Exchange (HMX) ==<br />
<br />
The technologies provided by VMMs for communication between VMs have a critical impact on VM isolation properties, on the confidence components can have in the delivery of data and in the integrity of the data that is received. The video below identifies aspects of inter-VM communication system architecture that support important properties that are valuable for building secure systems. Terminology is introduced to enable classification of the existing body of art and survey relevant communication technologies in modern hypervisor, OS and microkernel systems. An example is presented — Argo, an inter-VM communication mechanism developed for the Xen hypervisor — and how it is distinguished from other communication channels on the Xen platform and elsewhere.<br />
<br />
[https://www.platformsecuritysummit.com/2018/speaker/clark/ PSEC 2018 talk by Christopher Clark] (May 2018)<br />
<br />
== V4V ==<br />
<br />
V4V was created for Citrix XenClient and derivatives are currently deployed in production systems for [https://github.com/openxt OpenXT] and Bromium [https://bromium.com/opensource uXen]. <br />
<br />
* Jean Guyader: [https://lists.xenproject.org/archives/html/xen-devel/2012-05/msg01876.html xen-devel thread on V4V requirements] (May 2012)<br />
* Ross Philipson: [https://lists.xenproject.org/archives/html/xen-devel/2013-05/msg02711.html PATCH (V9) Add V4V to Xen] (May 2013)<br />
<br />
== Argo ==<br />
<br />
Argo is derived from V4V and patches will be submitted to xen-devel in 2018.<br />
<br />
* [v0.1 design documentation for Argo]</div>Rpersaudhttps://wiki.xenproject.org/index.php?title=Argo:_Hypervisor-Mediated_Exchange_(HMX)_for_Xen&diff=18995Argo: Hypervisor-Mediated Exchange (HMX) for Xen2018-09-11T17:20:04Z<p>Rpersaud: Created page with " == Hypervisor Mediated Exchange (HMX) == The technologies provided by VMMs for communication between VMs have a critical impact on VM isolation properties, on the confidenc..."</p>
<hr />
<div><br />
<br />
== Hypervisor Mediated Exchange (HMX) ==<br />
<br />
The technologies provided by VMMs for communication between VMs have a critical impact on VM isolation properties, on the confidence components can have in the delivery of data and in the integrity of the data that is received. The video below identifies aspects of inter-VM communication system architecture that support important properties that are valuable for building secure systems. Terminology is introduced to enable classification of the existing body of art and survey relevant communication technologies in modern hypervisor, OS and microkernel systems. An example is presented — Argo, an inter-VM communication mechanism developed for the Xen hypervisor — and how it is distinguished from other communication channels on the Xen platform and elsewhere.<br />
<br />
[https://www.platformsecuritysummit.com/2018/speaker/clark/ PSEC 2018 talk by Christopher Clark] (May 2018)<br />
<br />
== V4V ==<br />
<br />
<br />
== Argo ==</div>Rpersaudhttps://wiki.xenproject.org/index.php?title=Inter-domain_communication&diff=18994Inter-domain communication2018-09-11T17:02:51Z<p>Rpersaud: Create IVC umbrella page</p>
<hr />
<div><br />
<br />
* [[Inter-domain communication for XAPI]]<br />
* [[Xen in Qubes OS Security Architecture]]<br />
* [[Argo: Hypervisor-Mediated Exchange (HMX) for Xen]]</div>Rpersaudhttps://wiki.xenproject.org/index.php?title=Category:Security&diff=18993Category:Security2018-09-11T16:58:53Z<p>Rpersaud: </p>
<hr />
<div>[[File:Xen-Panda-Security-500px.jpg|right|100px]]This category contains documents that relate to:<br />
* Security features in Xen<br />
* Security related processes, announcements and procedures<br />
* Projects, products and their architectures that make use of Xen's unique security features<br />
<br />
__NOTOC__<br />
{{Trailbox|Securing Xen|Securing_Xen<br />
|{{Trail|Introductions|<br />
* [[Securing Xen|Securing Xen]]<br />
* [http://www.slideshare.net/xen_com_mgr/a-brief-tutorial-on-xens-advanced-security-features A brief Tutorial on Xen's Advanced Security Features]<br />
* [[Xen FAQ Security|Security FAQ]]<br />
}}|{{Trail|Documentation of Security Features|<br />
* [[Virtual Machine Introspection]]<br />
* [[Device Model Stub Domains]]<br />
* [[Dom0 Disaggregation]]<br />
* [[Driver Domain|Driver Domains]]<br />
* [[StubDom|Stub Domains]]<br />
* [[Storage_driver_domains|Storage Driver Domains]]<br />
* [[Xen Security Modules : XSM-FLASK]]<br />
* [http://xenproject.org/help/presentations-and-videos/video/latest/ccc14-vmi.html Virtual Machine Introspection]<br />
* [http://xenbits.xen.org/docs/unstable/misc/vtpm.txt vTPM]<br />
* [http://xenbits.xen.org/docs/unstable/misc/vtpm-platforms.txt vTPM Examples]<br />
* [http://xenbits.xen.org/docs/unstable/misc/vtpmmgr.txt Operation and CLI of vtpmmgr-stubdom]<br />
}}|{{Trail|Security Announcements and Processes|<br />
* [[Security Announcements]]<br />
* [[Security Vulnerability Process]]<br />
}}<br>{{Trail|Live Patching|<br />
* [[LivePatch|Live Patching]]<br />
* [[:Category:LivePatch|Examples, etc.]]<br />
}}<br><br />
{{Trail|External Coverage|<br />
* [http://www.eweek.com/security/how-xen-manages-security-disclosure.html How Xen Manages Security Disclosure]<br />
* Open Source Security Process<br />
** [http://www.linux.com/news/enterprise/systems-management/863439-open-source-security-process-part-1-a-cloud-security-introduction Part 1]<br />
** [http://www.linux.com/news/enterprise/systems-management/864824-open-source-security-process-part-2-containers-vs-hypervisors-protecting-your-attack-surface Part 2]<br />
** [http://www.linux.com/news/enterprise/systems-management/866433-open-source-security-process-part-3-are-security-practices-robust-enough-in-the-cloud-era Part 3]<br />
** [https://www.linux.com/news/open-source-security-process-part-4-xen-projects-policy-responsible-disclosure-maximum-fairness Part 4]<br />
}}<br />
|{{Trail|Examples of Advanced usage|<br />
* [[Inter-domain communication]]<br />
* [[Xen in Qubes OS Security Architecture]]<br />
* [[Xen in XCP and XenServer "Windsor" Security Architecture|Xen in XAPI/XCP and XenServer "Windsor" Security Architecture]]<br />
* [[Xen in XenClient XT Security Architecture]]<br />
}}<br><br />
{{Trail|Hardware-Assisted Security|<br />
* [[Xen Hardware-Assisted Virtualization Security Overview | Overview]]<br />
* [[Xen and AMD Hardware-Assisted Virtualization Security | AMD]]<br />
* [[Xen and Arm Hardware-Assisted Virtualization Security | Arm]]<br />
* [[Xen and Intel Hardware-Assisted Virtualization Security | Intel]]<br />
}}<br />
}}</div>Rpersaudhttps://wiki.xenproject.org/index.php?title=Automotive_Whitepapers&diff=18816Automotive Whitepapers2018-07-12T12:32:11Z<p>Rpersaud: </p>
<hr />
<div><br />
<br />
<br />
* [[:File:AGL_software_defined_car_jun18.pdf|The Automotive Grade Linux Software Defined Connected Car Architecture]] ''2018-06-18, multiple contributors''<br />
{{Quote|AGL Virtualization Expert Group (EG-VIRT), a team of virtualization professionals active in the AGL community, presents the AGL virtualized software defined vehicle architecture. The objectives of this white paper are: <br />
<br />
● Disseminate automotive virtualization inside and outside AGL <br />
● Identify virtualization use cases, requirements and solutions for AGL <br />
● Define the AGL virtualized software defined vehicle architecture <br />
<br />
EG-VIRT desires to build, connect and combine together open source virtualization solutions around AGL to provide a modular virtualization infrastructure which boosts the creation of innovative advanced driver-assistance systems (ADAS), in-vehicle Infotainment (IVI) and telematics products.}}<br />
<br />
* [[:File:DriverDomainonARM01.pdf|Driver Domain on ARM]] by Andrii Tseglytskyi ''2015-08-06, GlobalLogic''<br />
{{Quote|In the following article I want to describe GlobalLogic’s team experience of bring-up a driver domain on ARM platform. The results that we have achieved with a driver domain were introduced at CES 2015 show and GENIVI event.}}<br />
<br />
* [[:File:RT-Xen on ARM.pdf|RT-Xen on ARM]] by Denys Drozdov ''2015-03-10, GlobalLogic''<br />
{{Quote|The paper analyzes the latency of OS scheduling for symmetric and asymmetric multi-processing support cases – as well as incoming packet handling in Xen – using default credit and real-time schedulers. It also demonstrates how the real-time scheduler affects latency. With RT-Xen support, most of the incoming packets are predictably handled within 1 millisecond with a small overhead at the destined guest OS, which is a feasible time bound for most soft real-time applications.}}<br />
<br />
* [[:File:Device_passthrough_xen.pdf|Device Passthrough to Driver Domain in Xen]] by Yurii Konovalenko ''2015-02-25, GlobalLogic''<br />
{{Quote|As we all know, one of the most common sources of OS crashes are hardware drivers and the issues with them. On systems with visualization, it seems logical to create a separate domain and place hardware drivers (or at least the buggiest of them) there. One of the most significant tasks of creating a system with such a driver domain is to correctly provide it with resources (e.g., IO memory, IRQs). The main idea of passthrough described in the paper is to grant access for DomD through Dom0.}}<br />
<br />
* [[:File:Co-processor_management_under_xen.pdf|Managing coprocessors for Linux PV domains by running a Xen hypervisor on ARM platforms]] by Andrii Tseglytskyi ''2015-01-14, GlobalLogic''<br />
{{Quote|As modern ARM SoCs become faster and faster, they are now capable of performing the same highload tasks that desktop PCs were performing a few years ago, such as HD video playback and highspeed graphic rendering. The structure of an ARM SoC is also now quite complicated. In addition to containing a CPU module or modules, it also includes several peripheral modules (e.g., UARTs, Wireless, HDMI ports, etc.) and coprocessors that are designed to help with highload tasks like Graphic Processor Unit (GPU) or Video Processor Unit (VPU) are assembled together with the main CPU on almost all modern ARM SoCs that are designed for mobile and automotive markets. The article will cover few aspects of sharing such coprocessors when running Xen on embedded SoC.}}<br />
<br />
[[Category:Embedded and Automotive PV Drivers]]<br />
[[Category:OpenEmbedded]]<br />
[[Category:XenARM]]<br />
[[Category:Whitepapers]]</div>Rpersaudhttps://wiki.xenproject.org/index.php?title=File:AGL_software_defined_car_jun18.pdf&diff=18815File:AGL software defined car jun18.pdf2018-07-12T12:25:37Z<p>Rpersaud: Automotive Grade Linux white paper on virtualization architecture.
License: CC-BY-4.0</p>
<hr />
<div>== Summary ==<br />
Automotive Grade Linux white paper on virtualization architecture.<br />
<br />
License: CC-BY-4.0 <br />
== Licensing ==<br />
{{Unknown}}</div>Rpersaudhttps://wiki.xenproject.org/index.php?title=Xen_and_Intel_Hardware-Assisted_Virtualization_Security&diff=18734Xen and Intel Hardware-Assisted Virtualization Security2018-05-15T01:32:01Z<p>Rpersaud: /* Intel Trusted Execution Technology (TXT) - DRTM */</p>
<hr />
<div><br />
<br />
== Intel Software Guard Extensions (SGX) - Secure Enclave ==<br />
<br />
- [https://github.com/intel/xen-sgx/wiki Preliminary patches]<br />
- ITL thoughts on SGX: [http://theinvisiblethings.blogspot.com/2013/08/thoughts-on-intels-upcoming-software.html part1] &middot; [http://theinvisiblethings.blogspot.com/2013/09/thoughts-on-intels-upcoming-software.html part2] (2013)<br />
- Intel [https://www.slideshare.net/mobile/xen_com_mgr/xpdds17-introduction-to-intel-sgx-and-sgx-virtualization-kai-huang-intel slides] &middot; [https://youtube.com/watch?v=oES6hRhLJRM video] (2017)<br />
<br />
== Intel Trusted Execution Technology (TXT) - DRTM ==<br />
<br />
- Intel [https://web.archive.org/web/20140611161423/http://www-archive.xenproject.org/files/xensummit_fall07/23_JosephCihula.pdf Verifying the Xen launch] (2007)<br />
- Intel [https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/trusted-execution-technology-security-paper.pdf White paper] (2012) &middot; [https://downloadmirror.intel.com/18931/eng/Intel%20TXT%20LAB%20Handout.pdf Lab handout] (2010) &middot; [https://www.amazon.com/Dynamics-Trusted-Platform-Buildin/dp/1934053082 Book] (2009)<br />
- Qubes [http://theinvisiblethings.blogspot.com/2011/09/anti-evil-maid.html Anti Evil Maid] (2011)<br />
- [https://digital.library.unt.edu/ark:/67531/metadc804971/ Secure policy engine in hypervisor] (2015)<br />
- [https://www.linux.com/blog/event/elce/2017/10/device-we-trust-measure-twice-compute-once-xen-linux-tpm-20-and-txt TXT measured launch with TPM 2.0 and OTA update] (2017)</div>Rpersaudhttps://wiki.xenproject.org/index.php?title=Xen_and_Intel_Hardware-Assisted_Virtualization_Security&diff=18733Xen and Intel Hardware-Assisted Virtualization Security2018-05-15T01:05:24Z<p>Rpersaud: /* Intel Trusted Execution Technology (TXT) - DRTM */</p>
<hr />
<div><br />
<br />
== Intel Software Guard Extensions (SGX) - Secure Enclave ==<br />
<br />
- [https://github.com/intel/xen-sgx/wiki Preliminary patches]<br />
- ITL thoughts on SGX: [http://theinvisiblethings.blogspot.com/2013/08/thoughts-on-intels-upcoming-software.html part1] &middot; [http://theinvisiblethings.blogspot.com/2013/09/thoughts-on-intels-upcoming-software.html part2] (2013)<br />
- Intel [https://www.slideshare.net/mobile/xen_com_mgr/xpdds17-introduction-to-intel-sgx-and-sgx-virtualization-kai-huang-intel slides] &middot; [https://youtube.com/watch?v=oES6hRhLJRM video] (2017)<br />
<br />
== Intel Trusted Execution Technology (TXT) - DRTM ==<br />
<br />
- Intel [https://web.archive.org/web/20140611161423/http://www-archive.xenproject.org/files/xensummit_fall07/23_JosephCihula.pdf Verifying the Xen launch] (2007)<br />
- Qubes [http://theinvisiblethings.blogspot.com/2011/09/anti-evil-maid.html Anti Evil Maid] (2011)<br />
- [https://digital.library.unt.edu/ark:/67531/metadc804971/ Secure policy engine in hypervisor] (2015)<br />
- [https://www.linux.com/blog/event/elce/2017/10/device-we-trust-measure-twice-compute-once-xen-linux-tpm-20-and-txt TXT measured launch with TPM 2.0 and OTA update] (2017)</div>Rpersaudhttps://wiki.xenproject.org/index.php?title=Xen_and_Intel_Hardware-Assisted_Virtualization_Security&diff=18732Xen and Intel Hardware-Assisted Virtualization Security2018-05-15T01:03:19Z<p>Rpersaud: initial version</p>
<hr />
<div><br />
<br />
== Intel Software Guard Extensions (SGX) - Secure Enclave ==<br />
<br />
- [https://github.com/intel/xen-sgx/wiki Preliminary patches]<br />
- ITL thoughts on SGX: [http://theinvisiblethings.blogspot.com/2013/08/thoughts-on-intels-upcoming-software.html part1] &middot; [http://theinvisiblethings.blogspot.com/2013/09/thoughts-on-intels-upcoming-software.html part2] (2013)<br />
- Intel [https://www.slideshare.net/mobile/xen_com_mgr/xpdds17-introduction-to-intel-sgx-and-sgx-virtualization-kai-huang-intel slides] &middot; [https://youtube.com/watch?v=oES6hRhLJRM video] (2017)<br />
<br />
== Intel Trusted Execution Technology (TXT) - DRTM ==<br />
<br />
- [https://web.archive.org/web/20140611161423/http://www-archive.xenproject.org/files/xensummit_fall07/23_JosephCihula.pdf Verifying the Xen launch] (2007)<br />
- [http://theinvisiblethings.blogspot.com/2011/09/anti-evil-maid.html Anti Evil Maid] (2011)<br />
- [https://digital.library.unt.edu/ark:/67531/metadc804971/ Secure policy engine in hypervisor] (2015)<br />
- [https://www.linux.com/blog/event/elce/2017/10/device-we-trust-measure-twice-compute-once-xen-linux-tpm-20-and-txt TXT measured launch with TPM 2.0 and OTA update] (2017)</div>Rpersaudhttps://wiki.xenproject.org/index.php?title=Category:Security&diff=18731Category:Security2018-05-14T23:09:57Z<p>Rpersaud: Index to future hardware-assisted security pages</p>
<hr />
<div>[[File:Xen-Panda-Security-500px.jpg|right|100px]]This category contains documents that relate to:<br />
* Security features in Xen<br />
* Security related processes, announcements and procedures<br />
* Projects, products and their architectures that make use of Xen's unique security features<br />
<br />
__NOTOC__<br />
{{Trailbox|Securing Xen|Securing_Xen<br />
|{{Trail|Introductions|<br />
* [[Securing Xen|Securing Xen]]<br />
* [http://www.slideshare.net/xen_com_mgr/a-brief-tutorial-on-xens-advanced-security-features A brief Tutorial on Xen's Advanced Security Features]<br />
* [[Xen FAQ Security|Security FAQ]]<br />
}}|{{Trail|Documentation of Security Features|<br />
* [[Virtual Machine Introspection]]<br />
* [[Device Model Stub Domains]]<br />
* [[Dom0 Disaggregation]]<br />
* [[Driver Domain|Driver Domains]]<br />
* [[StubDom|Stub Domains]]<br />
* [[Storage_driver_domains|Storage Driver Domains]]<br />
* [[Xen Security Modules : XSM-FLASK]]<br />
* [http://xenproject.org/help/presentations-and-videos/video/latest/ccc14-vmi.html Virtual Machine Introspection]<br />
* [http://xenbits.xen.org/docs/unstable/misc/vtpm.txt vTPM]<br />
* [http://xenbits.xen.org/docs/unstable/misc/vtpm-platforms.txt vTPM Examples]<br />
* [http://xenbits.xen.org/docs/unstable/misc/vtpmmgr.txt Operation and CLI of vtpmmgr-stubdom]<br />
}}|{{Trail|Security Announcements and Processes|<br />
* [[Security Announcements]]<br />
* [[Security Vulnerability Process]]<br />
}}<br>{{Trail|Live Patching|<br />
* [[LivePatch|Live Patching]]<br />
* [[:Category:LivePatch|Examples, etc.]]<br />
}}<br><br />
{{Trail|External Coverage|<br />
* [http://www.eweek.com/security/how-xen-manages-security-disclosure.html How Xen Manages Security Disclosure]<br />
* Open Source Security Process<br />
** [http://www.linux.com/news/enterprise/systems-management/863439-open-source-security-process-part-1-a-cloud-security-introduction Part 1]<br />
** [http://www.linux.com/news/enterprise/systems-management/864824-open-source-security-process-part-2-containers-vs-hypervisors-protecting-your-attack-surface Part 2]<br />
** [http://www.linux.com/news/enterprise/systems-management/866433-open-source-security-process-part-3-are-security-practices-robust-enough-in-the-cloud-era Part 3]<br />
** [https://www.linux.com/news/open-source-security-process-part-4-xen-projects-policy-responsible-disclosure-maximum-fairness Part 4]<br />
}}<br />
|{{Trail|Examples of Advanced usage|<br />
* [[Inter-domain communication for XCP|Inter-domain communication for XAPI]]<br />
* [[Xen in Qubes OS Security Architecture]]<br />
* [[Xen in XCP and XenServer "Windsor" Security Architecture|Xen in XAPI/XCP and XenServer "Windsor" Security Architecture]]<br />
* [[Xen in XenClient XT Security Architecture]]<br />
}}<br><br />
{{Trail|Hardware-Assisted Security|<br />
* [[Xen Hardware-Assisted Virtualization Security Overview | Overview]]<br />
* [[Xen and AMD Hardware-Assisted Virtualization Security | AMD]]<br />
* [[Xen and Arm Hardware-Assisted Virtualization Security | Arm]]<br />
* [[Xen and Intel Hardware-Assisted Virtualization Security | Intel]]<br />
}}<br />
}}</div>Rpersaudhttps://wiki.xenproject.org/index.php?title=Category:OpenEmbedded&diff=18622Category:OpenEmbedded2018-02-19T18:19:44Z<p>Rpersaud: </p>
<hr />
<div>https://upload.wikimedia.org/wikipedia/commons/1/1f/Oe-logo.png<br />
<br />
<br />
[https://openembedded.org OpenEmbedded] provides a cross-compile environment to create custom Linux-based systems for ARM and x86 hardware devices. Since 2012, it has supported building Xen via the [https://layers.openembedded.org/layerindex/branch/master/layer/meta-virtualization/ meta-virtualization] layer which also supports libvirt, KVM and containers.<br />
<br />
== OE Resources ==<br />
<br />
* Yocto: [https://www.yoctoproject.org/sites/default/files/ypdd-2016.04-san_diego_1.pdf Introduction (2016)] – [http://elinux.org/images/a/a8/Getting_Started_with_Embedded_Linux-_Using_the_Yocto_Project_to_Build_your_Own_Custom_Embedded_Linux_Distribution.pdf Ecosystem (2015)] – [http://free-electrons.com/doc/training/yocto/yocto-slides.pdf Training (2017)]<br />
* Bitbake: [https://a4z.bitbucket.io/docs/BitBake/guide.html guide (2016)] – [http://www.yoctoproject.org/docs/2.3.1/bitbake-user-manual/bitbake-user-manual.html manual (2017)]<br />
* OE meta-virtualization [https://lists.yoctoproject.org/pipermail/meta-virtualization/ mailing list]<br />
* Automotive Grade Linux [https://wiki.automotivelinux.org/eg-virt Virtualization Expert Group]<br />
<br />
== OE+Xen Tutorials ==<br />
<br />
* [https://www.mail-archive.com/xen-devel@lists.xen.org/msg114825.html Build tools for Xen and OpenEmbedded], Oleksandr Andrushchenko, EPAM (2017)<br />
* [http://linux.globallogic.com/materials/presentations/Stream%201/Roman%20Shaposhnikov-%20How%20to%20create%20and%20support%20your%20own%20embedded%20Linux%20distro.pdf How to create and support your own embedded Linux distro], Roman Shaposhnikov, Global Logic (2017)<br />
* [https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/linux-customizing-thin-clients-yocto-project-white-paper.pdf Customizing a Linux OS for Thin Clients using Intel BSPs and the Yocto Project], Intel (2016)<br />
* [https://twobit.us/2013/11/openembedded-xen-network-driver-vm/ OpenEmbedded Xen Network Driver VM] (2013)<br />
<br />
== Presentations ==<br />
<br />
* Xen and the Art of Embedded Systems Virtualization, Stefano Stabellini: [https://youtube.com/watch?v=GYb-Qn3KAUM video], [https://www.slideshare.net/mobile/StefanoStabellini/xen-and-the-art-of-embedded-virtualization-elc-2017 slides] (2017)<br />
* OpenXT: Xen and OpenEmbedded on x86, Christopher Clark: [https://m.youtube.com/watch?v=nP-j_4K0T_0 video], [http://schd.ws/hosted_files/xensummit2016/c4/The%20OpenXT%20Project%20in%202016%20-%20Xen%20Developer%20Summit%20-%20Christopher%20Clark.pdf slides] (2016)<br />
* Xen Automotive, Alex Agizim: [http://events.linuxfoundation.org/sites/events/files/slides/Xen%20Automotive%20RC1.pdf slides] (2014)<br />
<br />
== Projects/Products using Xen and OpenEmbedded ==<br />
<br />
* [http://dornerworks.com/xen/xilinxxen DornerWorks]<br />
* [https://epam.com EPAM] [https://github.com/xen-troops xen-troops]<br />
* [https://cdn10.globallogic.com/wp-content/uploads/2016/12/GlobalLogic-Nautilus-Platform.pdf Global Logic Nautilus]<br />
* [http://openxt.org/history/ OpenXT]<br />
* [https://starlab.io/products/crucible/ Star Lab Crucible]<br />
* [http://www.wiki.xilinx.com/XEN+Hypervisor Xilinx]<br />
<br />
[[Category:Yocto]]<br />
[[Category:Embedded]]<br />
[[Category:XenARM]]</div>Rpersaudhttps://wiki.xenproject.org/index.php?title=Xen_ARM_with_Virtualization_Extensions_whitepaper&diff=18621Xen ARM with Virtualization Extensions whitepaper2018-02-19T18:17:34Z<p>Rpersaud: </p>
<hr />
<div>= Xen on ARM =<br />
<br />
== What is Xen? ==<br />
[http://www.xenproject.org/developers/teams/hypervisor.html Xen] is a lightweight, high performance, Open Source hypervisor. Xen has a very low footprint: the ARM port amounts to less than 90K lines of code. Xen is licensed [http://www.gnu.org/licenses/gpl-2.0.html GPLv2] and has an healthy and diverse community that supports it and funds its development. Xen is hosted by the [http://www.xenproject.org LinuxFoundation], that provides [http://www.xenproject.org/join.html stewardship] for the project.<br />
<br />
== The Xen Architecture ==<br />
Xen is type-1 hypervisor: it runs directly on the hardware, everything else in the system is running as a virtual machine on top of Xen, including Dom0, the first virtual machine. Dom0 is created by Xen, is privileged and drives the devices on the platform.<br />
Xen virtualizes CPU, memory, interrupts and timers, providing virtual machines with one or more virtual CPUs, a fraction of the memory of the system, a virtual interrupt controller and a virtual timer. Xen assigns devices such as SATA controllers and network cards to Dom0, taking care of remapping MMIO regions and IRQs. Dom0 (typically Linux, but it could also be FreeBSD or other operating systems) runs the same device drivers for these devices that would be using on a native execution.<br />
<br />
Dom0 also runs a set of drivers called ''paravirtualized backends'' to give access to disk, network, etc, to the other unprivileged virtual machines. The operating system running as DomU (unprivileged guest in Xen terminology) gets access to a set of generic virtual devices by running the corresponding ''paravirtualized frontend'' drivers. A single backend services multiple frontends. A pair of paravirtualized drivers exist for all the most common classes of devices: disk, network, console, framebuffer, mouse, keyboard, etc. They usually live in the operating system kernel, i.e. Linux. A few PV backends can also run in userspace in QEMU. The frontends connect to the backends using a simple ring protocol over a shared page in memory. Xen provides all the tools for discovery and to setup the initial communication. Xen also provides a mechanism for the frontend and the backend to share additional pages and notify each other via software interrupts.<br />
[[File:Xen arch1.png|600px|center|frameless]]<br />
<br />
Even though it is the most common configuration, there is no reasons to run all the device drivers and all the paravirtualized backends in Dom0. The Xen architecture allows ''driver domains'': unprivileged virtual machines with the only purpose of running the driver and the paravirtualized backend for one class of devices. For example you can have a disk driver domain, with the SATA controller assigned, running the driver for it and the disk paravirtualized backend. You can have a network driver domain with the network card assigned, running the driver for it and the network paravirtualized backend. As driver domains are regular unprivileged guests, they make the system more ''secure'' because they allow large pieces of code, such as the entire network stack, to run unprivileged. Even if a malicious guest manages to take over the paravirtualized network backend and the network driver domain, it would not be able to take over the entire system. Driver domains also improve ''isolation'' and ''resilience'': the network driver domain is fully isolated from the disk driver domains and Dom0. If the network driver crashes it would not be able to take down the entire system, only the network. It is possible to reboot just the network driver domains while everything else remains online.<br />
Finally driver domains allow Xen users to ''disaggregate'' and ''componentize'' the system in ways that would not be possible otherwise. For example they allow users to run a real-time operating system alongside the main OS to drive a device that has real time constraints. They allow users to run a legacy OS to drive old devices that do not have any new drivers in modern operating systems. They allow users to separate and isolate critical functionalities from less critical ones. For example they allow to run an OS such as QNX to drive most devices on the platform alongside Android for the user interface.<br />
[[File:Xen arch2.png|630px|center|frameless]]<br />
<br />
== Xen on ARM: a cleaner architecture ==<br />
Xen on ARM is not just a straight 1:1 port of x86 Xen. We exploited the opportunity to clean up the architecture and get rid of the cruft that we accumulated during the many years of x86 development. Firstly ''we removed any need for emulation''. Emulated interfaces are slow and insecure. QEMU, used for emulation on x86 Xen, is a well maintained Open Source project but is big both in terms of binary size and lines of source code. ''The smaller, the simpler, the better''. Xen on ARM does not need QEMU because it does not do any emulation. It accomplishes the goal by exploiting virtualization support in hardware as much as possible and using paravirtualized interfaces for IO. As a result Xen on ARM is faster and more secure.<br />
<br />
On x86 two different kinds of Xen guest coexist: PV guests, such as Linux and other Open Source OSes, and HVM guests, usually Microsoft Windows, but any OS can run as HVM guest. PV and HVM guests are quite different from the hypervisor point of view. The difference is exposed all the way up to the user, that needs to choose how to run the guest by setting a line in the VM config file. On ARM we did not want to introduce this differentiation: we felt that it is artificial and confusing. ''Xen on ARM only supports one kind of guest that is the best of both worlds'': it does not need any emulation and relies on paravirtualized interfaces for IO as early as possible in the boot sequence, like x86 PV guests. It exploits virtualization support in hardware as much as possible and does not require invasive changes to the guest operating system kernel in order to run, like x86 HVM guests.<br />
<br />
''The new architecture designed for Xen on ARM is much cleaner and simpler and it turned out to be a very good match for the hardware''.<br />
<br />
== Xen on ARM: virtualization extensions ==<br />
ARM virtualization extensions provide 3 levels of execution: EL0, user mode, EL1, kernel mode, and EL2, hypervisor mode. They introduce a new instruction, HVC, to switch between kernel mode and hypervisor mode. The MMU supports 2 stages of translation. The generic timers and the GIC interrupt controller are virtualization aware.<br />
[[File:Xen arm arch1.png|750px|center|frameless]]<br />
ARM virtualization extensions are a great fit for the Xen architecture:<br />
* Xen runs entirely and only in hypervisor mode <br />Xen leaves kernel mode for the guest operating system kernel and EL0 for guest user space applications. Type-2 hypervisors need to frequently switch between hypervisor mode and kernel mode. By running entirely in EL2 Xen significantly reduces the number of context switches required. <br />
* HVC, the new instruction, is used by the kernel to issue hypercalls to Xen<br />
* Xen uses 2-stage translation in the MMU to assign memory to virtual machines<br />
* Xen uses generic timers to receive timer interrupts as well as injecting timer interrupts and exposing the counter to virtual machines<br />
* Xen uses the GIC to receive interrupts as well as injecting interrupts into guests<br />
[[File:Xen arm arch2.png|750px|center|frameless]]<br />
Xen discovers the hardware via device tree. It assigns all the devices that it does not use to Dom0 by remapping the corresponding MMIO regions and interrupts. It generates a flatten device tree binary for Dom0 that describes exactly the environment exposed to it. Dom0's device tree contains:<br />
* the exact number of virtual cpus that Xen created for it (maybe less than the number of physical cpus on the platform)<br />
* the exact amount of memory that Xen gave to it (surely less than the amount of physical memory available)<br />
* the devices that Xen re-assigned to it and no more (not all devices are assigned to Dom0, at the very least one UART is not)<br />
* an hypervisor node to advertise the presence of Xen on the platform<br />
Dom0 boots exactly the same way it would boot natively. By using device tree to discover the hardware, Dom0 finds out what is available and loads the drivers for it. It does not try to access interfaces that are not present and therefore ''Xen does not need to do any emulation''. By finding the Xen hypervisor node, Dom0 knows that it is running on Xen and therefore can initialize the paravirtualized backends. Other DomUs would load the paravirtualized frontends instead.<br />
<br />
== Xen on ARM: code size ==<br />
We wrote previously that the new architecture turned out to be a very good match for the hardware. This is proven by the code size: the smaller the better. ''Xen on ARM is 1/6 of the code size of x86_64 Xen'', while still providing a similar level of features.<br />
In Xen 4.4.0:<br />
{| class="wikitable" style="margin-left: auto; margin-right: auto; text-align: center; border-color: black; border-style: solid; border-width: 1px 1px 1px 1px; padding: 5;"<br />
|-<br />
|style="background-color:LightBlue;"|<br />
|style="background-color:LightBlue;"|Common<br />
|style="background-color:LightBlue;"|ARMv7<br />
|style="background-color:LightBlue;"|ARMv8<br />
|style="background-color:LightBlue;"|Total<br />
|-<br />
|style="text-align:left;"|xen/arch/arm<br />
|11,767<br />
|3,503<br />
|1,812<br />
|17,082<br />
|-<br />
|style="text-align:center;"|C<br />
|11,587<br />
|954<br />
|813<br />
|13,354<br />
|-<br />
|style="text-align:center;"|ASM<br />
|180<br />
|2,549<br />
|999<br />
|3,728<br />
|-<br />
|style="text-align:left;"|xen/include/asm-arm<br />
|4,786<br />
|984<br />
|1,050<br />
|6,820<br />
|-<br />
|style="background-color:LightBlue; text-align:left;"|Total ARM<br />
|style="background-color:LightBlue;"|16,553<br />
|style="background-color:LightBlue;"|4,487<br />
|style="background-color:LightBlue;"|2,862<br />
|style="background-color:LightBlue;"|23,902<br />
|-<br />
|colspan="4" style="background-color:Tomato; text-align:center;"|x86_64<br />
|style="background-color:Tomato;"|Total<br />
|-<br />
|colspan="4" style="text-align:left;"|xen/arch/x86<br />
|124,615<br />
|-<br />
|colspan="4" style="text-align:left;"|xen/include/asm-x86<br />
|18,530<br />
|-<br />
|colspan="4" style="background-color:Tomato; text-align:left;"|Total x86_64<br />
|style="background-color:Tomato;"|143,145<br />
|}<br />
<br />
== Porting Xen to a new SoC ==<br />
Assuming that you already have a functional Dom0 kernel (usually Linux) for your SoC, porting Xen to it is a very simple task.<br />
In fact in terms of devices, Xen only uses:<br />
* GIC<br />
* generic timers<br />
* SMMU<br />
* one UART for debugging<br />
<br />
Therefore the porting effort is limited to writing a new UART driver for Xen (if the SoC comes with an unsupported UART) and the code to bring up secondary CPUs (if the platform does not support PSCI, for which Xen has already a driver).<br />
See for example the [http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/drivers/char/exynos4210-uart.c Exynos 4210 Xen driver] and the [http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/arm/platforms/exynos5.c Exynos5 platform code].<br />
<br />
If you need to debug the interrupts, have a look to the function do_IRQ() in Xen. All interrupts are taken by Xen through the GIC and routed to do_IRQ(). This will dispatch the IRQ either to a guest or call a Xen specific handler, then. Xen itself handles only limited number of interrupts: timers, UART and SMMU. The rest is either routed to guests or blacklisted by Xen.<br />
<br />
== Porting an operating system to Xen on ARM ==<br />
Porting an OS to Xen on ARM is easy: it does not require any changes to the operating system kernel, only a few new drivers to get the paravirtualized frontends running and to obtain access to network, disk, console, etc.<br />
The paravirtualized frontends rely on:<br />
* grant table for page sharing ([https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/xen/grant-table.c linux version], [http://svnweb.freebsd.org/base/head/sys/xen/gnttab.c?view=co freebsd version])<br />
* xenbus for discovery ([https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/xen/xenbus linux version], [http://svnweb.freebsd.org/base/head/sys/xen/xenbus/ freebsd version])<br />
* event channels for notifications ([https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/xen/events linux version], [http://svnweb.freebsd.org/base/head/sys/x86/xen/xen_intr.c freebsd version])<br />
Once the OS has support for the basic building blocks, the next step is introducing the paravirtualized frontend drivers. You are likely to be able to reuse the existing ones:<br />
<br />
* network ([https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/net/xen-netfront.c linux version], [http://svnweb.freebsd.org/base/head/sys/dev/xen/netfront/ freebsd version])<br />
* block ([https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/block/xen-blkfront.c linux version], [http://svnweb.freebsd.org/base/head/sys/dev/xen/blkfront/ freebsd version])<br />
* console ([https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/tty/hvc/hvc_xen.c linux version], [http://svnweb.freebsd.org/base/head/sys/dev/xen/console/ freebsd version])<br />
* framebuffer ([https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/video/xen-fbfront.c linux version])<br />
* keyboard and mouse ([https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/input/misc/xen-kbdfront.c linux version])<br />
<br />
== Mobile platforms and new PV protocols ==<br />
Virtualizing a modern mobile platform involves dealing with devices such as camera, compass, gps, etc, for which PV frontend and backend drivers do not exist today.<br />
If only one VM needs access to one of these devices at a time, you can simply assign the device to the VM, remapping the corresponding MMIO regions and interrupts.<br />
If multiple VMs need access to the device simultaneously, you have to write a new pair of PV frontend and backend drivers. Fortunately many open source implementations of PV frontends and backends for different class of devices already exist in Linux and other operating systems. Something similar is likely to already exist. The difficulty of writing a new pair of PV frontends and backends increases with the complexity of the device you are trying to share. If the device is simple, such as the compass, writing the new pair of drivers is going to very easy. If the device is complex, such as a 3d graphic accelerator, writing the new pair of frontends and backends is going to be difficult.<br />
<br />
[[Category:XenARM]]<br />
[[Category:Developers]]<br />
[[Category:OpenEmbedded]]<br />
[[Category:Xen 4.3]]<br />
[[Category:Xen 4.4]]</div>Rpersaudhttps://wiki.xenproject.org/index.php?title=Automotive_Whitepapers&diff=18620Automotive Whitepapers2018-02-19T18:14:54Z<p>Rpersaud: </p>
<hr />
<div>* [[:File:DriverDomainonARM01.pdf|Driver Domain on ARM]] by Andrii Tseglytskyi ''2015-08-06, GlobalLogic''<br />
{{Quote|In the following article I want to describe GlobalLogic’s team experience of bring-up a driver domain on ARM platform. The results that we have achieved with a driver domain were introduced at CES 2015 show and GENIVI event.}}<br />
<br />
* [[:File:RT-Xen on ARM.pdf|RT-Xen on ARM]] by Denys Drozdov ''2015-03-10, GlobalLogic''<br />
{{Quote|The paper analyzes the latency of OS scheduling for symmetric and asymmetric multi-processing support cases – as well as incoming packet handling in Xen – using default credit and real-time schedulers. It also demonstrates how the real-time scheduler affects latency. With RT-Xen support, most of the incoming packets are predictably handled within 1 millisecond with a small overhead at the destined guest OS, which is a feasible time bound for most soft real-time applications.}}<br />
<br />
* [[:File:Device_passthrough_xen.pdf|Device Passthrough to Driver Domain in Xen]] by Yurii Konovalenko ''2015-02-25, GlobalLogic''<br />
{{Quote|As we all know, one of the most common sources of OS crashes are hardware drivers and the issues with them. On systems with visualization, it seems logical to create a separate domain and place hardware drivers (or at least the buggiest of them) there. One of the most significant tasks of creating a system with such a driver domain is to correctly provide it with resources (e.g., IO memory, IRQs). The main idea of passthrough described in the paper is to grant access for DomD through Dom0.}}<br />
<br />
* [[:File:Co-processor_management_under_xen.pdf|Managing coprocessors for Linux PV domains by running a Xen hypervisor on ARM platforms]] by Andrii Tseglytskyi ''2015-01-14, GlobalLogic''<br />
{{Quote|As modern ARM SoCs become faster and faster, they are now capable of performing the same highload tasks that desktop PCs were performing a few years ago, such as HD video playback and highspeed graphic rendering. The structure of an ARM SoC is also now quite complicated. In addition to containing a CPU module or modules, it also includes several peripheral modules (e.g., UARTs, Wireless, HDMI ports, etc.) and coprocessors that are designed to help with highload tasks like Graphic Processor Unit (GPU) or Video Processor Unit (VPU) are assembled together with the main CPU on almost all modern ARM SoCs that are designed for mobile and automotive markets. The article will cover few aspects of sharing such coprocessors when running Xen on embedded SoC.}}<br />
<br />
[[Category:Embedded and Automotive PV Drivers]]<br />
[[Category:OpenEmbedded]]<br />
[[Category:XenARM]]<br />
[[Category:Whitepapers]]</div>Rpersaud