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;
User-Agent: Cyrus-JMAP/3.5.0-alpha0-519-g27a961944e-fm-20210531.001-g27a96194
Mime-Version: 1.0
Message-Id: <b8b39b76-8d07-4e4a-804a-746269787b61@www.fastmail.com>
In-Reply-To: <3159e1f4-77cd-e071-b6f2-a2bb83cfc69a@linux.intel.com>
References: <20210603004133.4079390-1-ak@linux.intel.com>
 <20210603004133.4079390-2-ak@linux.intel.com>
 <cc5c8265-83f7-aeb1-bc30-3367fe68bc97@kernel.org>
 <a0e66b4c-cec5-2a26-9431-d5a21e22c8f2@linux.intel.com>
 <2b2dec75-a0c1-4013-ac49-a49f30d5ac3c@www.fastmail.com>
 <3159e1f4-77cd-e071-b6f2-a2bb83cfc69a@linux.intel.com>
Date:   Thu, 03 Jun 2021 15:17:34 -0700
From:   "Andy Lutomirski" <luto@kernel.org>
To:     "Andi Kleen" <ak@linux.intel.com>, mst@redhat.com
Cc:     "Jason Wang" <jasowang@redhat.com>,
        virtualization@lists.linux-foundation.org, hch@lst.de,
        m.szyprowski@samsung.com, robin.murphy@arm.com,
        iommu@lists.linux-foundation.org,
        "the arch/x86 maintainers" <x86@kernel.org>,
        sathyanarayanan.kuppuswamy@linux.intel.com,
        "Josh Poimboeuf" <jpoimboe@redhat.com>,
        "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v1 1/8] virtio: Force only split mode with protected guest
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk


On Thu, Jun 3, 2021, at 12:53 PM, Andi Kleen wrote:
>=20
> > Tell that to every crypto downgrade attack ever.
>=20
> That's exactly what this patch addresses.
>=20
> >
> > I see two credible solutions:
> >
> > 1. Actually harden the virtio driver.
> That's exactly what this patchkit, and the alternative approaches, lik=
e=20
> 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.
>=20
> In most use cases the legacy driver is not insecure because there is n=
o=20
> memory protection anyways.
>=20
> Yes maybe such a split would be a good idea for maintenance and maybe=20=

> performance reasons, but at least from the security perspective I don'=
t=20
> see any need for it.


Please reread my email.

We do not need an increasing pile of kludges to make TDX and SEV =E2=80=9C=
secure=E2=80=9D.  We need the actual loaded driver to be secure.  The vi=
rtio architecture is full of legacy nonsense, and there is no good reaso=
n for SEV and TDX to be a giant special case.

As I said before, real PCIe (Thunderbolt/USB-C or anything else) has the=
 exact same problem.  The fact that TDX has encrypted memory is, at best=
, a poor proxy for the actual condition.  The actual condition is that t=
he host does not trust the device to implement the virtio protocol corre=
ctly.

>=20
> >
> > Another snag you may hit: virtio=E2=80=99s heuristic for whether to =
use proper DMA ops or to bypass them is a giant kludge. I=E2=80=99m very=
 slightly optimistic that getting the heuristic wrong will make the driv=
er fail to operate but won=E2=80=99t allow the host to take over the gue=
st, but I=E2=80=99m not really convinced. And I wrote that code!  A virt=
io-modern mode probably should not have a heuristic, and the various iom=
mu-bypassing modes should be fixed to work at the bus level, not the dev=
ice level
>=20
> TDX and SEV use the arch hook to enforce DMA API, so that part is also=
=20
> solved.
>=20

Can you point me to the code you=E2=80=99re referring to?

>=20
> -Andi
>=20
>=20