Virtualization - Jun 2021 - [PATCH v1 1/8] virtio: Force only split mode with protected guest

On Thu, Jun 3, 2021, at 11:00 AM, Andi Kleen wrote:
> 
> On 6/3/2021 10:33 AM, Andy Lutomirski wrote:
> > On 6/2/21 5:41 PM, Andi Kleen wrote:
> >> Only allow split mode when in a protected guest. Followon
> >> patches harden the split mode code paths, and we don't want
> >> an malicious host to force anything else. Also disallow
> >> indirect mode for similar reasons.
> > I read this as "the virtio driver is buggy.  Let's disable
most of the
> > buggy code in one special case in which we need a driver without bugs.
> > In all the other cases (e.g. hardware virtio device connected over
> > USB-C), driver bugs are still allowed."
> 
> My understanding is most of the other modes (except for split with 
> separate descriptors) are obsolete and just there for compatibility. As 
> long as they're deprecated they won't harm anyone.
> 
>
Tell that to every crypto downgrade attack ever.

I see two credible solutions:

1. Actually harden the virtio driver.

2. Have a new virtio-modern driver and use it for modern use cases. Maybe rename
the old driver virtio-legacy or virtio-insecure.  They can share code.

Another snag you may hit: virtio?s heuristic for whether to use proper DMA ops
or to bypass them is a giant kludge. I?m very slightly optimistic that getting
the heuristic wrong will make the driver fail to operate but won?t allow the
host to take over the guest, but I?m not really convinced. And I wrote that
code!  A virtio-modern mode probably should not have a heuristic, and the
various iommu-bypassing modes should be fixed to work at the bus level, not the
device level.

> Tell that to every crypto downgrade attack ever.
That's exactly what this patch addresses.
>
> I see two credible solutions:
>
> 1. Actually harden the virtio driver.
That's exactly what this patchkit, and the alternative approaches, like 
Jason's, are doing.
>
> 2. Have a new virtio-modern driver and use it for modern use cases. Maybe
rename the old driver virtio-legacy or virtio-insecure.  They can share code.
In most use cases the legacy driver is not insecure because there is no 
memory protection anyways.

Yes maybe such a split would be a good idea for maintenance and maybe 
performance reasons, but at least from the security perspective I don't 
see any need for it.
>
> Another snag you may hit: virtio?s heuristic for whether to use proper DMA
ops or to bypass them is a giant kludge. I?m very slightly optimistic that
getting the heuristic wrong will make the driver fail to operate but won?t allow
the host to take over the guest, but I?m not really convinced. And I wrote that
code!  A virtio-modern mode probably should not have a heuristic, and the
various iommu-bypassing modes should be fixed to work at the bus level, not the
device level
TDX and SEV use the arch hook to enforce DMA API, so that part is also 
solved.


-Andi

? 2021/6/4 ??3:31, Andy Lutomirski ??:
>
> On Thu, Jun 3, 2021, at 11:00 AM, Andi Kleen wrote:
>> On 6/3/2021 10:33 AM, Andy Lutomirski wrote:
>>> On 6/2/21 5:41 PM, Andi Kleen wrote:
>>>> Only allow split mode when in a protected guest. Followon
>>>> patches harden the split mode code paths, and we don't want
>>>> an malicious host to force anything else. Also disallow
>>>> indirect mode for similar reasons.
>>> I read this as "the virtio driver is buggy.  Let's disable
most of the
>>> buggy code in one special case in which we need a driver without
bugs.
>>> In all the other cases (e.g. hardware virtio device connected over
>>> USB-C), driver bugs are still allowed."
>> My understanding is most of the other modes (except for split with
>> separate descriptors) are obsolete and just there for compatibility. As
>> long as they're deprecated they won't harm anyone.
>>
>>
> Tell that to every crypto downgrade attack ever.
>
> I see two credible solutions:
>
> 1. Actually harden the virtio driver.
>
> 2. Have a new virtio-modern driver and use it for modern use cases. Maybe
rename the old driver virtio-legacy or virtio-insecure.  They can share code.

Note that we had already split legacy driver out which can be turned off 
via Kconfig.

>
> Another snag you may hit: virtio?s heuristic for whether to use proper DMA
ops or to bypass them is a giant kludge. I?m very slightly optimistic that
getting the heuristic wrong will make the driver fail to operate but won?t allow
the host to take over the guest, but I?m not really convinced. And I wrote that
code!  A virtio-modern mode probably should not have a heuristic, and the
various iommu-bypassing modes should be fixed to work at the bus level, not the
device level.

I remember there's a very long discussion about this and probably 
without any conclusion. Fortunately, the management layer has been 
taught to enforce VIRTIO_F_ACCESS_PLATFORM for encrypted guests.

A possible way to fix this is without any conflicts is to mandate the 
VIRTIO_F_ACCESS_PLATFORM in version 1.2.

Thanks

>