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: <2b2dec75-a0c1-4013-ac49-a49f30d5ac3c@www.fastmail.com>
In-Reply-To: <a0e66b4c-cec5-2a26-9431-d5a21e22c8f2@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>
Date:   Thu, 03 Jun 2021 12:31:59 -0700
From:   "Andy Lutomirski" <luto@kernel.org>
To:     "Andi Kleen" <ak@linux.intel.com>, mst@redhat.com
Cc:     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 11:00 AM, Andi Kleen wrote:
>=20
> 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 t=
he
> > buggy code in one special case in which we need a driver without bug=
s.
> > In all the other cases (e.g. hardware virtio device connected over
> > USB-C), driver bugs are still allowed."
>=20
> My understanding is most of the other modes (except for split with=20
> separate descriptors) are obsolete and just there for compatibility. A=
s=20
> long as they're deprecated they won't harm anyone.
>=20
>

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. Mayb=
e rename the old driver virtio-legacy or virtio-insecure.  They can shar=
e code.

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 sli=
ghtly optimistic that getting the heuristic wrong will make the driver f=
ail to operate but won=E2=80=99t allow the host to take over the guest, =
but I=E2=80=99m not really convinced. And I wrote that code!  A virtio-m=
odern mode probably should not have a heuristic, and the various iommu-b=
ypassing modes should be fixed to work at the bus level, not the device =
level.