Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted
On Mon, 2019-07-15 at 19:03 -0300, Thiago Jung Bauermann wrote: > > > Indeed. The idea is that QEMU can offer the flag, old guests can > > > reject > > > it (or even new guests can reject it, if they decide not to > > > convert into > > > secure VMs) and the feature negotiation will succeed with the > > > flag > > > unset. > > > > OK. And then what does QEMU do? Assume guest is not encrypted I > > guess? > > There's nothing different that QEMU needs to do, with or without the > flag. the perspective of the host, a secure guest and a regular guest > work the same way with respect to virtio. This is *precisely* why I was against adding a flag and touch the protocol negociation with qemu in the first place, back when I cared about that stuff... Guys, this has gone in circles over and over again. This has nothing to do with qemu. Qemu doesn't need to know about this. It's entirely guest local. This is why the one-liner in virtio was a far better and simpler solution. This is something the guest does to itself (with the participation of a ultravisor but that's not something qemu cares about at this stage, at least not as far as virtio is concerned). Basically, the guest "hides" its memory from the host using a HW secure memory facility. As a result, it needs to ensure that all of its DMA pages are bounced through insecure pages that aren't hidden. That's it, it's all guest side. Qemu shouldn't have to care about it at all. Cheers, Ben.
Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted
Michael S. Tsirkin writes: > On Mon, Jul 15, 2019 at 07:03:03PM -0300, Thiago Jung Bauermann wrote: >> >> Michael S. Tsirkin writes: >> >> > On Mon, Jul 15, 2019 at 05:29:06PM -0300, Thiago Jung Bauermann wrote: >> >> >> >> Michael S. Tsirkin writes: >> >> >> >> > On Sun, Jul 14, 2019 at 02:51:18AM -0300, Thiago Jung Bauermann wrote: >> >> >> >> >> >> >> >> >> Michael S. Tsirkin writes: >> >> >> >> >> >> > So this is what I would call this option: >> >> >> > >> >> >> > VIRTIO_F_ACCESS_PLATFORM_IDENTITY_ADDRESS >> >> >> > >> >> >> > and the explanation should state that all device >> >> >> > addresses are translated by the platform to identical >> >> >> > addresses. >> >> >> > >> >> >> > In fact this option then becomes more, not less restrictive >> >> >> > than VIRTIO_F_ACCESS_PLATFORM - it's a promise >> >> >> > by guest to only create identity mappings, >> >> >> > and only before driver_ok is set. >> >> >> > This option then would always be negotiated together with >> >> >> > VIRTIO_F_ACCESS_PLATFORM. >> >> >> > >> >> >> > Host then must verify that >> >> >> > 1. full 1:1 mappings are created before driver_ok >> >> >> > or can we make sure this happens before features_ok? >> >> >> > that would be ideal as we could require that features_ok fails >> >> >> > 2. mappings are not modified between driver_ok and reset >> >> >> > i guess attempts to change them will fail - >> >> >> > possibly by causing a guest crash >> >> >> > or some other kind of platform-specific error >> >> >> >> >> >> I think VIRTIO_F_ACCESS_PLATFORM_IDENTITY_ADDRESS is good, but >> >> >> requiring >> >> >> it to be accompanied by ACCESS_PLATFORM can be a problem. One reason is >> >> >> SLOF as I mentioned above, another is that we would be requiring all >> >> >> guests running on the machine (secure guests or not, since we would use >> >> >> the same configuration for all guests) to support it. But >> >> >> ACCESS_PLATFORM is relatively recent so it's a bit early for that. For >> >> >> instance, Ubuntu 16.04 LTS (which is still supported) doesn't know >> >> >> about >> >> >> it and wouldn't be able to use the device. >> >> > >> >> > OK and your target is to enable use with kernel drivers within >> >> > guests, right? >> >> >> >> Right. >> >> >> >> > My question is, we are defining a new flag here, I guess old guests >> >> > then do not set it. How does it help old guests? Or maybe it's >> >> > not designed to ... >> >> >> >> Indeed. The idea is that QEMU can offer the flag, old guests can reject >> >> it (or even new guests can reject it, if they decide not to convert into >> >> secure VMs) and the feature negotiation will succeed with the flag >> >> unset. >> > >> > OK. And then what does QEMU do? Assume guest is not encrypted I guess? >> >> There's nothing different that QEMU needs to do, with or without the >> flag. the perspective of the host, a secure guest and a regular guest >> work the same way with respect to virtio. > > OK. So now let's get back to implementation. What will > Linux guest driver do? It can't activate DMA API blindly since that > will assume translation also works, right? It can on pseries, because we always have a 1:1 window mapping the whole guest memory. > Or do we somehow limit it to just a specific platform? Yes, we want to accept the new flag only on secure pseries guests. -- Thiago Jung Bauermann IBM Linux Technology Center
Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted
On Mon, Jul 15, 2019 at 07:03:03PM -0300, Thiago Jung Bauermann wrote: > > Michael S. Tsirkin writes: > > > On Mon, Jul 15, 2019 at 05:29:06PM -0300, Thiago Jung Bauermann wrote: > >> > >> Michael S. Tsirkin writes: > >> > >> > On Sun, Jul 14, 2019 at 02:51:18AM -0300, Thiago Jung Bauermann wrote: > >> >> > >> >> > >> >> Michael S. Tsirkin writes: > >> >> > >> >> > So this is what I would call this option: > >> >> > > >> >> > VIRTIO_F_ACCESS_PLATFORM_IDENTITY_ADDRESS > >> >> > > >> >> > and the explanation should state that all device > >> >> > addresses are translated by the platform to identical > >> >> > addresses. > >> >> > > >> >> > In fact this option then becomes more, not less restrictive > >> >> > than VIRTIO_F_ACCESS_PLATFORM - it's a promise > >> >> > by guest to only create identity mappings, > >> >> > and only before driver_ok is set. > >> >> > This option then would always be negotiated together with > >> >> > VIRTIO_F_ACCESS_PLATFORM. > >> >> > > >> >> > Host then must verify that > >> >> > 1. full 1:1 mappings are created before driver_ok > >> >> > or can we make sure this happens before features_ok? > >> >> > that would be ideal as we could require that features_ok fails > >> >> > 2. mappings are not modified between driver_ok and reset > >> >> > i guess attempts to change them will fail - > >> >> > possibly by causing a guest crash > >> >> > or some other kind of platform-specific error > >> >> > >> >> I think VIRTIO_F_ACCESS_PLATFORM_IDENTITY_ADDRESS is good, but requiring > >> >> it to be accompanied by ACCESS_PLATFORM can be a problem. One reason is > >> >> SLOF as I mentioned above, another is that we would be requiring all > >> >> guests running on the machine (secure guests or not, since we would use > >> >> the same configuration for all guests) to support it. But > >> >> ACCESS_PLATFORM is relatively recent so it's a bit early for that. For > >> >> instance, Ubuntu 16.04 LTS (which is still supported) doesn't know about > >> >> it and wouldn't be able to use the device. > >> > > >> > OK and your target is to enable use with kernel drivers within > >> > guests, right? > >> > >> Right. > >> > >> > My question is, we are defining a new flag here, I guess old guests > >> > then do not set it. How does it help old guests? Or maybe it's > >> > not designed to ... > >> > >> Indeed. The idea is that QEMU can offer the flag, old guests can reject > >> it (or even new guests can reject it, if they decide not to convert into > >> secure VMs) and the feature negotiation will succeed with the flag > >> unset. > > > > OK. And then what does QEMU do? Assume guest is not encrypted I guess? > > There's nothing different that QEMU needs to do, with or without the > flag. the perspective of the host, a secure guest and a regular guest > work the same way with respect to virtio. OK. So now let's get back to implementation. What will Linux guest driver do? It can't activate DMA API blindly since that will assume translation also works, right? Or do we somehow limit it to just a specific platform? > -- > Thiago Jung Bauermann > IBM Linux Technology Center
Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted
Michael S. Tsirkin writes: > On Mon, Jul 15, 2019 at 05:29:06PM -0300, Thiago Jung Bauermann wrote: >> >> Michael S. Tsirkin writes: >> >> > On Sun, Jul 14, 2019 at 02:51:18AM -0300, Thiago Jung Bauermann wrote: >> >> >> >> >> >> Michael S. Tsirkin writes: >> >> >> >> > So this is what I would call this option: >> >> > >> >> > VIRTIO_F_ACCESS_PLATFORM_IDENTITY_ADDRESS >> >> > >> >> > and the explanation should state that all device >> >> > addresses are translated by the platform to identical >> >> > addresses. >> >> > >> >> > In fact this option then becomes more, not less restrictive >> >> > than VIRTIO_F_ACCESS_PLATFORM - it's a promise >> >> > by guest to only create identity mappings, >> >> > and only before driver_ok is set. >> >> > This option then would always be negotiated together with >> >> > VIRTIO_F_ACCESS_PLATFORM. >> >> > >> >> > Host then must verify that >> >> > 1. full 1:1 mappings are created before driver_ok >> >> > or can we make sure this happens before features_ok? >> >> > that would be ideal as we could require that features_ok fails >> >> > 2. mappings are not modified between driver_ok and reset >> >> > i guess attempts to change them will fail - >> >> > possibly by causing a guest crash >> >> > or some other kind of platform-specific error >> >> >> >> I think VIRTIO_F_ACCESS_PLATFORM_IDENTITY_ADDRESS is good, but requiring >> >> it to be accompanied by ACCESS_PLATFORM can be a problem. One reason is >> >> SLOF as I mentioned above, another is that we would be requiring all >> >> guests running on the machine (secure guests or not, since we would use >> >> the same configuration for all guests) to support it. But >> >> ACCESS_PLATFORM is relatively recent so it's a bit early for that. For >> >> instance, Ubuntu 16.04 LTS (which is still supported) doesn't know about >> >> it and wouldn't be able to use the device. >> > >> > OK and your target is to enable use with kernel drivers within >> > guests, right? >> >> Right. >> >> > My question is, we are defining a new flag here, I guess old guests >> > then do not set it. How does it help old guests? Or maybe it's >> > not designed to ... >> >> Indeed. The idea is that QEMU can offer the flag, old guests can reject >> it (or even new guests can reject it, if they decide not to convert into >> secure VMs) and the feature negotiation will succeed with the flag >> unset. > > OK. And then what does QEMU do? Assume guest is not encrypted I guess? There's nothing different that QEMU needs to do, with or without the flag. the perspective of the host, a secure guest and a regular guest work the same way with respect to virtio. -- Thiago Jung Bauermann IBM Linux Technology Center
Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted
On Mon, Jul 15, 2019 at 05:29:06PM -0300, Thiago Jung Bauermann wrote: > > Michael S. Tsirkin writes: > > > On Sun, Jul 14, 2019 at 02:51:18AM -0300, Thiago Jung Bauermann wrote: > >> > >> > >> Michael S. Tsirkin writes: > >> > >> > So this is what I would call this option: > >> > > >> > VIRTIO_F_ACCESS_PLATFORM_IDENTITY_ADDRESS > >> > > >> > and the explanation should state that all device > >> > addresses are translated by the platform to identical > >> > addresses. > >> > > >> > In fact this option then becomes more, not less restrictive > >> > than VIRTIO_F_ACCESS_PLATFORM - it's a promise > >> > by guest to only create identity mappings, > >> > and only before driver_ok is set. > >> > This option then would always be negotiated together with > >> > VIRTIO_F_ACCESS_PLATFORM. > >> > > >> > Host then must verify that > >> > 1. full 1:1 mappings are created before driver_ok > >> > or can we make sure this happens before features_ok? > >> > that would be ideal as we could require that features_ok fails > >> > 2. mappings are not modified between driver_ok and reset > >> > i guess attempts to change them will fail - > >> > possibly by causing a guest crash > >> > or some other kind of platform-specific error > >> > >> I think VIRTIO_F_ACCESS_PLATFORM_IDENTITY_ADDRESS is good, but requiring > >> it to be accompanied by ACCESS_PLATFORM can be a problem. One reason is > >> SLOF as I mentioned above, another is that we would be requiring all > >> guests running on the machine (secure guests or not, since we would use > >> the same configuration for all guests) to support it. But > >> ACCESS_PLATFORM is relatively recent so it's a bit early for that. For > >> instance, Ubuntu 16.04 LTS (which is still supported) doesn't know about > >> it and wouldn't be able to use the device. > > > > OK and your target is to enable use with kernel drivers within > > guests, right? > > Right. > > > My question is, we are defining a new flag here, I guess old guests > > then do not set it. How does it help old guests? Or maybe it's > > not designed to ... > > Indeed. The idea is that QEMU can offer the flag, old guests can reject > it (or even new guests can reject it, if they decide not to convert into > secure VMs) and the feature negotiation will succeed with the flag > unset. OK. And then what does QEMU do? Assume guest is not encrypted I guess? > -- > Thiago Jung Bauermann > IBM Linux Technology Center
Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted
Michael S. Tsirkin writes: > On Sun, Jul 14, 2019 at 02:51:18AM -0300, Thiago Jung Bauermann wrote: >> >> >> Michael S. Tsirkin writes: >> >> > So this is what I would call this option: >> > >> > VIRTIO_F_ACCESS_PLATFORM_IDENTITY_ADDRESS >> > >> > and the explanation should state that all device >> > addresses are translated by the platform to identical >> > addresses. >> > >> > In fact this option then becomes more, not less restrictive >> > than VIRTIO_F_ACCESS_PLATFORM - it's a promise >> > by guest to only create identity mappings, >> > and only before driver_ok is set. >> > This option then would always be negotiated together with >> > VIRTIO_F_ACCESS_PLATFORM. >> > >> > Host then must verify that >> > 1. full 1:1 mappings are created before driver_ok >> > or can we make sure this happens before features_ok? >> > that would be ideal as we could require that features_ok fails >> > 2. mappings are not modified between driver_ok and reset >> > i guess attempts to change them will fail - >> > possibly by causing a guest crash >> > or some other kind of platform-specific error >> >> I think VIRTIO_F_ACCESS_PLATFORM_IDENTITY_ADDRESS is good, but requiring >> it to be accompanied by ACCESS_PLATFORM can be a problem. One reason is >> SLOF as I mentioned above, another is that we would be requiring all >> guests running on the machine (secure guests or not, since we would use >> the same configuration for all guests) to support it. But >> ACCESS_PLATFORM is relatively recent so it's a bit early for that. For >> instance, Ubuntu 16.04 LTS (which is still supported) doesn't know about >> it and wouldn't be able to use the device. > > OK and your target is to enable use with kernel drivers within > guests, right? Right. > My question is, we are defining a new flag here, I guess old guests > then do not set it. How does it help old guests? Or maybe it's > not designed to ... Indeed. The idea is that QEMU can offer the flag, old guests can reject it (or even new guests can reject it, if they decide not to convert into secure VMs) and the feature negotiation will succeed with the flag unset. -- Thiago Jung Bauermann IBM Linux Technology Center
Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted
On Sun, Jul 14, 2019 at 02:51:18AM -0300, Thiago Jung Bauermann wrote: > > > Michael S. Tsirkin writes: > > > On Thu, Jun 27, 2019 at 10:58:40PM -0300, Thiago Jung Bauermann wrote: > >> > >> Michael S. Tsirkin writes: > >> > >> > On Mon, Jun 03, 2019 at 10:13:59PM -0300, Thiago Jung Bauermann wrote: > >> >> > >> >> > >> >> Michael S. Tsirkin writes: > >> >> > >> >> > On Wed, Apr 17, 2019 at 06:42:00PM -0300, Thiago Jung Bauermann wrote: > >> >> >> I rephrased it in terms of address translation. What do you think of > >> >> >> this version? The flag name is slightly different too: > >> >> >> > >> >> >> > >> >> >> VIRTIO_F_ACCESS_PLATFORM_NO_TRANSLATION This feature has the same > >> >> >> meaning as VIRTIO_F_ACCESS_PLATFORM both when set and when not > >> >> >> set, > >> >> >> with the exception that address translation is guaranteed to be > >> >> >> unnecessary when accessing memory addresses supplied to the > >> >> >> device > >> >> >> by the driver. Which is to say, the device will always use > >> >> >> physical > >> >> >> addresses matching addresses used by the driver (typically > >> >> >> meaning > >> >> >> physical addresses used by the CPU) and not translated further. > >> >> >> This > >> >> >> flag should be set by the guest if offered, but to allow for > >> >> >> backward-compatibility device implementations allow for it to be > >> >> >> left unset by the guest. It is an error to set both this flag and > >> >> >> VIRTIO_F_ACCESS_PLATFORM. > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > OK so VIRTIO_F_ACCESS_PLATFORM is designed to allow unpriveledged > >> >> > drivers. This is why devices fail when it's not negotiated. > >> >> > >> >> Just to clarify, what do you mean by unprivileged drivers? Is it drivers > >> >> implemented in guest userspace such as with VFIO? Or unprivileged in > >> >> some other sense such as needing to use bounce buffers for some reason? > >> > > >> > I had drivers in guest userspace in mind. > >> > >> Great. Thanks for clarifying. > >> > >> I don't think this flag would work for guest userspace drivers. Should I > >> add a note about that in the flag definition? > > > > I think you need to clarify access protection rules. Is it only > > translation that is bypassed or is any platform-specific > > protection mechanism bypassed too? > > It is only translation. In a secure guest, if the device tries to access > a memory address that wasn't provided by the driver then the > architecture will deny that access. If the device accesses addresses > provided to it by the driver, then there's no protection mechanism or > translation to get in the way. > > >> >> > This confuses me. > >> >> > If driver is unpriveledged then what happens with this flag? > >> >> > It can supply any address it wants. Will that corrupt kernel > >> >> > memory? > >> >> > >> >> Not needing address translation doesn't necessarily mean that there's no > >> >> IOMMU. On powerpc we don't use VIRTIO_F_ACCESS_PLATFORM but there's > >> >> always an IOMMU present. And we also support VFIO drivers. The VFIO API > >> >> for pseries (sPAPR section in Documentation/vfio.txt) has extra ioctls > >> >> to program the IOMMU. > >> >> > >> >> For our use case, we don't need address translation because we set up an > >> >> identity mapping in the IOMMU so that the device can use guest physical > >> >> addresses. > > > > OK so I think I am beginning to see it in a different light. Right now the > > specific > > platform creates an identity mapping. That in turn means DMA API can be > > fast - it does not need to do anything. What you are looking for is a > > way to tell host it's an identity mapping - just as an optimization. > > > > Is that right? > > Almost. Theoretically it is just an optimization. But in practice the > pseries boot firmware (SLOF) doesn't support IOMMU_PLATFORM so it's not > possible to boot a guest from a device with that flag set. > > > So this is what I would call this option: > > > > VIRTIO_F_ACCESS_PLATFORM_IDENTITY_ADDRESS > > > > and the explanation should state that all device > > addresses are translated by the platform to identical > > addresses. > > > > In fact this option then becomes more, not less restrictive > > than VIRTIO_F_ACCESS_PLATFORM - it's a promise > > by guest to only create identity mappings, > > and only before driver_ok is set. > > This option then would always be negotiated together with > > VIRTIO_F_ACCESS_PLATFORM. > > > > Host then must verify that > > 1. full 1:1 mappings are created before driver_ok > > or can we make sure this happens before features_ok? > > that would be ideal as we could require that features_ok fails > > 2. mappings are not modified between driver_ok and reset > > i guess attempts to change them will fail - > > possibly by causing a guest crash > > or some other kind of platform-specific error > > I think VIRTIO_F_ACCESS_PLATFORM_IDENTITY_ADDRESS is good, but requiring >
Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted
Michael S. Tsirkin writes: > On Thu, Jun 27, 2019 at 10:58:40PM -0300, Thiago Jung Bauermann wrote: >> >> Michael S. Tsirkin writes: >> >> > On Mon, Jun 03, 2019 at 10:13:59PM -0300, Thiago Jung Bauermann wrote: >> >> >> >> >> >> Michael S. Tsirkin writes: >> >> >> >> > On Wed, Apr 17, 2019 at 06:42:00PM -0300, Thiago Jung Bauermann wrote: >> >> >> I rephrased it in terms of address translation. What do you think of >> >> >> this version? The flag name is slightly different too: >> >> >> >> >> >> >> >> >> VIRTIO_F_ACCESS_PLATFORM_NO_TRANSLATION This feature has the same >> >> >> meaning as VIRTIO_F_ACCESS_PLATFORM both when set and when not set, >> >> >> with the exception that address translation is guaranteed to be >> >> >> unnecessary when accessing memory addresses supplied to the device >> >> >> by the driver. Which is to say, the device will always use physical >> >> >> addresses matching addresses used by the driver (typically meaning >> >> >> physical addresses used by the CPU) and not translated further. >> >> >> This >> >> >> flag should be set by the guest if offered, but to allow for >> >> >> backward-compatibility device implementations allow for it to be >> >> >> left unset by the guest. It is an error to set both this flag and >> >> >> VIRTIO_F_ACCESS_PLATFORM. >> >> > >> >> > >> >> > >> >> > >> >> > OK so VIRTIO_F_ACCESS_PLATFORM is designed to allow unpriveledged >> >> > drivers. This is why devices fail when it's not negotiated. >> >> >> >> Just to clarify, what do you mean by unprivileged drivers? Is it drivers >> >> implemented in guest userspace such as with VFIO? Or unprivileged in >> >> some other sense such as needing to use bounce buffers for some reason? >> > >> > I had drivers in guest userspace in mind. >> >> Great. Thanks for clarifying. >> >> I don't think this flag would work for guest userspace drivers. Should I >> add a note about that in the flag definition? > > I think you need to clarify access protection rules. Is it only > translation that is bypassed or is any platform-specific > protection mechanism bypassed too? It is only translation. In a secure guest, if the device tries to access a memory address that wasn't provided by the driver then the architecture will deny that access. If the device accesses addresses provided to it by the driver, then there's no protection mechanism or translation to get in the way. >> >> > This confuses me. >> >> > If driver is unpriveledged then what happens with this flag? >> >> > It can supply any address it wants. Will that corrupt kernel >> >> > memory? >> >> >> >> Not needing address translation doesn't necessarily mean that there's no >> >> IOMMU. On powerpc we don't use VIRTIO_F_ACCESS_PLATFORM but there's >> >> always an IOMMU present. And we also support VFIO drivers. The VFIO API >> >> for pseries (sPAPR section in Documentation/vfio.txt) has extra ioctls >> >> to program the IOMMU. >> >> >> >> For our use case, we don't need address translation because we set up an >> >> identity mapping in the IOMMU so that the device can use guest physical >> >> addresses. > > OK so I think I am beginning to see it in a different light. Right now the > specific > platform creates an identity mapping. That in turn means DMA API can be > fast - it does not need to do anything. What you are looking for is a > way to tell host it's an identity mapping - just as an optimization. > > Is that right? Almost. Theoretically it is just an optimization. But in practice the pseries boot firmware (SLOF) doesn't support IOMMU_PLATFORM so it's not possible to boot a guest from a device with that flag set. > So this is what I would call this option: > > VIRTIO_F_ACCESS_PLATFORM_IDENTITY_ADDRESS > > and the explanation should state that all device > addresses are translated by the platform to identical > addresses. > > In fact this option then becomes more, not less restrictive > than VIRTIO_F_ACCESS_PLATFORM - it's a promise > by guest to only create identity mappings, > and only before driver_ok is set. > This option then would always be negotiated together with > VIRTIO_F_ACCESS_PLATFORM. > > Host then must verify that > 1. full 1:1 mappings are created before driver_ok > or can we make sure this happens before features_ok? > that would be ideal as we could require that features_ok fails > 2. mappings are not modified between driver_ok and reset > i guess attempts to change them will fail - > possibly by causing a guest crash > or some other kind of platform-specific error I think VIRTIO_F_ACCESS_PLATFORM_IDENTITY_ADDRESS is good, but requiring it to be accompanied by ACCESS_PLATFORM can be a problem. One reason is SLOF as I mentioned above, another is that we would be requiring all guests running on the machine (secure guests or not, since we would use the same configuration for all guests) to support it. But ACCESS_PLATFORM is relatively recent so it's a bit early for that. For
Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted
On Thu, Jun 27, 2019 at 10:58:40PM -0300, Thiago Jung Bauermann wrote: > > Michael S. Tsirkin writes: > > > On Mon, Jun 03, 2019 at 10:13:59PM -0300, Thiago Jung Bauermann wrote: > >> > >> > >> Michael S. Tsirkin writes: > >> > >> > On Wed, Apr 17, 2019 at 06:42:00PM -0300, Thiago Jung Bauermann wrote: > >> >> I rephrased it in terms of address translation. What do you think of > >> >> this version? The flag name is slightly different too: > >> >> > >> >> > >> >> VIRTIO_F_ACCESS_PLATFORM_NO_TRANSLATION This feature has the same > >> >> meaning as VIRTIO_F_ACCESS_PLATFORM both when set and when not set, > >> >> with the exception that address translation is guaranteed to be > >> >> unnecessary when accessing memory addresses supplied to the device > >> >> by the driver. Which is to say, the device will always use physical > >> >> addresses matching addresses used by the driver (typically meaning > >> >> physical addresses used by the CPU) and not translated further. This > >> >> flag should be set by the guest if offered, but to allow for > >> >> backward-compatibility device implementations allow for it to be > >> >> left unset by the guest. It is an error to set both this flag and > >> >> VIRTIO_F_ACCESS_PLATFORM. > >> > > >> > > >> > > >> > > >> > OK so VIRTIO_F_ACCESS_PLATFORM is designed to allow unpriveledged > >> > drivers. This is why devices fail when it's not negotiated. > >> > >> Just to clarify, what do you mean by unprivileged drivers? Is it drivers > >> implemented in guest userspace such as with VFIO? Or unprivileged in > >> some other sense such as needing to use bounce buffers for some reason? > > > > I had drivers in guest userspace in mind. > > Great. Thanks for clarifying. > > I don't think this flag would work for guest userspace drivers. Should I > add a note about that in the flag definition? I think you need to clarify access protection rules. Is it only translation that is bypassed or is any platform-specific protection mechanism bypassed too? > >> > This confuses me. > >> > If driver is unpriveledged then what happens with this flag? > >> > It can supply any address it wants. Will that corrupt kernel > >> > memory? > >> > >> Not needing address translation doesn't necessarily mean that there's no > >> IOMMU. On powerpc we don't use VIRTIO_F_ACCESS_PLATFORM but there's > >> always an IOMMU present. And we also support VFIO drivers. The VFIO API > >> for pseries (sPAPR section in Documentation/vfio.txt) has extra ioctls > >> to program the IOMMU. > >> > >> For our use case, we don't need address translation because we set up an > >> identity mapping in the IOMMU so that the device can use guest physical > >> addresses. OK so I think I am beginning to see it in a different light. Right now the specific platform creates an identity mapping. That in turn means DMA API can be fast - it does not need to do anything. What you are looking for is a way to tell host it's an identity mapping - just as an optimization. Is that right? So this is what I would call this option: VIRTIO_F_ACCESS_PLATFORM_IDENTITY_ADDRESS and the explanation should state that all device addresses are translated by the platform to identical addresses. In fact this option then becomes more, not less restrictive than VIRTIO_F_ACCESS_PLATFORM - it's a promise by guest to only create identity mappings, and only before driver_ok is set. This option then would always be negotiated together with VIRTIO_F_ACCESS_PLATFORM. Host then must verify that 1. full 1:1 mappings are created before driver_ok or can we make sure this happens before features_ok? that would be ideal as we could require that features_ok fails 2. mappings are not modified between driver_ok and reset i guess attempts to change them will fail - possibly by causing a guest crash or some other kind of platform-specific error So far so good, but now a question: how are we handling guest address width limitations? Is VIRTIO_F_ACCESS_PLATFORM_IDENTITY_ADDRESS subject to guest address width limitations? I am guessing we can make them so ... This needs to be documented. > > > > And can it access any guest physical address? > > Sorry, I was mistaken. We do support VFIO in guests but not for virtio > devices, only for regular PCI devices. In which case they will use > address translation. Not sure how this answers the question. > >> If the guest kernel is concerned that an unprivileged driver could > >> jeopardize its integrity it should not negotiate this feature flag. > > > > Unfortunately flag negotiation is done through config space > > and so can be overwritten by the driver. > > Ok, so the guest kernel has to forbid VFIO access on devices where this > flag is advertised. That's possible in theory but in practice we did not yet teach VFIO not to attach to legacy devices without VIRTIO_F_ACCESS_PLATFORM. So all security relies on host denying driver_ok without
Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted
Michael S. Tsirkin writes: > On Mon, Jun 03, 2019 at 10:13:59PM -0300, Thiago Jung Bauermann wrote: >> >> >> Michael S. Tsirkin writes: >> >> > On Wed, Apr 17, 2019 at 06:42:00PM -0300, Thiago Jung Bauermann wrote: >> >> I rephrased it in terms of address translation. What do you think of >> >> this version? The flag name is slightly different too: >> >> >> >> >> >> VIRTIO_F_ACCESS_PLATFORM_NO_TRANSLATION This feature has the same >> >> meaning as VIRTIO_F_ACCESS_PLATFORM both when set and when not set, >> >> with the exception that address translation is guaranteed to be >> >> unnecessary when accessing memory addresses supplied to the device >> >> by the driver. Which is to say, the device will always use physical >> >> addresses matching addresses used by the driver (typically meaning >> >> physical addresses used by the CPU) and not translated further. This >> >> flag should be set by the guest if offered, but to allow for >> >> backward-compatibility device implementations allow for it to be >> >> left unset by the guest. It is an error to set both this flag and >> >> VIRTIO_F_ACCESS_PLATFORM. >> > >> > >> > OK so VIRTIO_F_ACCESS_PLATFORM is designed to allow unpriveledged >> > drivers. This is why devices fail when it's not negotiated. >> >> Just to clarify, what do you mean by unprivileged drivers? Is it drivers >> implemented in guest userspace such as with VFIO? Or unprivileged in >> some other sense such as needing to use bounce buffers for some reason? > > I had drivers in guest userspace in mind. Great. Thanks for clarifying. I don't think this flag would work for guest userspace drivers. Should I add a note about that in the flag definition? >> > This confuses me. >> > If driver is unpriveledged then what happens with this flag? >> > It can supply any address it wants. Will that corrupt kernel >> > memory? >> >> Not needing address translation doesn't necessarily mean that there's no >> IOMMU. On powerpc we don't use VIRTIO_F_ACCESS_PLATFORM but there's >> always an IOMMU present. And we also support VFIO drivers. The VFIO API >> for pseries (sPAPR section in Documentation/vfio.txt) has extra ioctls >> to program the IOMMU. >> >> For our use case, we don't need address translation because we set up an >> identity mapping in the IOMMU so that the device can use guest physical >> addresses. > > And can it access any guest physical address? Sorry, I was mistaken. We do support VFIO in guests but not for virtio devices, only for regular PCI devices. In which case they will use address translation. >> If the guest kernel is concerned that an unprivileged driver could >> jeopardize its integrity it should not negotiate this feature flag. > > Unfortunately flag negotiation is done through config space > and so can be overwritten by the driver. Ok, so the guest kernel has to forbid VFIO access on devices where this flag is advertised. >> Perhaps there should be a note about this in the flag definition? This >> concern is platform-dependant though. I don't believe it's an issue in >> pseries. > > Again ACCESS_PLATFORM has a pretty open definition. It does actually > say it's all up to the platform. > > Specifically how will VIRTIO_F_ACCESS_PLATFORM_NO_TRANSLATION be > implemented portably? virtio has no portable way to know > whether DMA API bypasses translation. The fact that VIRTIO_F_ACCESS_PLATFORM_NO_TRANSLATION is set communicates that knowledge to virtio. There is a shared understanding between the guest and the host about what this flag being set means. -- Thiago Jung Bauermann IBM Linux Technology Center
Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted
On Mon, Jun 03, 2019 at 10:13:59PM -0300, Thiago Jung Bauermann wrote: > > > Michael S. Tsirkin writes: > > > On Wed, Apr 17, 2019 at 06:42:00PM -0300, Thiago Jung Bauermann wrote: > >> I rephrased it in terms of address translation. What do you think of > >> this version? The flag name is slightly different too: > >> > >> > >> VIRTIO_F_ACCESS_PLATFORM_NO_TRANSLATION This feature has the same > >> meaning as VIRTIO_F_ACCESS_PLATFORM both when set and when not set, > >> with the exception that address translation is guaranteed to be > >> unnecessary when accessing memory addresses supplied to the device > >> by the driver. Which is to say, the device will always use physical > >> addresses matching addresses used by the driver (typically meaning > >> physical addresses used by the CPU) and not translated further. This > >> flag should be set by the guest if offered, but to allow for > >> backward-compatibility device implementations allow for it to be > >> left unset by the guest. It is an error to set both this flag and > >> VIRTIO_F_ACCESS_PLATFORM. > > > > > > OK so VIRTIO_F_ACCESS_PLATFORM is designed to allow unpriveledged > > drivers. This is why devices fail when it's not negotiated. > > Just to clarify, what do you mean by unprivileged drivers? Is it drivers > implemented in guest userspace such as with VFIO? Or unprivileged in > some other sense such as needing to use bounce buffers for some reason? I had drivers in guest userspace in mind. > > This confuses me. > > If driver is unpriveledged then what happens with this flag? > > It can supply any address it wants. Will that corrupt kernel > > memory? > > Not needing address translation doesn't necessarily mean that there's no > IOMMU. On powerpc we don't use VIRTIO_F_ACCESS_PLATFORM but there's > always an IOMMU present. And we also support VFIO drivers. The VFIO API > for pseries (sPAPR section in Documentation/vfio.txt) has extra ioctls > to program the IOMMU. > > For our use case, we don't need address translation because we set up an > identity mapping in the IOMMU so that the device can use guest physical > addresses. And can it access any guest physical address? > If the guest kernel is concerned that an unprivileged driver could > jeopardize its integrity it should not negotiate this feature flag. Unfortunately flag negotiation is done through config space and so can be overwritten by the driver. > Perhaps there should be a note about this in the flag definition? This > concern is platform-dependant though. I don't believe it's an issue in > pseries. Again ACCESS_PLATFORM has a pretty open definition. It does actually say it's all up to the platform. Specifically how will VIRTIO_F_ACCESS_PLATFORM_NO_TRANSLATION be implemented portably? virtio has no portable way to know whether DMA API bypasses translation. > -- > Thiago Jung Bauermann > IBM Linux Technology Center
Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted
Michael S. Tsirkin writes: > On Wed, Apr 17, 2019 at 06:42:00PM -0300, Thiago Jung Bauermann wrote: >> I rephrased it in terms of address translation. What do you think of >> this version? The flag name is slightly different too: >> >> >> VIRTIO_F_ACCESS_PLATFORM_NO_TRANSLATION This feature has the same >> meaning as VIRTIO_F_ACCESS_PLATFORM both when set and when not set, >> with the exception that address translation is guaranteed to be >> unnecessary when accessing memory addresses supplied to the device >> by the driver. Which is to say, the device will always use physical >> addresses matching addresses used by the driver (typically meaning >> physical addresses used by the CPU) and not translated further. This >> flag should be set by the guest if offered, but to allow for >> backward-compatibility device implementations allow for it to be >> left unset by the guest. It is an error to set both this flag and >> VIRTIO_F_ACCESS_PLATFORM. > > > OK so VIRTIO_F_ACCESS_PLATFORM is designed to allow unpriveledged > drivers. This is why devices fail when it's not negotiated. Just to clarify, what do you mean by unprivileged drivers? Is it drivers implemented in guest userspace such as with VFIO? Or unprivileged in some other sense such as needing to use bounce buffers for some reason? > This confuses me. > If driver is unpriveledged then what happens with this flag? > It can supply any address it wants. Will that corrupt kernel > memory? Not needing address translation doesn't necessarily mean that there's no IOMMU. On powerpc we don't use VIRTIO_F_ACCESS_PLATFORM but there's always an IOMMU present. And we also support VFIO drivers. The VFIO API for pseries (sPAPR section in Documentation/vfio.txt) has extra ioctls to program the IOMMU. For our use case, we don't need address translation because we set up an identity mapping in the IOMMU so that the device can use guest physical addresses. If the guest kernel is concerned that an unprivileged driver could jeopardize its integrity it should not negotiate this feature flag. Perhaps there should be a note about this in the flag definition? This concern is platform-dependant though. I don't believe it's an issue in pseries. -- Thiago Jung Bauermann IBM Linux Technology Center
Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted
On Wed, Apr 17, 2019 at 06:42:00PM -0300, Thiago Jung Bauermann wrote: > I rephrased it in terms of address translation. What do you think of > this version? The flag name is slightly different too: > > > VIRTIO_F_ACCESS_PLATFORM_NO_TRANSLATION This feature has the same > meaning as VIRTIO_F_ACCESS_PLATFORM both when set and when not set, > with the exception that address translation is guaranteed to be > unnecessary when accessing memory addresses supplied to the device > by the driver. Which is to say, the device will always use physical > addresses matching addresses used by the driver (typically meaning > physical addresses used by the CPU) and not translated further. This > flag should be set by the guest if offered, but to allow for > backward-compatibility device implementations allow for it to be > left unset by the guest. It is an error to set both this flag and > VIRTIO_F_ACCESS_PLATFORM. OK so VIRTIO_F_ACCESS_PLATFORM is designed to allow unpriveledged drivers. This is why devices fail when it's not negotiated. This confuses me. If driver is unpriveledged then what happens with this flag? It can supply any address it wants. Will that corrupt kernel memory? -- MST
Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted
On Fri, Apr 26, 2019 at 08:56:43PM -0300, Thiago Jung Bauermann wrote: > > Michael S. Tsirkin writes: > > > On Wed, Apr 24, 2019 at 10:01:56PM -0300, Thiago Jung Bauermann wrote: > >> > >> Michael S. Tsirkin writes: > >> > >> > On Wed, Apr 17, 2019 at 06:42:00PM -0300, Thiago Jung Bauermann wrote: > >> >> > >> >> Michael S. Tsirkin writes: > >> >> > >> >> > On Thu, Mar 21, 2019 at 09:05:04PM -0300, Thiago Jung Bauermann wrote: > >> >> >> > >> >> >> Michael S. Tsirkin writes: > >> >> >> > >> >> >> > On Wed, Mar 20, 2019 at 01:13:41PM -0300, Thiago Jung Bauermann > >> >> >> > wrote: > >> >> >> >> >From what I understand of the ACCESS_PLATFORM definition, the > >> >> >> >> >host will > >> >> >> >> only ever try to access memory addresses that are supplied to it > >> >> >> >> by the > >> >> >> >> guest, so all of the secure guest memory that the host cares > >> >> >> >> about is > >> >> >> >> accessible: > >> >> >> >> > >> >> >> >> If this feature bit is set to 0, then the device has same > >> >> >> >> access to > >> >> >> >> memory addresses supplied to it as the driver has. In > >> >> >> >> particular, > >> >> >> >> the device will always use physical addresses matching > >> >> >> >> addresses > >> >> >> >> used by the driver (typically meaning physical addresses used > >> >> >> >> by the > >> >> >> >> CPU) and not translated further, and can access any address > >> >> >> >> supplied > >> >> >> >> to it by the driver. When clear, this overrides any > >> >> >> >> platform-specific description of whether device access is > >> >> >> >> limited or > >> >> >> >> translated in any way, e.g. whether an IOMMU may be present. > >> >> >> >> > >> >> >> >> All of the above is true for POWER guests, whether they are secure > >> >> >> >> guests or not. > >> >> >> >> > >> >> >> >> Or are you saying that a virtio device may want to access memory > >> >> >> >> addresses that weren't supplied to it by the driver? > >> >> >> > > >> >> >> > Your logic would apply to IOMMUs as well. For your mode, there are > >> >> >> > specific encrypted memory regions that driver has access to but > >> >> >> > device > >> >> >> > does not. that seems to violate the constraint. > >> >> >> > >> >> >> Right, if there's a pre-configured 1:1 mapping in the IOMMU such that > >> >> >> the device can ignore the IOMMU for all practical purposes I would > >> >> >> indeed say that the logic would apply to IOMMUs as well. :-) > >> >> >> > >> >> >> I guess I'm still struggling with the purpose of signalling to the > >> >> >> driver that the host may not have access to memory addresses that it > >> >> >> will never try to access. > >> >> > > >> >> > For example, one of the benefits is to signal to host that driver does > >> >> > not expect ability to access all memory. If it does, host can > >> >> > fail initialization gracefully. > >> >> > >> >> But why would the ability to access all memory be necessary or even > >> >> useful? When would the host access memory that the driver didn't tell it > >> >> to access? > >> > > >> > When I say all memory I mean even memory not allowed by the IOMMU. > >> > >> Yes, but why? How is that memory relevant? > > > > It's relevant when driver is not trusted to only supply correct > > addresses. The feature was originally designed to support userspace > > drivers within guests. > > Ah, thanks for clarifying. I don't think that's a problem in our case. > If the guest provides an incorrect address, the hardware simply won't > allow the host to access it. > > >> >> >> > Another idea is maybe something like virtio-iommu? > >> >> >> > >> >> >> You mean, have legacy guests use virtio-iommu to request an IOMMU > >> >> >> bypass? If so, it's an interesting idea for new guests but it doesn't > >> >> >> help with guests that are out today in the field, which don't have A > >> >> >> virtio-iommu driver. > >> >> > > >> >> > I presume legacy guests don't use encrypted memory so why do we > >> >> > worry about them at all? > >> >> > >> >> They don't use encrypted memory, but a host machine will run a mix of > >> >> secure and legacy guests. And since the hypervisor doesn't know whether > >> >> a guest will be secure or not at the time it is launched, legacy guests > >> >> will have to be launched with the same configuration as secure guests. > >> > > >> > OK and so I think the issue is that hosts generally fail if they set > >> > ACCESS_PLATFORM and guests do not negotiate it. > >> > So you can not just set ACCESS_PLATFORM for everyone. > >> > Is that the issue here? > >> > >> Yes, that is one half of the issue. The other is that even if hosts > >> didn't fail, existing legacy guests wouldn't "take the initiative" of > >> not negotiating ACCESS_PLATFORM to get the improved performance. They'd > >> have to be modified to do that. > > > > So there's a non-encrypted guest, hypervisor wants to set > > ACCESS_PLATFORM to allow encrypted guests but that will slow down legacy > > guests since
Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted
Michael S. Tsirkin writes: > On Wed, Apr 24, 2019 at 10:01:56PM -0300, Thiago Jung Bauermann wrote: >> >> Michael S. Tsirkin writes: >> >> > On Wed, Apr 17, 2019 at 06:42:00PM -0300, Thiago Jung Bauermann wrote: >> >> >> >> Michael S. Tsirkin writes: >> >> >> >> > On Thu, Mar 21, 2019 at 09:05:04PM -0300, Thiago Jung Bauermann wrote: >> >> >> >> >> >> Michael S. Tsirkin writes: >> >> >> >> >> >> > On Wed, Mar 20, 2019 at 01:13:41PM -0300, Thiago Jung Bauermann >> >> >> > wrote: >> >> >> >> >From what I understand of the ACCESS_PLATFORM definition, the host >> >> >> >> >will >> >> >> >> only ever try to access memory addresses that are supplied to it by >> >> >> >> the >> >> >> >> guest, so all of the secure guest memory that the host cares about >> >> >> >> is >> >> >> >> accessible: >> >> >> >> >> >> >> >> If this feature bit is set to 0, then the device has same >> >> >> >> access to >> >> >> >> memory addresses supplied to it as the driver has. In >> >> >> >> particular, >> >> >> >> the device will always use physical addresses matching addresses >> >> >> >> used by the driver (typically meaning physical addresses used >> >> >> >> by the >> >> >> >> CPU) and not translated further, and can access any address >> >> >> >> supplied >> >> >> >> to it by the driver. When clear, this overrides any >> >> >> >> platform-specific description of whether device access is >> >> >> >> limited or >> >> >> >> translated in any way, e.g. whether an IOMMU may be present. >> >> >> >> >> >> >> >> All of the above is true for POWER guests, whether they are secure >> >> >> >> guests or not. >> >> >> >> >> >> >> >> Or are you saying that a virtio device may want to access memory >> >> >> >> addresses that weren't supplied to it by the driver? >> >> >> > >> >> >> > Your logic would apply to IOMMUs as well. For your mode, there are >> >> >> > specific encrypted memory regions that driver has access to but >> >> >> > device >> >> >> > does not. that seems to violate the constraint. >> >> >> >> >> >> Right, if there's a pre-configured 1:1 mapping in the IOMMU such that >> >> >> the device can ignore the IOMMU for all practical purposes I would >> >> >> indeed say that the logic would apply to IOMMUs as well. :-) >> >> >> >> >> >> I guess I'm still struggling with the purpose of signalling to the >> >> >> driver that the host may not have access to memory addresses that it >> >> >> will never try to access. >> >> > >> >> > For example, one of the benefits is to signal to host that driver does >> >> > not expect ability to access all memory. If it does, host can >> >> > fail initialization gracefully. >> >> >> >> But why would the ability to access all memory be necessary or even >> >> useful? When would the host access memory that the driver didn't tell it >> >> to access? >> > >> > When I say all memory I mean even memory not allowed by the IOMMU. >> >> Yes, but why? How is that memory relevant? > > It's relevant when driver is not trusted to only supply correct > addresses. The feature was originally designed to support userspace > drivers within guests. Ah, thanks for clarifying. I don't think that's a problem in our case. If the guest provides an incorrect address, the hardware simply won't allow the host to access it. >> >> >> > Another idea is maybe something like virtio-iommu? >> >> >> >> >> >> You mean, have legacy guests use virtio-iommu to request an IOMMU >> >> >> bypass? If so, it's an interesting idea for new guests but it doesn't >> >> >> help with guests that are out today in the field, which don't have A >> >> >> virtio-iommu driver. >> >> > >> >> > I presume legacy guests don't use encrypted memory so why do we >> >> > worry about them at all? >> >> >> >> They don't use encrypted memory, but a host machine will run a mix of >> >> secure and legacy guests. And since the hypervisor doesn't know whether >> >> a guest will be secure or not at the time it is launched, legacy guests >> >> will have to be launched with the same configuration as secure guests. >> > >> > OK and so I think the issue is that hosts generally fail if they set >> > ACCESS_PLATFORM and guests do not negotiate it. >> > So you can not just set ACCESS_PLATFORM for everyone. >> > Is that the issue here? >> >> Yes, that is one half of the issue. The other is that even if hosts >> didn't fail, existing legacy guests wouldn't "take the initiative" of >> not negotiating ACCESS_PLATFORM to get the improved performance. They'd >> have to be modified to do that. > > So there's a non-encrypted guest, hypervisor wants to set > ACCESS_PLATFORM to allow encrypted guests but that will slow down legacy > guests since their vIOMMU emulation is very slow. Yes. > So enabling support for encryption slows down non-encrypted guests. Not > great but not the end of the world, considering even older guests that > don't support ACCESS_PLATFORM are completely broken and you do not seem > to be too worried by that.
Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted
On Wed, Apr 24, 2019 at 10:01:56PM -0300, Thiago Jung Bauermann wrote: > > Michael S. Tsirkin writes: > > > On Wed, Apr 17, 2019 at 06:42:00PM -0300, Thiago Jung Bauermann wrote: > >> > >> Michael S. Tsirkin writes: > >> > >> > On Thu, Mar 21, 2019 at 09:05:04PM -0300, Thiago Jung Bauermann wrote: > >> >> > >> >> Michael S. Tsirkin writes: > >> >> > >> >> > On Wed, Mar 20, 2019 at 01:13:41PM -0300, Thiago Jung Bauermann wrote: > >> >> >> >From what I understand of the ACCESS_PLATFORM definition, the host > >> >> >> >will > >> >> >> only ever try to access memory addresses that are supplied to it by > >> >> >> the > >> >> >> guest, so all of the secure guest memory that the host cares about is > >> >> >> accessible: > >> >> >> > >> >> >> If this feature bit is set to 0, then the device has same access > >> >> >> to > >> >> >> memory addresses supplied to it as the driver has. In particular, > >> >> >> the device will always use physical addresses matching addresses > >> >> >> used by the driver (typically meaning physical addresses used by > >> >> >> the > >> >> >> CPU) and not translated further, and can access any address > >> >> >> supplied > >> >> >> to it by the driver. When clear, this overrides any > >> >> >> platform-specific description of whether device access is > >> >> >> limited or > >> >> >> translated in any way, e.g. whether an IOMMU may be present. > >> >> >> > >> >> >> All of the above is true for POWER guests, whether they are secure > >> >> >> guests or not. > >> >> >> > >> >> >> Or are you saying that a virtio device may want to access memory > >> >> >> addresses that weren't supplied to it by the driver? > >> >> > > >> >> > Your logic would apply to IOMMUs as well. For your mode, there are > >> >> > specific encrypted memory regions that driver has access to but device > >> >> > does not. that seems to violate the constraint. > >> >> > >> >> Right, if there's a pre-configured 1:1 mapping in the IOMMU such that > >> >> the device can ignore the IOMMU for all practical purposes I would > >> >> indeed say that the logic would apply to IOMMUs as well. :-) > >> >> > >> >> I guess I'm still struggling with the purpose of signalling to the > >> >> driver that the host may not have access to memory addresses that it > >> >> will never try to access. > >> > > >> > For example, one of the benefits is to signal to host that driver does > >> > not expect ability to access all memory. If it does, host can > >> > fail initialization gracefully. > >> > >> But why would the ability to access all memory be necessary or even > >> useful? When would the host access memory that the driver didn't tell it > >> to access? > > > > When I say all memory I mean even memory not allowed by the IOMMU. > > Yes, but why? How is that memory relevant? It's relevant when driver is not trusted to only supply correct addresses. The feature was originally designed to support userspace drivers within guests. > >> >> >> >> > But the name "sev_active" makes me scared because at least AMD > >> >> >> >> > guys who > >> >> >> >> > were doing the sensible thing and setting ACCESS_PLATFORM > >> >> >> >> > >> >> >> >> My understanding is, AMD guest-platform knows in advance that > >> >> >> >> their > >> >> >> >> guest will run in secure mode and hence sets the flag at the time > >> >> >> >> of VM > >> >> >> >> instantiation. Unfortunately we dont have that luxury on our > >> >> >> >> platforms. > >> >> >> > > >> >> >> > Well you do have that luxury. It looks like that there are existing > >> >> >> > guests that already acknowledge ACCESS_PLATFORM and you are not > >> >> >> > happy > >> >> >> > with how that path is slow. So you are trying to optimize for > >> >> >> > them by clearing ACCESS_PLATFORM and then you have lost ability > >> >> >> > to invoke DMA API. > >> >> >> > > >> >> >> > For example if there was another flag just like ACCESS_PLATFORM > >> >> >> > just not yet used by anyone, you would be all fine using that > >> >> >> > right? > >> >> >> > >> >> >> Yes, a new flag sounds like a great idea. What about the definition > >> >> >> below? > >> >> >> > >> >> >> VIRTIO_F_ACCESS_PLATFORM_NO_IOMMU This feature has the same meaning > >> >> >> as > >> >> >> VIRTIO_F_ACCESS_PLATFORM both when set and when not set, with the > >> >> >> exception that the IOMMU is explicitly defined to be off or > >> >> >> bypassed > >> >> >> when accessing memory addresses supplied to the device by the > >> >> >> driver. This flag should be set by the guest if offered, but to > >> >> >> allow for backward-compatibility device implementations allow > >> >> >> for it > >> >> >> to be left unset by the guest. It is an error to set both this > >> >> >> flag > >> >> >> and VIRTIO_F_ACCESS_PLATFORM. > >> >> > > >> >> > It looks kind of narrow but it's an option. > >> >> > >> >> Great! > >> >> > >> >> > I wonder how we'll define what's an iommu though. > >> >> > >> >>
Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted
Michael S. Tsirkin writes: > On Wed, Apr 17, 2019 at 06:42:00PM -0300, Thiago Jung Bauermann wrote: >> >> Michael S. Tsirkin writes: >> >> > On Thu, Mar 21, 2019 at 09:05:04PM -0300, Thiago Jung Bauermann wrote: >> >> >> >> Michael S. Tsirkin writes: >> >> >> >> > On Wed, Mar 20, 2019 at 01:13:41PM -0300, Thiago Jung Bauermann wrote: >> >> >> >From what I understand of the ACCESS_PLATFORM definition, the host >> >> >> >will >> >> >> only ever try to access memory addresses that are supplied to it by the >> >> >> guest, so all of the secure guest memory that the host cares about is >> >> >> accessible: >> >> >> >> >> >> If this feature bit is set to 0, then the device has same access to >> >> >> memory addresses supplied to it as the driver has. In particular, >> >> >> the device will always use physical addresses matching addresses >> >> >> used by the driver (typically meaning physical addresses used by >> >> >> the >> >> >> CPU) and not translated further, and can access any address >> >> >> supplied >> >> >> to it by the driver. When clear, this overrides any >> >> >> platform-specific description of whether device access is limited >> >> >> or >> >> >> translated in any way, e.g. whether an IOMMU may be present. >> >> >> >> >> >> All of the above is true for POWER guests, whether they are secure >> >> >> guests or not. >> >> >> >> >> >> Or are you saying that a virtio device may want to access memory >> >> >> addresses that weren't supplied to it by the driver? >> >> > >> >> > Your logic would apply to IOMMUs as well. For your mode, there are >> >> > specific encrypted memory regions that driver has access to but device >> >> > does not. that seems to violate the constraint. >> >> >> >> Right, if there's a pre-configured 1:1 mapping in the IOMMU such that >> >> the device can ignore the IOMMU for all practical purposes I would >> >> indeed say that the logic would apply to IOMMUs as well. :-) >> >> >> >> I guess I'm still struggling with the purpose of signalling to the >> >> driver that the host may not have access to memory addresses that it >> >> will never try to access. >> > >> > For example, one of the benefits is to signal to host that driver does >> > not expect ability to access all memory. If it does, host can >> > fail initialization gracefully. >> >> But why would the ability to access all memory be necessary or even >> useful? When would the host access memory that the driver didn't tell it >> to access? > > When I say all memory I mean even memory not allowed by the IOMMU. Yes, but why? How is that memory relevant? >> >> >> >> > But the name "sev_active" makes me scared because at least AMD >> >> >> >> > guys who >> >> >> >> > were doing the sensible thing and setting ACCESS_PLATFORM >> >> >> >> >> >> >> >> My understanding is, AMD guest-platform knows in advance that their >> >> >> >> guest will run in secure mode and hence sets the flag at the time >> >> >> >> of VM >> >> >> >> instantiation. Unfortunately we dont have that luxury on our >> >> >> >> platforms. >> >> >> > >> >> >> > Well you do have that luxury. It looks like that there are existing >> >> >> > guests that already acknowledge ACCESS_PLATFORM and you are not happy >> >> >> > with how that path is slow. So you are trying to optimize for >> >> >> > them by clearing ACCESS_PLATFORM and then you have lost ability >> >> >> > to invoke DMA API. >> >> >> > >> >> >> > For example if there was another flag just like ACCESS_PLATFORM >> >> >> > just not yet used by anyone, you would be all fine using that right? >> >> >> >> >> >> Yes, a new flag sounds like a great idea. What about the definition >> >> >> below? >> >> >> >> >> >> VIRTIO_F_ACCESS_PLATFORM_NO_IOMMU This feature has the same meaning as >> >> >> VIRTIO_F_ACCESS_PLATFORM both when set and when not set, with the >> >> >> exception that the IOMMU is explicitly defined to be off or >> >> >> bypassed >> >> >> when accessing memory addresses supplied to the device by the >> >> >> driver. This flag should be set by the guest if offered, but to >> >> >> allow for backward-compatibility device implementations allow for >> >> >> it >> >> >> to be left unset by the guest. It is an error to set both this flag >> >> >> and VIRTIO_F_ACCESS_PLATFORM. >> >> > >> >> > It looks kind of narrow but it's an option. >> >> >> >> Great! >> >> >> >> > I wonder how we'll define what's an iommu though. >> >> >> >> Hm, it didn't occur to me it could be an issue. I'll try. >> >> I rephrased it in terms of address translation. What do you think of >> this version? The flag name is slightly different too: >> >> >> VIRTIO_F_ACCESS_PLATFORM_NO_TRANSLATION This feature has the same >> meaning as VIRTIO_F_ACCESS_PLATFORM both when set and when not set, >> with the exception that address translation is guaranteed to be >> unnecessary when accessing memory addresses supplied to the device >> by the driver. Which
Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted
On Wed, Apr 17, 2019 at 06:42:00PM -0300, Thiago Jung Bauermann wrote: > > Michael S. Tsirkin writes: > > > On Thu, Mar 21, 2019 at 09:05:04PM -0300, Thiago Jung Bauermann wrote: > >> > >> Michael S. Tsirkin writes: > >> > >> > On Wed, Mar 20, 2019 at 01:13:41PM -0300, Thiago Jung Bauermann wrote: > >> >> >From what I understand of the ACCESS_PLATFORM definition, the host will > >> >> only ever try to access memory addresses that are supplied to it by the > >> >> guest, so all of the secure guest memory that the host cares about is > >> >> accessible: > >> >> > >> >> If this feature bit is set to 0, then the device has same access to > >> >> memory addresses supplied to it as the driver has. In particular, > >> >> the device will always use physical addresses matching addresses > >> >> used by the driver (typically meaning physical addresses used by the > >> >> CPU) and not translated further, and can access any address supplied > >> >> to it by the driver. When clear, this overrides any > >> >> platform-specific description of whether device access is limited or > >> >> translated in any way, e.g. whether an IOMMU may be present. > >> >> > >> >> All of the above is true for POWER guests, whether they are secure > >> >> guests or not. > >> >> > >> >> Or are you saying that a virtio device may want to access memory > >> >> addresses that weren't supplied to it by the driver? > >> > > >> > Your logic would apply to IOMMUs as well. For your mode, there are > >> > specific encrypted memory regions that driver has access to but device > >> > does not. that seems to violate the constraint. > >> > >> Right, if there's a pre-configured 1:1 mapping in the IOMMU such that > >> the device can ignore the IOMMU for all practical purposes I would > >> indeed say that the logic would apply to IOMMUs as well. :-) > >> > >> I guess I'm still struggling with the purpose of signalling to the > >> driver that the host may not have access to memory addresses that it > >> will never try to access. > > > > For example, one of the benefits is to signal to host that driver does > > not expect ability to access all memory. If it does, host can > > fail initialization gracefully. > > But why would the ability to access all memory be necessary or even > useful? When would the host access memory that the driver didn't tell it > to access? When I say all memory I mean even memory not allowed by the IOMMU. > >> >> >> > But the name "sev_active" makes me scared because at least AMD > >> >> >> > guys who > >> >> >> > were doing the sensible thing and setting ACCESS_PLATFORM > >> >> >> > >> >> >> My understanding is, AMD guest-platform knows in advance that their > >> >> >> guest will run in secure mode and hence sets the flag at the time of > >> >> >> VM > >> >> >> instantiation. Unfortunately we dont have that luxury on our > >> >> >> platforms. > >> >> > > >> >> > Well you do have that luxury. It looks like that there are existing > >> >> > guests that already acknowledge ACCESS_PLATFORM and you are not happy > >> >> > with how that path is slow. So you are trying to optimize for > >> >> > them by clearing ACCESS_PLATFORM and then you have lost ability > >> >> > to invoke DMA API. > >> >> > > >> >> > For example if there was another flag just like ACCESS_PLATFORM > >> >> > just not yet used by anyone, you would be all fine using that right? > >> >> > >> >> Yes, a new flag sounds like a great idea. What about the definition > >> >> below? > >> >> > >> >> VIRTIO_F_ACCESS_PLATFORM_NO_IOMMU This feature has the same meaning as > >> >> VIRTIO_F_ACCESS_PLATFORM both when set and when not set, with the > >> >> exception that the IOMMU is explicitly defined to be off or bypassed > >> >> when accessing memory addresses supplied to the device by the > >> >> driver. This flag should be set by the guest if offered, but to > >> >> allow for backward-compatibility device implementations allow for it > >> >> to be left unset by the guest. It is an error to set both this flag > >> >> and VIRTIO_F_ACCESS_PLATFORM. > >> > > >> > It looks kind of narrow but it's an option. > >> > >> Great! > >> > >> > I wonder how we'll define what's an iommu though. > >> > >> Hm, it didn't occur to me it could be an issue. I'll try. > > I rephrased it in terms of address translation. What do you think of > this version? The flag name is slightly different too: > > > VIRTIO_F_ACCESS_PLATFORM_NO_TRANSLATION This feature has the same > meaning as VIRTIO_F_ACCESS_PLATFORM both when set and when not set, > with the exception that address translation is guaranteed to be > unnecessary when accessing memory addresses supplied to the device > by the driver. Which is to say, the device will always use physical > addresses matching addresses used by the driver (typically meaning > physical addresses used by the CPU) and not translated further. This > flag should be set by the
Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted
David Gibson writes: > On Sat, Mar 23, 2019 at 05:01:35PM -0400, Michael S. Tsirkin wrote: >> On Thu, Mar 21, 2019 at 09:05:04PM -0300, Thiago Jung Bauermann wrote: >> > Michael S. Tsirkin writes: > [snip] >> > >> > Is there any justification to doing that beyond someone putting >> > >> > out slow code in the past? >> > >> >> > >> The definition of the ACCESS_PLATFORM flag is generic and captures the >> > >> notion of memory access restrictions for the device. Unfortunately, on >> > >> powerpc pSeries guests it also implies that the IOMMU is turned on >> > > >> > > IIUC that's really because on pSeries IOMMU is *always* turned on. >> > > Platform has no way to say what you want it to say >> > > which is bypass the iommu for the specific device. >> > >> > Yes, that's correct. pSeries guests running on KVM are in a gray area >> > where theoretically they use an IOMMU but in practice KVM ignores it. >> > It's unfortunate but it's the reality on the ground today. :-/ > > Um.. I'm not sure what you mean by this. As far as I'm concerned > there is always a guest-visible (paravirtualized) IOMMU, and that will > be backed onto the host IOMMU when necessary. There is, but vhost will ignore it and directly map the guest memory when ACCESS_PLATFORM (the flag previously known as IOMMU_PLATFORM) isn't set. From QEMU's hw/virtio/vhost.c: static int vhost_dev_has_iommu(struct vhost_dev *dev) { VirtIODevice *vdev = dev->vdev; return virtio_host_has_feature(vdev, VIRTIO_F_IOMMU_PLATFORM); } static void *vhost_memory_map(struct vhost_dev *dev, hwaddr addr, hwaddr *plen, int is_write) { if (!vhost_dev_has_iommu(dev)) { return cpu_physical_memory_map(addr, plen, is_write); } else { return (void *)(uintptr_t)addr; } } -- Thiago Jung Bauermann IBM Linux Technology Center
Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted
Michael S. Tsirkin writes: > On Thu, Mar 21, 2019 at 09:05:04PM -0300, Thiago Jung Bauermann wrote: >> >> Michael S. Tsirkin writes: >> >> > On Wed, Mar 20, 2019 at 01:13:41PM -0300, Thiago Jung Bauermann wrote: >> >> >From what I understand of the ACCESS_PLATFORM definition, the host will >> >> only ever try to access memory addresses that are supplied to it by the >> >> guest, so all of the secure guest memory that the host cares about is >> >> accessible: >> >> >> >> If this feature bit is set to 0, then the device has same access to >> >> memory addresses supplied to it as the driver has. In particular, >> >> the device will always use physical addresses matching addresses >> >> used by the driver (typically meaning physical addresses used by the >> >> CPU) and not translated further, and can access any address supplied >> >> to it by the driver. When clear, this overrides any >> >> platform-specific description of whether device access is limited or >> >> translated in any way, e.g. whether an IOMMU may be present. >> >> >> >> All of the above is true for POWER guests, whether they are secure >> >> guests or not. >> >> >> >> Or are you saying that a virtio device may want to access memory >> >> addresses that weren't supplied to it by the driver? >> > >> > Your logic would apply to IOMMUs as well. For your mode, there are >> > specific encrypted memory regions that driver has access to but device >> > does not. that seems to violate the constraint. >> >> Right, if there's a pre-configured 1:1 mapping in the IOMMU such that >> the device can ignore the IOMMU for all practical purposes I would >> indeed say that the logic would apply to IOMMUs as well. :-) >> >> I guess I'm still struggling with the purpose of signalling to the >> driver that the host may not have access to memory addresses that it >> will never try to access. > > For example, one of the benefits is to signal to host that driver does > not expect ability to access all memory. If it does, host can > fail initialization gracefully. But why would the ability to access all memory be necessary or even useful? When would the host access memory that the driver didn't tell it to access? >> >> >> > But the name "sev_active" makes me scared because at least AMD guys >> >> >> > who >> >> >> > were doing the sensible thing and setting ACCESS_PLATFORM >> >> >> >> >> >> My understanding is, AMD guest-platform knows in advance that their >> >> >> guest will run in secure mode and hence sets the flag at the time of VM >> >> >> instantiation. Unfortunately we dont have that luxury on our platforms. >> >> > >> >> > Well you do have that luxury. It looks like that there are existing >> >> > guests that already acknowledge ACCESS_PLATFORM and you are not happy >> >> > with how that path is slow. So you are trying to optimize for >> >> > them by clearing ACCESS_PLATFORM and then you have lost ability >> >> > to invoke DMA API. >> >> > >> >> > For example if there was another flag just like ACCESS_PLATFORM >> >> > just not yet used by anyone, you would be all fine using that right? >> >> >> >> Yes, a new flag sounds like a great idea. What about the definition >> >> below? >> >> >> >> VIRTIO_F_ACCESS_PLATFORM_NO_IOMMU This feature has the same meaning as >> >> VIRTIO_F_ACCESS_PLATFORM both when set and when not set, with the >> >> exception that the IOMMU is explicitly defined to be off or bypassed >> >> when accessing memory addresses supplied to the device by the >> >> driver. This flag should be set by the guest if offered, but to >> >> allow for backward-compatibility device implementations allow for it >> >> to be left unset by the guest. It is an error to set both this flag >> >> and VIRTIO_F_ACCESS_PLATFORM. >> > >> > It looks kind of narrow but it's an option. >> >> Great! >> >> > I wonder how we'll define what's an iommu though. >> >> Hm, it didn't occur to me it could be an issue. I'll try. I rephrased it in terms of address translation. What do you think of this version? The flag name is slightly different too: VIRTIO_F_ACCESS_PLATFORM_NO_TRANSLATION This feature has the same meaning as VIRTIO_F_ACCESS_PLATFORM both when set and when not set, with the exception that address translation is guaranteed to be unnecessary when accessing memory addresses supplied to the device by the driver. Which is to say, the device will always use physical addresses matching addresses used by the driver (typically meaning physical addresses used by the CPU) and not translated further. This flag should be set by the guest if offered, but to allow for backward-compatibility device implementations allow for it to be left unset by the guest. It is an error to set both this flag and VIRTIO_F_ACCESS_PLATFORM. >> > Another idea is maybe something like virtio-iommu? >> >> You mean, have legacy guests use virtio-iommu to request an IOMMU >> bypass? If so, it's an
Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted
On Wed, Jan 30, 2019 at 08:44:27AM +0100, Christoph Hellwig wrote: > On Tue, Jan 29, 2019 at 09:36:08PM -0500, Michael S. Tsirkin wrote: > > This has been discussed ad nauseum. virtio is all about compatibility. > > Losing a couple of lines of code isn't worth breaking working setups. > > People that want "just use DMA API no tricks" now have the option. > > Setting a flag in a feature bit map is literally a single line > > of code in the hypervisor. So stop pushing for breaking working > > legacy setups and just fix it in the right place. > > I agree with the legacy aspect. What I am missing is an extremely > strong wording that says you SHOULD always set this flag for new > hosts, including an explanation why. So as far as power is concerned, IIUC the issue they are struggling with is that some platforms do not support pass-through mode in the emulated IOMMU. Disabling PLATFORM_ACCESS is so far a way around that, unfortunately just for virtio devices. I would like virtio-iommu to be able to address that need as well. -- MST
Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted
On Sat, Mar 23, 2019 at 05:01:35PM -0400, Michael S. Tsirkin wrote: > On Thu, Mar 21, 2019 at 09:05:04PM -0300, Thiago Jung Bauermann wrote: > > Michael S. Tsirkin writes: [snip] > > >> > Is there any justification to doing that beyond someone putting > > >> > out slow code in the past? > > >> > > >> The definition of the ACCESS_PLATFORM flag is generic and captures the > > >> notion of memory access restrictions for the device. Unfortunately, on > > >> powerpc pSeries guests it also implies that the IOMMU is turned on > > > > > > IIUC that's really because on pSeries IOMMU is *always* turned on. > > > Platform has no way to say what you want it to say > > > which is bypass the iommu for the specific device. > > > > Yes, that's correct. pSeries guests running on KVM are in a gray area > > where theoretically they use an IOMMU but in practice KVM ignores it. > > It's unfortunate but it's the reality on the ground today. :-/ Um.. I'm not sure what you mean by this. As far as I'm concerned there is always a guest-visible (paravirtualized) IOMMU, and that will be backed onto the host IOMMU when necessary. [Actually there is an IOMMU bypass hack that's used by the guest firmware, but I don't think we want to expose that] > Well it's not just the reality, virt setups need something that > emulated IOMMUs don't provide. That is not uncommon, e.g. > intel's VTD has a "cache mode" field which AFAIK is only used for virt. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: PGP signature
Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted
On Thu, Mar 21, 2019 at 09:05:04PM -0300, Thiago Jung Bauermann wrote: > > Michael S. Tsirkin writes: > > > On Wed, Mar 20, 2019 at 01:13:41PM -0300, Thiago Jung Bauermann wrote: > >> >> Another way of looking at this issue which also explains our reluctance > >> >> is that the only difference between a secure guest and a regular guest > >> >> (at least regarding virtio) is that the former uses swiotlb while the > >> >> latter doens't. > >> > > >> > But swiotlb is just one implementation. It's a guest internal thing. The > >> > issue is that memory isn't host accessible. > >> > >> >From what I understand of the ACCESS_PLATFORM definition, the host will > >> only ever try to access memory addresses that are supplied to it by the > >> guest, so all of the secure guest memory that the host cares about is > >> accessible: > >> > >> If this feature bit is set to 0, then the device has same access to > >> memory addresses supplied to it as the driver has. In particular, > >> the device will always use physical addresses matching addresses > >> used by the driver (typically meaning physical addresses used by the > >> CPU) and not translated further, and can access any address supplied > >> to it by the driver. When clear, this overrides any > >> platform-specific description of whether device access is limited or > >> translated in any way, e.g. whether an IOMMU may be present. > >> > >> All of the above is true for POWER guests, whether they are secure > >> guests or not. > >> > >> Or are you saying that a virtio device may want to access memory > >> addresses that weren't supplied to it by the driver? > > > > Your logic would apply to IOMMUs as well. For your mode, there are > > specific encrypted memory regions that driver has access to but device > > does not. that seems to violate the constraint. > > Right, if there's a pre-configured 1:1 mapping in the IOMMU such that > the device can ignore the IOMMU for all practical purposes I would > indeed say that the logic would apply to IOMMUs as well. :-) > > I guess I'm still struggling with the purpose of signalling to the > driver that the host may not have access to memory addresses that it > will never try to access. For example, one of the benefits is to signal to host that driver does not expect ability to access all memory. If it does, host can fail initialization gracefully. > >> >> And from the device's point of view they're > >> >> indistinguishable. It can't tell one guest that is using swiotlb from > >> >> one that isn't. And that implies that secure guest vs regular guest > >> >> isn't a virtio interface issue, it's "guest internal affairs". So > >> >> there's no reason to reflect that in the feature flags. > >> > > >> > So don't. The way not to reflect that in the feature flags is > >> > to set ACCESS_PLATFORM. Then you say *I don't care let platform device*. > >> > > >> > > >> > Without ACCESS_PLATFORM > >> > virtio has a very specific opinion about the security of the > >> > device, and that opinion is that device is part of the guest > >> > supervisor security domain. > >> > >> Sorry for being a bit dense, but not sure what "the device is part of > >> the guest supervisor security domain" means. In powerpc-speak, > >> "supervisor" is the operating system so perhaps that explains my > >> confusion. Are you saying that without ACCESS_PLATFORM, the guest > >> considers the host to be part of the guest operating system's security > >> domain? > > > > I think so. The spec says "device has same access as driver". > > Ok, makes sense. > > >> If so, does that have any other implication besides "the host > >> can access any address supplied to it by the driver"? If that is the > >> case, perhaps the definition of ACCESS_PLATFORM needs to be amended to > >> include that information because it's not part of the current > >> definition. > >> > >> >> > But the name "sev_active" makes me scared because at least AMD guys > >> >> > who > >> >> > were doing the sensible thing and setting ACCESS_PLATFORM > >> >> > >> >> My understanding is, AMD guest-platform knows in advance that their > >> >> guest will run in secure mode and hence sets the flag at the time of VM > >> >> instantiation. Unfortunately we dont have that luxury on our platforms. > >> > > >> > Well you do have that luxury. It looks like that there are existing > >> > guests that already acknowledge ACCESS_PLATFORM and you are not happy > >> > with how that path is slow. So you are trying to optimize for > >> > them by clearing ACCESS_PLATFORM and then you have lost ability > >> > to invoke DMA API. > >> > > >> > For example if there was another flag just like ACCESS_PLATFORM > >> > just not yet used by anyone, you would be all fine using that right? > >> > >> Yes, a new flag sounds like a great idea. What about the definition > >> below? > >> > >> VIRTIO_F_ACCESS_PLATFORM_NO_IOMMU This feature has the same meaning as > >> VIRTIO_F_ACCESS_PLATFORM both
Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted
Michael S. Tsirkin writes: > On Wed, Mar 20, 2019 at 01:13:41PM -0300, Thiago Jung Bauermann wrote: >> >> Another way of looking at this issue which also explains our reluctance >> >> is that the only difference between a secure guest and a regular guest >> >> (at least regarding virtio) is that the former uses swiotlb while the >> >> latter doens't. >> > >> > But swiotlb is just one implementation. It's a guest internal thing. The >> > issue is that memory isn't host accessible. >> >> >From what I understand of the ACCESS_PLATFORM definition, the host will >> only ever try to access memory addresses that are supplied to it by the >> guest, so all of the secure guest memory that the host cares about is >> accessible: >> >> If this feature bit is set to 0, then the device has same access to >> memory addresses supplied to it as the driver has. In particular, >> the device will always use physical addresses matching addresses >> used by the driver (typically meaning physical addresses used by the >> CPU) and not translated further, and can access any address supplied >> to it by the driver. When clear, this overrides any >> platform-specific description of whether device access is limited or >> translated in any way, e.g. whether an IOMMU may be present. >> >> All of the above is true for POWER guests, whether they are secure >> guests or not. >> >> Or are you saying that a virtio device may want to access memory >> addresses that weren't supplied to it by the driver? > > Your logic would apply to IOMMUs as well. For your mode, there are > specific encrypted memory regions that driver has access to but device > does not. that seems to violate the constraint. Right, if there's a pre-configured 1:1 mapping in the IOMMU such that the device can ignore the IOMMU for all practical purposes I would indeed say that the logic would apply to IOMMUs as well. :-) I guess I'm still struggling with the purpose of signalling to the driver that the host may not have access to memory addresses that it will never try to access. >> >> And from the device's point of view they're >> >> indistinguishable. It can't tell one guest that is using swiotlb from >> >> one that isn't. And that implies that secure guest vs regular guest >> >> isn't a virtio interface issue, it's "guest internal affairs". So >> >> there's no reason to reflect that in the feature flags. >> > >> > So don't. The way not to reflect that in the feature flags is >> > to set ACCESS_PLATFORM. Then you say *I don't care let platform device*. >> > >> > >> > Without ACCESS_PLATFORM >> > virtio has a very specific opinion about the security of the >> > device, and that opinion is that device is part of the guest >> > supervisor security domain. >> >> Sorry for being a bit dense, but not sure what "the device is part of >> the guest supervisor security domain" means. In powerpc-speak, >> "supervisor" is the operating system so perhaps that explains my >> confusion. Are you saying that without ACCESS_PLATFORM, the guest >> considers the host to be part of the guest operating system's security >> domain? > > I think so. The spec says "device has same access as driver". Ok, makes sense. >> If so, does that have any other implication besides "the host >> can access any address supplied to it by the driver"? If that is the >> case, perhaps the definition of ACCESS_PLATFORM needs to be amended to >> include that information because it's not part of the current >> definition. >> >> >> > But the name "sev_active" makes me scared because at least AMD guys who >> >> > were doing the sensible thing and setting ACCESS_PLATFORM >> >> >> >> My understanding is, AMD guest-platform knows in advance that their >> >> guest will run in secure mode and hence sets the flag at the time of VM >> >> instantiation. Unfortunately we dont have that luxury on our platforms. >> > >> > Well you do have that luxury. It looks like that there are existing >> > guests that already acknowledge ACCESS_PLATFORM and you are not happy >> > with how that path is slow. So you are trying to optimize for >> > them by clearing ACCESS_PLATFORM and then you have lost ability >> > to invoke DMA API. >> > >> > For example if there was another flag just like ACCESS_PLATFORM >> > just not yet used by anyone, you would be all fine using that right? >> >> Yes, a new flag sounds like a great idea. What about the definition >> below? >> >> VIRTIO_F_ACCESS_PLATFORM_NO_IOMMU This feature has the same meaning as >> VIRTIO_F_ACCESS_PLATFORM both when set and when not set, with the >> exception that the IOMMU is explicitly defined to be off or bypassed >> when accessing memory addresses supplied to the device by the >> driver. This flag should be set by the guest if offered, but to >> allow for backward-compatibility device implementations allow for it >> to be left unset by the guest. It is an error to set both this flag >> and VIRTIO_F_ACCESS_PLATFORM.
Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted
On Wed, Mar 20, 2019 at 01:13:41PM -0300, Thiago Jung Bauermann wrote: > >> Another way of looking at this issue which also explains our reluctance > >> is that the only difference between a secure guest and a regular guest > >> (at least regarding virtio) is that the former uses swiotlb while the > >> latter doens't. > > > > But swiotlb is just one implementation. It's a guest internal thing. The > > issue is that memory isn't host accessible. > > >From what I understand of the ACCESS_PLATFORM definition, the host will > only ever try to access memory addresses that are supplied to it by the > guest, so all of the secure guest memory that the host cares about is > accessible: > > If this feature bit is set to 0, then the device has same access to > memory addresses supplied to it as the driver has. In particular, > the device will always use physical addresses matching addresses > used by the driver (typically meaning physical addresses used by the > CPU) and not translated further, and can access any address supplied > to it by the driver. When clear, this overrides any > platform-specific description of whether device access is limited or > translated in any way, e.g. whether an IOMMU may be present. > > All of the above is true for POWER guests, whether they are secure > guests or not. > > Or are you saying that a virtio device may want to access memory > addresses that weren't supplied to it by the driver? Your logic would apply to IOMMUs as well. For your mode, there are specific encrypted memory regions that driver has access to but device does not. that seems to violate the constraint. > >> And from the device's point of view they're > >> indistinguishable. It can't tell one guest that is using swiotlb from > >> one that isn't. And that implies that secure guest vs regular guest > >> isn't a virtio interface issue, it's "guest internal affairs". So > >> there's no reason to reflect that in the feature flags. > > > > So don't. The way not to reflect that in the feature flags is > > to set ACCESS_PLATFORM. Then you say *I don't care let platform device*. > > > > > > Without ACCESS_PLATFORM > > virtio has a very specific opinion about the security of the > > device, and that opinion is that device is part of the guest > > supervisor security domain. > > Sorry for being a bit dense, but not sure what "the device is part of > the guest supervisor security domain" means. In powerpc-speak, > "supervisor" is the operating system so perhaps that explains my > confusion. Are you saying that without ACCESS_PLATFORM, the guest > considers the host to be part of the guest operating system's security > domain? I think so. The spec says "device has same access as driver". > If so, does that have any other implication besides "the host > can access any address supplied to it by the driver"? If that is the > case, perhaps the definition of ACCESS_PLATFORM needs to be amended to > include that information because it's not part of the current > definition. > > >> That said, we still would like to arrive at a proper design for this > >> rather than add yet another hack if we can avoid it. So here's another > >> proposal: considering that the dma-direct code (in kernel/dma/direct.c) > >> automatically uses swiotlb when necessary (thanks to Christoph's recent > >> DMA work), would it be ok to replace virtio's own direct-memory code > >> that is used in the !ACCESS_PLATFORM case with the dma-direct code? That > >> way we'll get swiotlb even with !ACCESS_PLATFORM, and virtio will get a > >> code cleanup (replace open-coded stuff with calls to existing > >> infrastructure). > > > > Let's say I have some doubts that there's an API that > > matches what virtio with its bag of legacy compatibility exactly. > > Ok. > > >> > But the name "sev_active" makes me scared because at least AMD guys who > >> > were doing the sensible thing and setting ACCESS_PLATFORM > >> > >> My understanding is, AMD guest-platform knows in advance that their > >> guest will run in secure mode and hence sets the flag at the time of VM > >> instantiation. Unfortunately we dont have that luxury on our platforms. > > > > Well you do have that luxury. It looks like that there are existing > > guests that already acknowledge ACCESS_PLATFORM and you are not happy > > with how that path is slow. So you are trying to optimize for > > them by clearing ACCESS_PLATFORM and then you have lost ability > > to invoke DMA API. > > > > For example if there was another flag just like ACCESS_PLATFORM > > just not yet used by anyone, you would be all fine using that right? > > Yes, a new flag sounds like a great idea. What about the definition > below? > > VIRTIO_F_ACCESS_PLATFORM_NO_IOMMU This feature has the same meaning as > VIRTIO_F_ACCESS_PLATFORM both when set and when not set, with the > exception that the IOMMU is explicitly defined to be off or bypassed > when accessing memory addresses supplied to
Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted
Hello Michael, Sorry for the delay in responding. We had some internal discussions on this. Michael S. Tsirkin writes: > On Mon, Feb 04, 2019 at 04:14:20PM -0200, Thiago Jung Bauermann wrote: >> >> Hello Michael, >> >> Michael S. Tsirkin writes: >> >> > On Tue, Jan 29, 2019 at 03:42:44PM -0200, Thiago Jung Bauermann wrote: >> So while ACCESS_PLATFORM solves our problems for secure guests, we can't >> turn it on by default because we can't affect legacy systems. Doing so >> would penalize existing systems that can access all memory. They would >> all have to unnecessarily go through address translations, and take a >> performance hit. > > So as step one, you just give hypervisor admin an option to run legacy > systems faster by blocking secure mode. I don't see why that is > so terrible. There are a few reasons why: 1. It's bad user experience to require people to fiddle with knobs for obscure reasons if it's possible to design things such that they Just Work. 2. "User" in this case can be a human directly calling QEMU, but could also be libvirt or one of its users, or some other framework. This means having to adjust and/or educate an open-ended number of people and software. It's best avoided if possible. 3. The hypervisor admin and the admin of the guest system don't necessarily belong to the same organization (e.g., cloud provider and cloud customer), so there may be some friction when they need to coordinate to get this right. 4. A feature of our design is that the guest may or may not decide to "go secure" at boot time, so it's best not to depend on flags that may or may not have been set at the time QEMU was started. >> The semantics of ACCESS_PLATFORM assume that the hypervisor/QEMU knows >> in advance - right when the VM is instantiated - that it will not have >> access to all guest memory. > > Not quite. It just means that hypervisor can live with not having > access to all memory. If platform wants to give it access > to all memory that is quite all right. Except that on powerpc it also means "there's an IOMMU present" and there's no way to say "bypass IOMMU translation". :-/ >> Another way of looking at this issue which also explains our reluctance >> is that the only difference between a secure guest and a regular guest >> (at least regarding virtio) is that the former uses swiotlb while the >> latter doens't. > > But swiotlb is just one implementation. It's a guest internal thing. The > issue is that memory isn't host accessible. >From what I understand of the ACCESS_PLATFORM definition, the host will only ever try to access memory addresses that are supplied to it by the guest, so all of the secure guest memory that the host cares about is accessible: If this feature bit is set to 0, then the device has same access to memory addresses supplied to it as the driver has. In particular, the device will always use physical addresses matching addresses used by the driver (typically meaning physical addresses used by the CPU) and not translated further, and can access any address supplied to it by the driver. When clear, this overrides any platform-specific description of whether device access is limited or translated in any way, e.g. whether an IOMMU may be present. All of the above is true for POWER guests, whether they are secure guests or not. Or are you saying that a virtio device may want to access memory addresses that weren't supplied to it by the driver? >> And from the device's point of view they're >> indistinguishable. It can't tell one guest that is using swiotlb from >> one that isn't. And that implies that secure guest vs regular guest >> isn't a virtio interface issue, it's "guest internal affairs". So >> there's no reason to reflect that in the feature flags. > > So don't. The way not to reflect that in the feature flags is > to set ACCESS_PLATFORM. Then you say *I don't care let platform device*. > > > Without ACCESS_PLATFORM > virtio has a very specific opinion about the security of the > device, and that opinion is that device is part of the guest > supervisor security domain. Sorry for being a bit dense, but not sure what "the device is part of the guest supervisor security domain" means. In powerpc-speak, "supervisor" is the operating system so perhaps that explains my confusion. Are you saying that without ACCESS_PLATFORM, the guest considers the host to be part of the guest operating system's security domain? If so, does that have any other implication besides "the host can access any address supplied to it by the driver"? If that is the case, perhaps the definition of ACCESS_PLATFORM needs to be amended to include that information because it's not part of the current definition. >> That said, we still would like to arrive at a proper design for this >> rather than add yet another hack if we can avoid it. So here's another >> proposal: considering that the dma-direct code (in kernel/dma/direct.c) >> automatically uses
Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted
On Tue, Feb 05, 2019 at 08:24:07AM +0100, Christoph Hellwig wrote: > On Mon, Feb 04, 2019 at 04:38:21PM -0500, Michael S. Tsirkin wrote: > > It was designed to make, when set, as many guests as we can work > > correctly, and it seems to be successful in doing exactly that. > > > > Unfortunately there could be legacy guests that do work correctly but > > become slow. Whether trying to somehow work around that > > can paint us into a corner where things again don't > > work for some people is a question worth discussing. > > The other problem is that some qemu machines just throw passthrough > devices and virtio devices on the same virtual PCI(e) bus, and have a > common IOMMU setup for the whole bus / root port / domain. I think > this is completely bogus, but unfortunately it is out in the field. > > Given that power is one of these examples I suspect that is what > Thiago referes to. But in this case the answer can't be that we > pile on hack ontop of another, but instead introduce a new qemu > machine that separates these clearly, and make that mandatory for > the secure guest support. That could we one approach, assuming one exists that guests already support. -- MST
Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted
On Mon, Feb 04, 2019 at 04:38:21PM -0500, Michael S. Tsirkin wrote: > It was designed to make, when set, as many guests as we can work > correctly, and it seems to be successful in doing exactly that. > > Unfortunately there could be legacy guests that do work correctly but > become slow. Whether trying to somehow work around that > can paint us into a corner where things again don't > work for some people is a question worth discussing. The other problem is that some qemu machines just throw passthrough devices and virtio devices on the same virtual PCI(e) bus, and have a common IOMMU setup for the whole bus / root port / domain. I think this is completely bogus, but unfortunately it is out in the field. Given that power is one of these examples I suspect that is what Thiago referes to. But in this case the answer can't be that we pile on hack ontop of another, but instead introduce a new qemu machine that separates these clearly, and make that mandatory for the secure guest support.
Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted
On Mon, Feb 04, 2019 at 04:15:41PM -0200, Thiago Jung Bauermann wrote: > > Christoph Hellwig writes: > > > On Tue, Jan 29, 2019 at 09:36:08PM -0500, Michael S. Tsirkin wrote: > >> This has been discussed ad nauseum. virtio is all about compatibility. > >> Losing a couple of lines of code isn't worth breaking working setups. > >> People that want "just use DMA API no tricks" now have the option. > >> Setting a flag in a feature bit map is literally a single line > >> of code in the hypervisor. So stop pushing for breaking working > >> legacy setups and just fix it in the right place. > > > > I agree with the legacy aspect. What I am missing is an extremely > > strong wording that says you SHOULD always set this flag for new > > hosts, including an explanation why. > > My understanding of ACCESS_PLATFORM is that it means "this device will > behave in all aspects like a regular device attached to this bus". Not really. Look it up in the spec: VIRTIO_F_ACCESS_PLATFORM(33) This feature indicates that the device can be used on a platform where device access to data in memory is limited and/or translated. E.g. this is the case if the device can be located behind an IOMMU that translates bus addresses from the device into physical addresses in memory, if the device can be limited to only access certain memory addresses or if special commands such as a cache flush can be needed to synchronise data in memory with the device. Whether accesses are actually limited or translated is described by platform-specific means. If this feature bit is set to 0, then the device has same access to memory addresses supplied to it as the driver has. In particular, the device will always use physical addresses matching addresses used by the driver (typically meaning physical addresses used by the CPU) and not translated further, and can access any address supplied to it by the driver. When clear, this overrides any platform-specific description of whether device access is limited or translated in any way, e.g. whether an IOMMU may be present. > Is > that it? Therefore it should be set because it's the sane thing to do? It's the sane thing to do unless you want the very specific thing that having it clear means, which is just have it be another CPU. It was designed to make, when set, as many guests as we can work correctly, and it seems to be successful in doing exactly that. Unfortunately there could be legacy guests that do work correctly but become slow. Whether trying to somehow work around that can paint us into a corner where things again don't work for some people is a question worth discussing. > -- > Thiago Jung Bauermann > IBM Linux Technology Center
Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted
On Mon, Feb 04, 2019 at 04:14:20PM -0200, Thiago Jung Bauermann wrote: > > Hello Michael, > > Michael S. Tsirkin writes: > > > On Tue, Jan 29, 2019 at 03:42:44PM -0200, Thiago Jung Bauermann wrote: > >> > >> Fixing address of powerpc mailing list. > >> > >> Thiago Jung Bauermann writes: > >> > >> > Hello, > >> > > >> > With Christoph's rework of the DMA API that recently landed, the patch > >> > below is the only change needed in virtio to make it work in a POWER > >> > secure guest under the ultravisor. > >> > > >> > The other change we need (making sure the device's dma_map_ops is NULL > >> > so that the dma-direct/swiotlb code is used) can be made in > >> > powerpc-specific code. > >> > > >> > Of course, I also have patches (soon to be posted as RFC) which hook up > >> > to the powerpc secure guest support code. > >> > > >> > What do you think? > >> > > >> > From d0629a36a75c678b4a72b853f8f7f8c17eedd6b3 Mon Sep 17 00:00:00 2001 > >> > From: Thiago Jung Bauermann > >> > Date: Thu, 24 Jan 2019 22:08:02 -0200 > >> > Subject: [RFC PATCH] virtio_ring: Use DMA API if guest memory is > >> > encrypted > >> > > >> > The host can't access the guest memory when it's encrypted, so using > >> > regular memory pages for the ring isn't an option. Go through the DMA > >> > API. > >> > > >> > Signed-off-by: Thiago Jung Bauermann > > > > Well I think this will come back to bite us (witness xen which is now > > reworking precisely this path - but at least they aren't to blame, xen > > came before ACCESS_PLATFORM). > > > > I also still think the right thing would have been to set > > ACCESS_PLATFORM for all systems where device can't access all memory. > > I understand. The problem with that approach for us is that because we > don't know which guests will become secure guests and which will remain > regular guests, QEMU would need to offer ACCESS_PLATFORM to all guests. > > And the problem with that is that for QEMU on POWER, having > ACCESS_PLATFORM turned off means that it can bypass the IOMMU for the > device (which makes sense considering that the name of the flag was > IOMMU_PLATFORM). And we need that for regular guests to avoid > performance degradation. You don't really, ACCESS_PLATFORM means just that, platform decides. > So while ACCESS_PLATFORM solves our problems for secure guests, we can't > turn it on by default because we can't affect legacy systems. Doing so > would penalize existing systems that can access all memory. They would > all have to unnecessarily go through address translations, and take a > performance hit. So as step one, you just give hypervisor admin an option to run legacy systems faster by blocking secure mode. I don't see why that is so terrible. But as step two, assuming you use above step one to make legacy guests go fast - maybe there is a point in detecting such a hypervisor and doing something smarter with it. By all means let's have a discussion around this but that is no longer "to make it work" as the commit log says it's more a performance optimization. > The semantics of ACCESS_PLATFORM assume that the hypervisor/QEMU knows > in advance - right when the VM is instantiated - that it will not have > access to all guest memory. Not quite. It just means that hypervisor can live with not having access to all memory. If platform wants to give it access to all memory that is quite all right. > Unfortunately that assumption is subtly > broken on our secure-platform. The hypervisor/QEMU realizes that the > platform is going secure only *after the VM is instantiated*. It's the > kernel running in the VM that determines that it wants to switch the > platform to secure-mode. ACCESS_PLATFORM is there so guests can detect legacy hypervisors which always assumed it's another CPU. > Another way of looking at this issue which also explains our reluctance > is that the only difference between a secure guest and a regular guest > (at least regarding virtio) is that the former uses swiotlb while the > latter doens't. But swiotlb is just one implementation. It's a guest internal thing. The issue is that memory isn't host accessible. Yes linux does not use that info too much right now but it already begins to seep out of the abstraction. For example as you are doing data copies you should maybe calculate the packet checksum just as well. Not something DMA API will let you know right now, but that's because any bounce buffer users so far weren't terribly fast a
Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted
Christoph Hellwig writes: > On Tue, Jan 29, 2019 at 09:36:08PM -0500, Michael S. Tsirkin wrote: >> This has been discussed ad nauseum. virtio is all about compatibility. >> Losing a couple of lines of code isn't worth breaking working setups. >> People that want "just use DMA API no tricks" now have the option. >> Setting a flag in a feature bit map is literally a single line >> of code in the hypervisor. So stop pushing for breaking working >> legacy setups and just fix it in the right place. > > I agree with the legacy aspect. What I am missing is an extremely > strong wording that says you SHOULD always set this flag for new > hosts, including an explanation why. My understanding of ACCESS_PLATFORM is that it means "this device will behave in all aspects like a regular device attached to this bus". Is that it? Therefore it should be set because it's the sane thing to do? -- Thiago Jung Bauermann IBM Linux Technology Center
Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted
Hello Michael, Michael S. Tsirkin writes: > On Tue, Jan 29, 2019 at 03:42:44PM -0200, Thiago Jung Bauermann wrote: >> >> Fixing address of powerpc mailing list. >> >> Thiago Jung Bauermann writes: >> >> > Hello, >> > >> > With Christoph's rework of the DMA API that recently landed, the patch >> > below is the only change needed in virtio to make it work in a POWER >> > secure guest under the ultravisor. >> > >> > The other change we need (making sure the device's dma_map_ops is NULL >> > so that the dma-direct/swiotlb code is used) can be made in >> > powerpc-specific code. >> > >> > Of course, I also have patches (soon to be posted as RFC) which hook up >> > to the powerpc secure guest support code. >> > >> > What do you think? >> > >> > From d0629a36a75c678b4a72b853f8f7f8c17eedd6b3 Mon Sep 17 00:00:00 2001 >> > From: Thiago Jung Bauermann >> > Date: Thu, 24 Jan 2019 22:08:02 -0200 >> > Subject: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted >> > >> > The host can't access the guest memory when it's encrypted, so using >> > regular memory pages for the ring isn't an option. Go through the DMA API. >> > >> > Signed-off-by: Thiago Jung Bauermann > > Well I think this will come back to bite us (witness xen which is now > reworking precisely this path - but at least they aren't to blame, xen > came before ACCESS_PLATFORM). > > I also still think the right thing would have been to set > ACCESS_PLATFORM for all systems where device can't access all memory. I understand. The problem with that approach for us is that because we don't know which guests will become secure guests and which will remain regular guests, QEMU would need to offer ACCESS_PLATFORM to all guests. And the problem with that is that for QEMU on POWER, having ACCESS_PLATFORM turned off means that it can bypass the IOMMU for the device (which makes sense considering that the name of the flag was IOMMU_PLATFORM). And we need that for regular guests to avoid performance degradation. So while ACCESS_PLATFORM solves our problems for secure guests, we can't turn it on by default because we can't affect legacy systems. Doing so would penalize existing systems that can access all memory. They would all have to unnecessarily go through address translations, and take a performance hit. The semantics of ACCESS_PLATFORM assume that the hypervisor/QEMU knows in advance - right when the VM is instantiated - that it will not have access to all guest memory. Unfortunately that assumption is subtly broken on our secure-platform. The hypervisor/QEMU realizes that the platform is going secure only *after the VM is instantiated*. It's the kernel running in the VM that determines that it wants to switch the platform to secure-mode. Another way of looking at this issue which also explains our reluctance is that the only difference between a secure guest and a regular guest (at least regarding virtio) is that the former uses swiotlb while the latter doens't. And from the device's point of view they're indistinguishable. It can't tell one guest that is using swiotlb from one that isn't. And that implies that secure guest vs regular guest isn't a virtio interface issue, it's "guest internal affairs". So there's no reason to reflect that in the feature flags. That said, we still would like to arrive at a proper design for this rather than add yet another hack if we can avoid it. So here's another proposal: considering that the dma-direct code (in kernel/dma/direct.c) automatically uses swiotlb when necessary (thanks to Christoph's recent DMA work), would it be ok to replace virtio's own direct-memory code that is used in the !ACCESS_PLATFORM case with the dma-direct code? That way we'll get swiotlb even with !ACCESS_PLATFORM, and virtio will get a code cleanup (replace open-coded stuff with calls to existing infrastructure). > But I also think I don't have the energy to argue about power secure > guest anymore. So be it for power secure guest since the involved > engineers disagree with me. Hey I've been wrong in the past ;). Yeah, it's been a difficult discussion. Thanks for still engaging! I honestly thought that this patch was a good solution (if the guest has encrypted memory it means that the DMA API needs to be used), but I can see where you are coming from. As I said, we'd like to arrive at a good solution if possible. > But the name "sev_active" makes me scared because at least AMD guys who > were doing the sensible thing and setting ACCESS_PLATFORM My understanding is, AMD guest-platform knows in advance that their guest will run in secure mode and hence sets the flag at the time of VM instantiation. Unfortunately
Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted
On Tue, Jan 29, 2019 at 09:36:08PM -0500, Michael S. Tsirkin wrote: > This has been discussed ad nauseum. virtio is all about compatibility. > Losing a couple of lines of code isn't worth breaking working setups. > People that want "just use DMA API no tricks" now have the option. > Setting a flag in a feature bit map is literally a single line > of code in the hypervisor. So stop pushing for breaking working > legacy setups and just fix it in the right place. I agree with the legacy aspect. What I am missing is an extremely strong wording that says you SHOULD always set this flag for new hosts, including an explanation why.
Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted
On Wed, Jan 30, 2019 at 11:05:42AM +0800, Jason Wang wrote: > > On 2019/1/30 上午10:36, Michael S. Tsirkin wrote: > > On Wed, Jan 30, 2019 at 10:24:01AM +0800, Jason Wang wrote: > > > On 2019/1/30 上午3:02, Michael S. Tsirkin wrote: > > > > On Tue, Jan 29, 2019 at 03:42:44PM -0200, Thiago Jung Bauermann wrote: > > > > > Fixing address of powerpc mailing list. > > > > > > > > > > Thiago Jung Bauermann writes: > > > > > > > > > > > Hello, > > > > > > > > > > > > With Christoph's rework of the DMA API that recently landed, the > > > > > > patch > > > > > > below is the only change needed in virtio to make it work in a POWER > > > > > > secure guest under the ultravisor. > > > > > > > > > > > > The other change we need (making sure the device's dma_map_ops is > > > > > > NULL > > > > > > so that the dma-direct/swiotlb code is used) can be made in > > > > > > powerpc-specific code. > > > > > > > > > > > > Of course, I also have patches (soon to be posted as RFC) which > > > > > > hook up > > > > > > to the powerpc secure guest support code. > > > > > > > > > > > > What do you think? > > > > > > > > > > > > From d0629a36a75c678b4a72b853f8f7f8c17eedd6b3 Mon Sep 17 00:00:00 > > > > > > 2001 > > > > > > From: Thiago Jung Bauermann > > > > > > Date: Thu, 24 Jan 2019 22:08:02 -0200 > > > > > > Subject: [RFC PATCH] virtio_ring: Use DMA API if guest memory is > > > > > > encrypted > > > > > > > > > > > > The host can't access the guest memory when it's encrypted, so using > > > > > > regular memory pages for the ring isn't an option. Go through the > > > > > > DMA API. > > > > > > > > > > > > Signed-off-by: Thiago Jung Bauermann > > > > Well I think this will come back to bite us (witness xen which is now > > > > reworking precisely this path - but at least they aren't to blame, xen > > > > came before ACCESS_PLATFORM). > > > > > > > > I also still think the right thing would have been to set > > > > ACCESS_PLATFORM for all systems where device can't access all memory. > > > > > > > > But I also think I don't have the energy to argue about power secure > > > > guest anymore. So be it for power secure guest since the involved > > > > engineers disagree with me. Hey I've been wrong in the past ;). > > > > > > > > But the name "sev_active" makes me scared because at least AMD guys who > > > > were doing the sensible thing and setting ACCESS_PLATFORM (unless I'm > > > > wrong? I reemember distinctly that's so) will likely be affected too. > > > > We don't want that. > > > > > > > > So let's find a way to make sure it's just power secure guest for now > > > > pls. > > > > > > > > I also think we should add a dma_api near features under virtio_device > > > > such that these hacks can move off data path. > > > > > > Anyway the current Xen code is conflict with spec which said: > > > > > > "If this feature bit is set to 0, then the device has same access to > > > memory > > > addresses supplied to it as the driver has. In particular, the device will > > > always use physical addresses matching addresses used by the driver > > > (typically meaning physical addresses used by the CPU) and not translated > > > further, and can access any address supplied to it by the driver. When > > > clear, this overrides any platform-specific description of whether device > > > access is limited or translated in any way, e.g. whether an IOMMU may be > > > present. " > > > > > > I wonder how much value that the above description can give us. It's kind > > > of > > > odd that the behavior of "when the feature is not negotiated" is described > > > in the spec. > > Hmm what's odd about it? We need to describe the behaviour is all cases. > > > Well, try to limit the behavior of 'legacy' driver is tricky or even > impossible. Xen is an exact example for this. So don't. Xen got grand-fathered in because when that came along we thought it's a one off thi
Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted
On 2019/1/30 上午10:36, Michael S. Tsirkin wrote: On Wed, Jan 30, 2019 at 10:24:01AM +0800, Jason Wang wrote: On 2019/1/30 上午3:02, Michael S. Tsirkin wrote: On Tue, Jan 29, 2019 at 03:42:44PM -0200, Thiago Jung Bauermann wrote: Fixing address of powerpc mailing list. Thiago Jung Bauermann writes: Hello, With Christoph's rework of the DMA API that recently landed, the patch below is the only change needed in virtio to make it work in a POWER secure guest under the ultravisor. The other change we need (making sure the device's dma_map_ops is NULL so that the dma-direct/swiotlb code is used) can be made in powerpc-specific code. Of course, I also have patches (soon to be posted as RFC) which hook up to the powerpc secure guest support code. What do you think? From d0629a36a75c678b4a72b853f8f7f8c17eedd6b3 Mon Sep 17 00:00:00 2001 From: Thiago Jung Bauermann Date: Thu, 24 Jan 2019 22:08:02 -0200 Subject: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted The host can't access the guest memory when it's encrypted, so using regular memory pages for the ring isn't an option. Go through the DMA API. Signed-off-by: Thiago Jung Bauermann Well I think this will come back to bite us (witness xen which is now reworking precisely this path - but at least they aren't to blame, xen came before ACCESS_PLATFORM). I also still think the right thing would have been to set ACCESS_PLATFORM for all systems where device can't access all memory. But I also think I don't have the energy to argue about power secure guest anymore. So be it for power secure guest since the involved engineers disagree with me. Hey I've been wrong in the past ;). But the name "sev_active" makes me scared because at least AMD guys who were doing the sensible thing and setting ACCESS_PLATFORM (unless I'm wrong? I reemember distinctly that's so) will likely be affected too. We don't want that. So let's find a way to make sure it's just power secure guest for now pls. I also think we should add a dma_api near features under virtio_device such that these hacks can move off data path. Anyway the current Xen code is conflict with spec which said: "If this feature bit is set to 0, then the device has same access to memory addresses supplied to it as the driver has. In particular, the device will always use physical addresses matching addresses used by the driver (typically meaning physical addresses used by the CPU) and not translated further, and can access any address supplied to it by the driver. When clear, this overrides any platform-specific description of whether device access is limited or translated in any way, e.g. whether an IOMMU may be present. " I wonder how much value that the above description can give us. It's kind of odd that the behavior of "when the feature is not negotiated" is described in the spec. Hmm what's odd about it? We need to describe the behaviour is all cases. Well, try to limit the behavior of 'legacy' driver is tricky or even impossible. Xen is an exact example for this. Personally I think we can remove the above and then we can switch to use DMA API unconditionally in guest driver. It may have single digit regression probably, we can try to overcome it. Thanks This has been discussed ad nauseum. virtio is all about compatibility. Losing a couple of lines of code isn't worth breaking working setups. People that want "just use DMA API no tricks" now have the option. Setting a flag in a feature bit map is literally a single line of code in the hypervisor. So stop pushing for breaking working legacy setups and just fix it in the right place. I may miss soemthing, which kind of legacy setup is broken? Do you mean using virtio without IOMMU_PLATFORM on platform with IOMMU? We actually unbreak this setup. Thanks By the way could you please respond about virtio-iommu and why there's no support for ACCESS_PLATFORM on power? I have Cc'd you on these discussions. Thanks! --- drivers/virtio/virtio_ring.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c index cd7e755484e3..321a27075380 100644 --- a/drivers/virtio/virtio_ring.c +++ b/drivers/virtio/virtio_ring.c @@ -259,8 +259,11 @@ static bool vring_use_dma_api(struct virtio_device *vdev) * not work without an even larger kludge. Instead, enable * the DMA API if we're a Xen guest, which at least allows * all of the sensible Xen configurations to work correctly. +* +* Also, if guest memory is encrypted the host can't access +* it directly. In this case, we'll need to use the DMA API. */ - if (xen_domain()) + if (xen_domain() || sev_active()) return true; return false; -- Thiago Jung Bauermann IBM Linux Technology Center
Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted
On Wed, Jan 30, 2019 at 10:24:01AM +0800, Jason Wang wrote: > > On 2019/1/30 上午3:02, Michael S. Tsirkin wrote: > > On Tue, Jan 29, 2019 at 03:42:44PM -0200, Thiago Jung Bauermann wrote: > > > Fixing address of powerpc mailing list. > > > > > > Thiago Jung Bauermann writes: > > > > > > > Hello, > > > > > > > > With Christoph's rework of the DMA API that recently landed, the patch > > > > below is the only change needed in virtio to make it work in a POWER > > > > secure guest under the ultravisor. > > > > > > > > The other change we need (making sure the device's dma_map_ops is NULL > > > > so that the dma-direct/swiotlb code is used) can be made in > > > > powerpc-specific code. > > > > > > > > Of course, I also have patches (soon to be posted as RFC) which hook up > > > > to the powerpc secure guest support code. > > > > > > > > What do you think? > > > > > > > > From d0629a36a75c678b4a72b853f8f7f8c17eedd6b3 Mon Sep 17 00:00:00 2001 > > > > From: Thiago Jung Bauermann > > > > Date: Thu, 24 Jan 2019 22:08:02 -0200 > > > > Subject: [RFC PATCH] virtio_ring: Use DMA API if guest memory is > > > > encrypted > > > > > > > > The host can't access the guest memory when it's encrypted, so using > > > > regular memory pages for the ring isn't an option. Go through the DMA > > > > API. > > > > > > > > Signed-off-by: Thiago Jung Bauermann > > Well I think this will come back to bite us (witness xen which is now > > reworking precisely this path - but at least they aren't to blame, xen > > came before ACCESS_PLATFORM). > > > > I also still think the right thing would have been to set > > ACCESS_PLATFORM for all systems where device can't access all memory. > > > > But I also think I don't have the energy to argue about power secure > > guest anymore. So be it for power secure guest since the involved > > engineers disagree with me. Hey I've been wrong in the past ;). > > > > But the name "sev_active" makes me scared because at least AMD guys who > > were doing the sensible thing and setting ACCESS_PLATFORM (unless I'm > > wrong? I reemember distinctly that's so) will likely be affected too. > > We don't want that. > > > > So let's find a way to make sure it's just power secure guest for now > > pls. > > > > I also think we should add a dma_api near features under virtio_device > > such that these hacks can move off data path. > > > Anyway the current Xen code is conflict with spec which said: > > "If this feature bit is set to 0, then the device has same access to memory > addresses supplied to it as the driver has. In particular, the device will > always use physical addresses matching addresses used by the driver > (typically meaning physical addresses used by the CPU) and not translated > further, and can access any address supplied to it by the driver. When > clear, this overrides any platform-specific description of whether device > access is limited or translated in any way, e.g. whether an IOMMU may be > present. " > > I wonder how much value that the above description can give us. It's kind of > odd that the behavior of "when the feature is not negotiated" is described > in the spec. Hmm what's odd about it? We need to describe the behaviour is all cases. > Personally I think we can remove the above and then we can > switch to use DMA API unconditionally in guest driver. It may have single > digit regression probably, we can try to overcome it. > > Thanks This has been discussed ad nauseum. virtio is all about compatibility. Losing a couple of lines of code isn't worth breaking working setups. People that want "just use DMA API no tricks" now have the option. Setting a flag in a feature bit map is literally a single line of code in the hypervisor. So stop pushing for breaking working legacy setups and just fix it in the right place. > > > > > By the way could you please respond about virtio-iommu and > > why there's no support for ACCESS_PLATFORM on power? > > > > I have Cc'd you on these discussions. > > > > > > Thanks! > > > > > > > > --- > > > > drivers/virtio/virtio_ring.c | 5 - > > > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c > > > >
Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted
On 2019/1/30 上午3:02, Michael S. Tsirkin wrote: On Tue, Jan 29, 2019 at 03:42:44PM -0200, Thiago Jung Bauermann wrote: Fixing address of powerpc mailing list. Thiago Jung Bauermann writes: Hello, With Christoph's rework of the DMA API that recently landed, the patch below is the only change needed in virtio to make it work in a POWER secure guest under the ultravisor. The other change we need (making sure the device's dma_map_ops is NULL so that the dma-direct/swiotlb code is used) can be made in powerpc-specific code. Of course, I also have patches (soon to be posted as RFC) which hook up to the powerpc secure guest support code. What do you think? From d0629a36a75c678b4a72b853f8f7f8c17eedd6b3 Mon Sep 17 00:00:00 2001 From: Thiago Jung Bauermann Date: Thu, 24 Jan 2019 22:08:02 -0200 Subject: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted The host can't access the guest memory when it's encrypted, so using regular memory pages for the ring isn't an option. Go through the DMA API. Signed-off-by: Thiago Jung Bauermann Well I think this will come back to bite us (witness xen which is now reworking precisely this path - but at least they aren't to blame, xen came before ACCESS_PLATFORM). I also still think the right thing would have been to set ACCESS_PLATFORM for all systems where device can't access all memory. But I also think I don't have the energy to argue about power secure guest anymore. So be it for power secure guest since the involved engineers disagree with me. Hey I've been wrong in the past ;). But the name "sev_active" makes me scared because at least AMD guys who were doing the sensible thing and setting ACCESS_PLATFORM (unless I'm wrong? I reemember distinctly that's so) will likely be affected too. We don't want that. So let's find a way to make sure it's just power secure guest for now pls. I also think we should add a dma_api near features under virtio_device such that these hacks can move off data path. Anyway the current Xen code is conflict with spec which said: "If this feature bit is set to 0, then the device has same access to memory addresses supplied to it as the driver has. In particular, the device will always use physical addresses matching addresses used by the driver (typically meaning physical addresses used by the CPU) and not translated further, and can access any address supplied to it by the driver. When clear, this overrides any platform-specific description of whether device access is limited or translated in any way, e.g. whether an IOMMU may be present. " I wonder how much value that the above description can give us. It's kind of odd that the behavior of "when the feature is not negotiated" is described in the spec. Personally I think we can remove the above and then we can switch to use DMA API unconditionally in guest driver. It may have single digit regression probably, we can try to overcome it. Thanks By the way could you please respond about virtio-iommu and why there's no support for ACCESS_PLATFORM on power? I have Cc'd you on these discussions. Thanks! --- drivers/virtio/virtio_ring.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c index cd7e755484e3..321a27075380 100644 --- a/drivers/virtio/virtio_ring.c +++ b/drivers/virtio/virtio_ring.c @@ -259,8 +259,11 @@ static bool vring_use_dma_api(struct virtio_device *vdev) * not work without an even larger kludge. Instead, enable * the DMA API if we're a Xen guest, which at least allows * all of the sensible Xen configurations to work correctly. +* +* Also, if guest memory is encrypted the host can't access +* it directly. In this case, we'll need to use the DMA API. */ - if (xen_domain()) + if (xen_domain() || sev_active()) return true; return false; -- Thiago Jung Bauermann IBM Linux Technology Center
Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted
On Tue, Jan 29, 2019 at 03:42:44PM -0200, Thiago Jung Bauermann wrote: > > Fixing address of powerpc mailing list. > > Thiago Jung Bauermann writes: > > > Hello, > > > > With Christoph's rework of the DMA API that recently landed, the patch > > below is the only change needed in virtio to make it work in a POWER > > secure guest under the ultravisor. > > > > The other change we need (making sure the device's dma_map_ops is NULL > > so that the dma-direct/swiotlb code is used) can be made in > > powerpc-specific code. > > > > Of course, I also have patches (soon to be posted as RFC) which hook up > > to the powerpc secure guest support code. > > > > What do you think? > > > > From d0629a36a75c678b4a72b853f8f7f8c17eedd6b3 Mon Sep 17 00:00:00 2001 > > From: Thiago Jung Bauermann > > Date: Thu, 24 Jan 2019 22:08:02 -0200 > > Subject: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted > > > > The host can't access the guest memory when it's encrypted, so using > > regular memory pages for the ring isn't an option. Go through the DMA API. > > > > Signed-off-by: Thiago Jung Bauermann Well I think this will come back to bite us (witness xen which is now reworking precisely this path - but at least they aren't to blame, xen came before ACCESS_PLATFORM). I also still think the right thing would have been to set ACCESS_PLATFORM for all systems where device can't access all memory. But I also think I don't have the energy to argue about power secure guest anymore. So be it for power secure guest since the involved engineers disagree with me. Hey I've been wrong in the past ;). But the name "sev_active" makes me scared because at least AMD guys who were doing the sensible thing and setting ACCESS_PLATFORM (unless I'm wrong? I reemember distinctly that's so) will likely be affected too. We don't want that. So let's find a way to make sure it's just power secure guest for now pls. I also think we should add a dma_api near features under virtio_device such that these hacks can move off data path. By the way could you please respond about virtio-iommu and why there's no support for ACCESS_PLATFORM on power? I have Cc'd you on these discussions. Thanks! > > --- > > drivers/virtio/virtio_ring.c | 5 - > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c > > index cd7e755484e3..321a27075380 100644 > > --- a/drivers/virtio/virtio_ring.c > > +++ b/drivers/virtio/virtio_ring.c > > @@ -259,8 +259,11 @@ static bool vring_use_dma_api(struct virtio_device > > *vdev) > > * not work without an even larger kludge. Instead, enable > > * the DMA API if we're a Xen guest, which at least allows > > * all of the sensible Xen configurations to work correctly. > > +* > > +* Also, if guest memory is encrypted the host can't access > > +* it directly. In this case, we'll need to use the DMA API. > > */ > > - if (xen_domain()) > > + if (xen_domain() || sev_active()) > > return true; > > > > return false; > > > -- > Thiago Jung Bauermann > IBM Linux Technology Center
Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted
Fixing address of powerpc mailing list. Thiago Jung Bauermann writes: > Hello, > > With Christoph's rework of the DMA API that recently landed, the patch > below is the only change needed in virtio to make it work in a POWER > secure guest under the ultravisor. > > The other change we need (making sure the device's dma_map_ops is NULL > so that the dma-direct/swiotlb code is used) can be made in > powerpc-specific code. > > Of course, I also have patches (soon to be posted as RFC) which hook up > to the powerpc secure guest support code. > > What do you think? > > From d0629a36a75c678b4a72b853f8f7f8c17eedd6b3 Mon Sep 17 00:00:00 2001 > From: Thiago Jung Bauermann > Date: Thu, 24 Jan 2019 22:08:02 -0200 > Subject: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted > > The host can't access the guest memory when it's encrypted, so using > regular memory pages for the ring isn't an option. Go through the DMA API. > > Signed-off-by: Thiago Jung Bauermann > --- > drivers/virtio/virtio_ring.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c > index cd7e755484e3..321a27075380 100644 > --- a/drivers/virtio/virtio_ring.c > +++ b/drivers/virtio/virtio_ring.c > @@ -259,8 +259,11 @@ static bool vring_use_dma_api(struct virtio_device *vdev) >* not work without an even larger kludge. Instead, enable >* the DMA API if we're a Xen guest, which at least allows >* all of the sensible Xen configurations to work correctly. > + * > + * Also, if guest memory is encrypted the host can't access > + * it directly. In this case, we'll need to use the DMA API. >*/ > - if (xen_domain()) > + if (xen_domain() || sev_active()) > return true; > > return false; -- Thiago Jung Bauermann IBM Linux Technology Center