[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <33504152-624a-45cc-51b3-10ce7aa2428f@linux.intel.com>
Date: Wed, 2 Jun 2021 18:56:27 -0700
From: Andi Kleen <ak@...ux.intel.com>
To: Jason Wang <jasowang@...hat.com>, mst@...hat.com
Cc: virtualization@...ts.linux-foundation.org, hch@....de,
m.szyprowski@...sung.com, robin.murphy@....com,
iommu@...ts.linux-foundation.org, x86@...nel.org,
sathyanarayanan.kuppuswamy@...ux.intel.com, jpoimboe@...hat.com,
linux-kernel@...r.kernel.org
Subject: Re: Virtio hardening for TDX
> Note that it's probably needed by other cases as well:
>
> 1) Other encrypted VM technology
> 2) VDUSE[1]
> 3) Smart NICs
Right. I don't see any reason why these shouldn't work. You may just
need to add the enable for the lockdown, but you can reuse the basic
infrastructure.
>
> We have already had discussions and some patches have been
> posted[2][3][4].
Thanks.
Yes [2] is indeed an alternative. We considered this at some point, but
since we don't care about DOS in our case it seemed simpler to just
harden the existing code. But yes if it's there it's useful for TDX too.
FWIW I would argue that the descriptor boundary checking should be added
in any case, security case or separated metadata or not, because it can
catch bugs and is very cheap. Checking boundaries is good practice.
[4] would be an independent issue, that's something we didn't catch.
Also the swiotlb hardening implemented in this patchkit doesn't seem to
be in any of the other patches.
So I would say my patches are mostly orthogonal to these patches below
and not conflicting, even though they address a similar problem space.
-Andi
Powered by blists - more mailing lists