Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: Virtio hardening for TDX
To:     Andi Kleen <ak@linux.intel.com>, mst@redhat.com
Cc:     virtualization@lists.linux-foundation.org, hch@lst.de,
        m.szyprowski@samsung.com, robin.murphy@arm.com,
        iommu@lists.linux-foundation.org, x86@kernel.org,
        sathyanarayanan.kuppuswamy@linux.intel.com, jpoimboe@redhat.com,
        linux-kernel@vger.kernel.org
References: <20210603004133.4079390-1-ak@linux.intel.com>
From:   Jason Wang <jasowang@redhat.com>
Message-ID: <63d01084-68d2-a8d5-931d-541a22b5f231@redhat.com>
Date:   Thu, 3 Jun 2021 09:34:08 +0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
 Gecko/20100101 Thunderbird/78.10.2
MIME-Version: 1.0
In-Reply-To: <20210603004133.4079390-1-ak@linux.intel.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Precedence: bulk


在 2021/6/3 上午8:41, Andi Kleen 写道:
> [v1: Initial post]
>
> With confidential computing like TDX the guest doesn't trust the host
> anymore. The host is allowed to DOS of course, but it is not allowed
> to read or write any guest memory not explicitely shared with it.
>
> This has implication for virtio. Traditionally virtio didn't assume
> the other side of the communication channel is malicious, and therefore
> didn't do any boundary checks in virtio ring data structures.
>
> This patchkit does hardening for virtio.  In a TDX like model
> the only host memory accesses allowed are in the virtio ring,
> as well as the (forced) swiotlb buffer.
>
> This patch kit does various changes to ensure there can be no
> access outside these two areas. It is possible for the host
> to break the communication, but this should result in a IO
> error on the guest, but no memory safety violations.
>
> virtio is quite complicated with many modes. To simplify
> the task we enforce that virtio is only in split mode without
> indirect descriptors, when running as a TDX guest. We also
> enforce use of the DMA API.
>
> Then these code paths are hardened against any corruptions
> on the ring.
>
> This patchkit has components in three subsystems:
> - Hardening changes to virtio, all in the generic virtio-ring
> - Hardening changes to kernel/dma swiotlb to harden swiotlb against
> malicious pointers. It requires an API change which needed a tree sweep.
> - A single x86 patch to enable the arch_has_restricted_memory_access
> for TDX
>
> It depends on Sathya's earlier patchkit that adds the basic infrastructure
> for TDX. This is only needed for the "am I running in TDX" part.


Note that it's probably needed by other cases as well:

1) Other encrypted VM technology
2) VDUSE[1]
3) Smart NICs

We have already had discussions and some patches have been posted[2][3][4].

I think the basic idea is similar, basically,  we don't trust any 
metadata provided by the device.

[2] is the series that use the metadata stored in the private memory 
which can't be accessed by swiotlb, this series aims to eliminate all 
the possible attacks via virtqueue metadata
[3] is one example for the the used length validation
[4] is the fix for the malicious config space

Thanks

[1] https://www.spinics.net/lists/netdev/msg743264.html
[2] https://www.spinics.net/lists/kvm/msg241825.html
[3] https://patches.linaro.org/patch/450733/
[4] https://lkml.org/lkml/2021/5/17/376

>
>
>