Linux Virtualization - Jul 2019 - [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted

Michael S. Tsirkin <mst at redhat.com> writes:
> On Mon, Jul 15, 2019 at 05:29:06PM -0300, Thiago Jung Bauermann wrote:
>>
>> Michael S. Tsirkin <mst at redhat.com> writes:
>>
>> > On Sun, Jul 14, 2019 at 02:51:18AM -0300, Thiago Jung Bauermann
wrote:
>> >>
>> >>
>> >> Michael S. Tsirkin <mst at redhat.com> 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

On Mon, Jul 15, 2019 at 07:03:03PM -0300, Thiago Jung Bauermann
wrote:
> 
> Michael S. Tsirkin <mst at redhat.com> writes:
> 
> > On Mon, Jul 15, 2019 at 05:29:06PM -0300, Thiago Jung Bauermann wrote:
> >>
> >> Michael S. Tsirkin <mst at redhat.com> writes:
> >>
> >> > On Sun, Jul 14, 2019 at 02:51:18AM -0300, Thiago Jung
Bauermann wrote:
> >> >>
> >> >>
> >> >> Michael S. Tsirkin <mst at redhat.com> 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

Michael S. Tsirkin <mst at redhat.com> writes:
> On Mon, Jul 15, 2019 at 07:03:03PM -0300, Thiago Jung Bauermann wrote:
>> 
>> Michael S. Tsirkin <mst at redhat.com> writes:
>> 
>> > On Mon, Jul 15, 2019 at 05:29:06PM -0300, Thiago Jung Bauermann
wrote:
>> >>
>> >> Michael S. Tsirkin <mst at redhat.com> writes:
>> >>
>> >> > On Sun, Jul 14, 2019 at 02:51:18AM -0300, Thiago Jung
Bauermann wrote:
>> >> >>
>> >> >>
>> >> >> Michael S. Tsirkin <mst at redhat.com> 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

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.