search for: ultravisor

...gt; that operates in PV mode private to that guest. I.e. any attempts by the > > hypervisor or other guests to access it will result in an exception. If > > supported by the environment (machine, KVM, guest VM) a guest can decide > > to change into PV mode by doing the appropriate ultravisor calls. > > > > * Ultravisor: > > > > A hardware/firmware entity that manages PV guests, and polices access to > > their memory. A PV guest prospect needs to interact with the ultravisor, > > to enter PV mode, and potentially to share pages (for I/O which should...

...y of a guest > that operates in PV mode private to that guest. I.e. any attempts by the > hypervisor or other guests to access it will result in an exception. If > supported by the environment (machine, KVM, guest VM) a guest can decide > to change into PV mode by doing the appropriate ultravisor calls. Unlike > some other enhanced virtualization protection technology, I think that sentence misses its second part? > > * Ultravisor: > > A hardware/firmware entity that manages PV guests, and polices access to > their memory. A PV guest prospect needs to interact with th...

...y of a guest > that operates in PV mode private to that guest. I.e. any attempts by the > hypervisor or other guests to access it will result in an exception. If > supported by the environment (machine, KVM, guest VM) a guest can decide > to change into PV mode by doing the appropriate ultravisor calls. > > * Ultravisor: > > A hardware/firmware entity that manages PV guests, and polices access to > their memory. A PV guest prospect needs to interact with the ultravisor, > to enter PV mode, and potentially to share pages (for I/O which should > be encrypted by the gues...

..._rodata_ro(void) > pr_info("Write protected read-only-after-init data: %luk\n", size >> 10); > } > > +int set_memory_encrypted(unsigned long addr, int numpages) > +{ > + /* also called for the swiotlb bounce buffers, make all pages shared */ > + /* TODO: do ultravisor calls */ > + return 0; > +} > +EXPORT_SYMBOL_GPL(set_memory_encrypted); > + > +int set_memory_decrypted(unsigned long addr, int numpages) > +{ > + /* also called for the swiotlb bounce buffers, make all pages shared */ > + /* TODO: do ultravisor calls */ > + return 0; &gt...

...as a *normal* VM. The DT stuff is generated by qemu at a point where it has *no idea* that the VM will later become secure and thus will have to restrict which pages can be used for "DMA". The VM will *at runtime* turn itself into a secure VM via interactions with the security HW and the Ultravisor layer (which sits below the HV). This happens way after the DT has been created and consumed, the qemu devices instanciated etc... Only the guest kernel knows because it initates the transition. When that happens, the virtio devices have already been used by the guest firmware, bootloader, possibl...

...as a *normal* VM. The DT stuff is generated by qemu at a point where it has *no idea* that the VM will later become secure and thus will have to restrict which pages can be used for "DMA". The VM will *at runtime* turn itself into a secure VM via interactions with the security HW and the Ultravisor layer (which sits below the HV). This happens way after the DT has been created and consumed, the qemu devices instanciated etc... Only the guest kernel knows because it initates the transition. When that happens, the virtio devices have already been used by the guest firmware, bootloader, possibl...

...; Intel virtio based NIC is going to work on any of those > > > > plaforms. > > > > > > SEV guys report that they just set the iommu flag and then it all works. > > > > This is one of the fundamental difference between SEV architecture and > > the ultravisor architecture. In SEV, qemu is aware of SEV. In > > ultravisor architecture, only the VM that runs within qemu is aware of > > ultravisor; hypervisor/qemu/administrator are untrusted entities. > > Spo one option is to teach qemu that it's on a platform with an > ultraviso...

...for example the > > > Intel virtio based NIC is going to work on any of those > > > plaforms. > > > > SEV guys report that they just set the iommu flag and then it all works. > > This is one of the fundamental difference between SEV architecture and > the ultravisor architecture. In SEV, qemu is aware of SEV. In > ultravisor architecture, only the VM that runs within qemu is aware of > ultravisor; hypervisor/qemu/administrator are untrusted entities. Spo one option is to teach qemu that it's on a platform with an ultravisor, this might have more a...

...ed virtualization protection technology may require the use of > bounce buffers for I/O. While support for this was built into the virtio > core, virtio-ccw wasn't changed accordingly. Can you elaborate some more about the general approach (Enhanced virtualization protection technology, ultravisor, concept, issues, how to squeeze it into QEMU/KVM/kernel) etc = For my taste, this cover letter misses some important context :) > > Thus what needs to be done to bring virtio-ccw up to speed with respect > to this is: > * use some 'new' common virtio stuff > * make sure t...

...nly-after-init data: %luk\n", size >> 10); > > > } > > > > > > +int set_memory_encrypted(unsigned long addr, int numpages) > > > +{ > > > + /* also called for the swiotlb bounce buffers, make all pages shared */ > > > + /* TODO: do ultravisor calls */ > > > + return 0; > > > +} > > > +EXPORT_SYMBOL_GPL(set_memory_encrypted); > > > + > > > +int set_memory_decrypted(unsigned long addr, int numpages) > > > +{ > > > + /* also called for the swiotlb bounce buffers, make all pages...

...directly, which holds true for traditional VMs, but breaks when the VM in our case turns itself into a secure VM. This isn't under the action (or due to changes in) the hypervisor. KVM operates (almost) normally here. But there's this (very thin and open source btw) layer underneath called ultravisor, which exploits some HW facilities to maintain a separate pool of "secure" memory, which cannot be physically accessed by a non-secure entity. So in our scenario, qemu and KVM create a VM totally normally, there is no changes required to the VM firmware, bootloader(s), etc... in fact we...

...directly, which holds true for traditional VMs, but breaks when the VM in our case turns itself into a secure VM. This isn't under the action (or due to changes in) the hypervisor. KVM operates (almost) normally here. But there's this (very thin and open source btw) layer underneath called ultravisor, which exploits some HW facilities to maintain a separate pool of "secure" memory, which cannot be physically accessed by a non-secure entity. So in our scenario, qemu and KVM create a VM totally normally, there is no changes required to the VM firmware, bootloader(s), etc... in fact we...

...un Linux at that point, unsecurely, as we can use Linux as a bootloader under some circumstances), we start a "secure image". This is a kernel zImage that includes a "ticket" that has the appropriate signature etc... so that when that kernel starts, it can authenticate with the ultravisor, be verified (along with its ramdisk) etc... and copied (by the UV) into secure memory & run from there. At that point, the hypervisor is informed that the VM has become secure. So at that point, we could exit to qemu to inform it of the change, and have it walk the qtree and "Switch&quo...

...un Linux at that point, unsecurely, as we can use Linux as a bootloader under some circumstances), we start a "secure image". This is a kernel zImage that includes a "ticket" that has the appropriate signature etc... so that when that kernel starts, it can authenticate with the ultravisor, be verified (along with its ramdisk) etc... and copied (by the UV) into secure memory & run from there. At that point, the hypervisor is informed that the VM has become secure. So at that point, we could exit to qemu to inform it of the change, and have it walk the qtree and "Switch&quo...

