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
Date: Thu, 03 Jun 2021 15:17:34 -0700 [thread overview]
Message-ID: <b8b39b76-8d07-4e4a-804a-746269787b61@www.fastmail.com> (raw)
In-Reply-To: <3159e1f4-77cd-e071-b6f2-a2bb83cfc69a@linux.intel.com>
On Thu, Jun 3, 2021, at 12:53 PM, Andi Kleen wrote:
>
> > 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.
Please reread my email.
We do not need an increasing pile of kludges to make TDX and SEV “secure”. We need the actual loaded driver to be secure. The virtio architecture is full of legacy nonsense, and there is no good reason 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 the host does not trust the device to implement the virtio protocol correctly.
>
> >
> > 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.
>
Can you point me to the code you’re referring to?
>
> -Andi
>
>
next prev parent reply other threads:[~2021-06-03 22:18 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-03 0:41 Virtio hardening for TDX Andi Kleen
2021-06-03 0:41 ` [PATCH v1 1/8] virtio: Force only split mode with protected guest Andi Kleen
2021-06-03 1:36 ` Jason Wang
2021-06-03 1:48 ` Andi Kleen
2021-06-03 2:32 ` Jason Wang
2021-06-03 2:56 ` Andi Kleen
2021-06-03 3:02 ` Jason Wang
2021-06-03 13:55 ` Andi Kleen
2021-06-04 2:29 ` Jason Wang
2021-06-03 17:33 ` Andy Lutomirski
2021-06-03 18:00 ` Andi Kleen
2021-06-03 19:31 ` Andy Lutomirski
2021-06-03 19:53 ` Andi Kleen
2021-06-03 22:17 ` Andy Lutomirski [this message]
2021-06-03 23:32 ` Andi Kleen
2021-06-04 1:46 ` Andy Lutomirski
2021-06-04 1:54 ` Andi Kleen
2021-06-04 1:22 ` Jason Wang
2021-06-04 1:29 ` Jason Wang
2021-06-04 2:20 ` Jason Wang
2021-06-03 0:41 ` [PATCH v1 2/8] virtio: Add boundary checks to virtio ring Andi Kleen
2021-06-03 2:14 ` Jason Wang
2021-06-03 2:18 ` Andi Kleen
2021-06-03 2:36 ` Jason Wang
2021-06-03 0:41 ` [PATCH v1 3/8] virtio: Harden split buffer detachment Andi Kleen
2021-06-03 2:29 ` Jason Wang
2021-06-03 0:41 ` [PATCH v1 4/8] x86/tdx: Add arch_has_restricted_memory_access for TDX Andi Kleen
2021-06-03 4:02 ` Kuppuswamy, Sathyanarayanan
2021-06-03 0:41 ` [PATCH v1 5/8] dma: Use size for swiotlb boundary checks Andi Kleen
2021-06-03 1:48 ` Konrad Rzeszutek Wilk
2021-06-03 2:03 ` Andi Kleen
2021-06-03 9:09 ` Robin Murphy
2021-06-03 0:41 ` [PATCH v1 6/8] dma: Add return value to dma_unmap_page Andi Kleen
2021-06-03 9:08 ` Robin Murphy
2021-06-03 12:36 ` Andi Kleen
2021-06-03 0:41 ` [PATCH v1 7/8] virtio: Abort IO when descriptor points outside forced swiotlb Andi Kleen
2021-06-03 0:41 ` [PATCH v1 8/8] virtio: Error out on endless free lists Andi Kleen
2021-06-03 1:34 ` Virtio hardening for TDX Jason Wang
2021-06-03 1:56 ` Andi Kleen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b8b39b76-8d07-4e4a-804a-746269787b61@www.fastmail.com \
--to=luto@kernel.org \
--cc=ak@linux.intel.com \
--cc=hch@lst.de \
--cc=iommu@lists.linux-foundation.org \
--cc=jasowang@redhat.com \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=mst@redhat.com \
--cc=robin.murphy@arm.com \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=virtualization@lists.linux-foundation.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).