From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Matthew Garrett <mjg59@google.com>
Cc: David Tolnay <dtolnay@gmail.com>, Peter Huewe <peterhuewe@gmx.de>,
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
Jason Gunthorpe <jgg@ziepe.ca>,
linux-integrity <linux-integrity@vger.kernel.org>,
"Michael S. Tsirkin" <mst@redhat.com>,
Jason Wang <jasowang@redhat.com>,
virtualization@lists.linux-foundation.org, dgreid@chromium.org,
apronin@chromium.org
Subject: Re: [PATCH] tpm: Add driver for TPM over virtio
Date: Mon, 25 Feb 2019 12:20:43 -0800 [thread overview]
Message-ID: <1551126043.3226.45.camel@HansenPartnership.com> (raw)
In-Reply-To: <CACdnJuuMdYS5L4uCKDHr5e-+N3g2qbuZY4KpKdAPbGS9QFYs9g@mail.gmail.com>
On Mon, 2019-02-25 at 11:17 -0800, Matthew Garrett wrote:
> On Mon, Feb 25, 2019 at 7:36 AM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > > The virtio driver performs discovery via virtio, which crosvm
> > > implements already for all of its supported devices. This
> > > substantially reduces the amount of TPM-specific code compared to
> > > your suggestions, and lowers the barrier to entry for
> > > implementing TPM support in other hypervisors which I hope we
> > > agree is beneficial.
> >
> > Well, that's somewhat misleading: The reason we already have two
> > hypervisor specific drivers already is because every hypervisor has
> > a different virtual discovery mechanism. You didn't find the other
> > two hypervisor drivers remotely useful, so why would another
> > hypervisor find yours useful?
>
> The existing hypervisor drivers expose hypervisor-specific details.
> This proposed driver provides an abstract interface that is usable by
> other hypervisors. It allows building a VM that exposes TPM
> functionality without requiring additional hardware emulation,
> reducing the hypervisor attack surface.
Well, that depends whether you think a virtio bus is an abstract
concept or a hypervisor specific detail. There are currently four
major hypervisors: xen, kvm, hyper-v and ESX. Of those, only one
implements virtio: kvm. I agree virtio is a standard and certainly a
slew of minor hypervisors implement it because they need paravirt
support on Linux so they piggyback off kvm, but I don't see any of the
other major hypervisors jumping on the bandwagon.
I certainly agree our lives would be easier if all the major hypervisor
vendors would just agree a single paravirt driver standard.
> > > For me as a hypervisor implementer, what advantages do you see
> > > that would make me decide to implement TPM-specific virtual
> > > hardware emulation in the form of TIS rather than simply
> > > leveraging a virtio driver like for other virtual devices?
> >
> > So your argument is that for every device we have in the Linux
> > kernel, we should have the N hypervisor paravirt variants for the
> > same thing? I assure you that's not going to fly because paravirt
> > drivers would then outnumber real drivers by an order of magnitude.
>
> Well, no - in general there's no need to have more than one virtio
> driver for any /class/ of hardware. For various unfortunate accidents
> of history we've ended up with multiple cases where we have
> hypervisor-specific drivers.
Fully agree, that's why I'm doing so now.
> Using the more generic virtio
> infrastructure reduces the need for that, since any hypervisor should
> be able to implement the backend (eg, in this case it'd be very easy
> to add support for this driver to qemu,
I certainly agree there ... is there a plan for this?
> which would allow the use of TPMs without needing to enable a whole
> bunch of additional qemu features). This isn't a discussion we'd be
> having if we'd pushed back more strongly against hypervisor-specific
> solutions in the past.
I'm still looking for the pragmatic use case. I think yours is attack
surface reduction, because the virtio discovery and operation is less
code and therefore more secure than physical hardware discovery and
operation? I'm not entirely sure I buy that because the TPM
communication interface is pretty simple and it's fairly deep down in
the kernel internal stack making it difficult to exploit.
James
next prev parent reply other threads:[~2019-02-25 20:20 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-22 2:14 [PATCH] tpm: Add driver for TPM over virtio David Tolnay
2019-02-22 5:51 ` Michael S. Tsirkin
2019-02-22 21:40 ` David Tolnay
2019-02-22 22:24 ` Michael S. Tsirkin
2019-02-23 1:23 ` David Tolnay
2019-02-25 9:58 ` Jarkko Sakkinen
2019-02-22 10:26 ` Jarkko Sakkinen
2019-02-22 15:23 ` Michael S. Tsirkin
2019-02-22 19:31 ` Jarkko Sakkinen
2019-02-22 19:33 ` Jarkko Sakkinen
2019-02-22 21:25 ` Michael S. Tsirkin
2019-02-22 21:50 ` Jarkko Sakkinen
2019-02-22 22:24 ` David Tolnay
2019-02-22 22:36 ` Jarkko Sakkinen
2019-02-22 23:05 ` Michael S. Tsirkin
2019-02-24 9:33 ` Jarkko Sakkinen
2019-02-22 20:55 ` Michael S. Tsirkin
2019-02-22 21:30 ` Jarkko Sakkinen
2019-02-22 10:30 ` Jarkko Sakkinen
2019-02-22 15:30 ` James Bottomley
2019-02-22 21:16 ` Michael S. Tsirkin
2019-02-22 21:31 ` Jason Gunthorpe
2019-02-22 21:59 ` Jarkko Sakkinen
2019-02-22 22:07 ` Michael S. Tsirkin
2019-02-22 22:14 ` Jarkko Sakkinen
2019-02-22 22:00 ` David Tolnay
2019-02-22 22:18 ` James Bottomley
2019-02-23 0:45 ` David Tolnay
2019-02-23 1:34 ` James Bottomley
2019-02-23 2:41 ` David Tolnay
2019-02-24 16:30 ` James Bottomley
2019-02-24 17:51 ` Jarkko Sakkinen
2019-02-24 22:12 ` David Tolnay
2019-02-25 9:55 ` Jarkko Sakkinen
2019-02-25 15:36 ` James Bottomley
2019-02-25 19:17 ` Matthew Garrett
2019-02-25 19:54 ` Jarkko Sakkinen
2019-02-25 20:20 ` James Bottomley [this message]
2019-02-25 21:00 ` Matthew Garrett
2019-02-25 21:02 ` Matthew Garrett
2019-02-25 22:14 ` James Bottomley
2019-02-25 22:24 ` Matthew Garrett
2019-02-25 22:32 ` James Bottomley
2019-02-25 22:43 ` Matthew Garrett
2019-02-25 22:51 ` James Bottomley
2019-02-25 23:02 ` Matthew Garrett
2019-02-25 23:09 ` James Bottomley
2019-02-25 21:05 ` Jarkko Sakkinen
2019-02-25 22:24 ` James Bottomley
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=1551126043.3226.45.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=apronin@chromium.org \
--cc=dgreid@chromium.org \
--cc=dtolnay@gmail.com \
--cc=jarkko.sakkinen@linux.intel.com \
--cc=jasowang@redhat.com \
--cc=jgg@ziepe.ca \
--cc=linux-integrity@vger.kernel.org \
--cc=mjg59@google.com \
--cc=mst@redhat.com \
--cc=peterhuewe@gmx.de \
--cc=virtualization@lists.linux-foundation.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).