On Fri, 2018-08-03 at 09:02 -0700, Christoph Hellwig wrote: > On Fri, Aug 03, 2018 at 10:58:36AM -0500, Benjamin Herrenschmidt wrote: > > On Fri, 2018-08-03 at 00:05 -0700, Christoph Hellwig wrote: > > > > 2- Make virtio use the DMA API with our custom platform-provided > > > > swiotlb callbacks when needed, that is when not using IOMMU *and* > > > >

On Fri, 2018-08-03 at 09:02 -0700, Christoph Hellwig wrote: > On Fri, Aug 03, 2018 at 10:58:36AM -0500, Benjamin Herrenschmidt wrote: > > On Fri, 2018-08-03 at 00:05 -0700, Christoph Hellwig wrote: > > > > 2- Make virtio use the DMA API with our custom platform-provided > > > > swiotlb callbacks when needed, that is when not using IOMMU *and* > > > >

...t platforms, force virtio core to use DMA > >>> + * MAP API for all virtio devices. But there can also be some > >>> + * exceptions for individual devices like virtio balloon. > >>> + */ > >>> + return (of_find_compatible_node(NULL, NULL, "ibm,ultravisor") != NULL); > >>> +} > >> > >> Isn't this kind of slow? vring_use_dma_api is on > >> data path and supposed to be very fast. > > > > Yes it is slow and not ideal. This won't be the final code. The final > > code will cache the...

...t platforms, force virtio core to use DMA > >>> + * MAP API for all virtio devices. But there can also be some > >>> + * exceptions for individual devices like virtio balloon. > >>> + */ > >>> + return (of_find_compatible_node(NULL, NULL, "ibm,ultravisor") != NULL); > >>> +} > >> > >> Isn't this kind of slow? vring_use_dma_api is on > >> data path and supposed to be very fast. > > > > Yes it is slow and not ideal. This won't be the final code. The final > > code will cache the...

...es_virtio_dma(struct virtio_device *vdev) +{ + /* + * On protected guest platforms, force virtio core to use DMA + * MAP API for all virtio devices. But there can also be some + * exceptions for individual devices like virtio balloon. + */ + return (of_find_compatible_node(NULL, NULL, "ibm,ultravisor") != NULL); +} diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c index 21d464a..47ea6c3 100644 --- a/drivers/virtio/virtio_ring.c +++ b/drivers/virtio/virtio_ring.c @@ -141,8 +141,18 @@ struct vring_virtqueue { * unconditionally on data path. */ +#ifndef platform_f...

...es_virtio_dma(struct virtio_device *vdev) +{ + /* + * On protected guest platforms, force virtio core to use DMA + * MAP API for all virtio devices. But there can also be some + * exceptions for individual devices like virtio balloon. + */ + return (of_find_compatible_node(NULL, NULL, "ibm,ultravisor") != NULL); +} diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c index 21d464a..47ea6c3 100644 --- a/drivers/virtio/virtio_ring.c +++ b/drivers/virtio/virtio_ring.c @@ -141,8 +141,18 @@ struct vring_virtqueue { * unconditionally on data path. */ +#ifndef platform_f...