qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Corey Minyard <minyard@acm.org>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: Robin Jarry <robin.jarry@6wind.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] -device ipmi-bmc-sim attached to -netdev vde
Date: Mon, 4 Mar 2019 13:36:37 -0600	[thread overview]
Message-ID: <20190304193637.GC25395@minyard.net> (raw)
In-Reply-To: <20190304170900.GS4239@redhat.com>

On Mon, Mar 04, 2019 at 05:09:00PM +0000, Daniel P. Berrangé wrote:
> On Tue, Feb 19, 2019 at 09:07:08PM -0600, Corey Minyard wrote:
> > My suggestion, though, would be to implement something that ran over
> > TLS with two-way authentication.  It doesn't look too hard to do
> > in qemu (though I haven't tried it) but you could have a qemu console
> > running over TLS that would allow you control from another qemu session.
> > Plus it would give you authorization and encryption on your qemu
> > console logins, which is probably a good thing.
> > 
> > <shameless-plug> I have been working on a library that makes it easy
> > (easier?  The pain is always in the key management) to make TLS
> > connections.  It's at https://github.com/cminyard/gensio and you
> > can use it from C or Python.</shameless-plug>
> 
> On the QEMU side, we already have a framework for doing socket
> connections with TLS support in a straightforward manner via
> the QIOChannel framework. The code using this in QEMU doesn't
> really need to know anything about TLS in order to use this.
> We have it wired up in character devices, VNC, migration and
> NBD network sockets.

Right, I wasn't clear, that was for the client side, not the
qemu side.  I saw that the TLS code was already present in
qemu; no qemu modifications should be required.

> 
> Last week my authorization series merged, so that we can also
> easily deal with access control whitelisting permitted clients
> via their x509 certificate distinguished name.

That's even better.

Thanks,

-corey

> 
> So I'd expect anything on the QEMU side that introduces new
> network sockets usage to support TLS out of the box with
> little extra effort required over plain TCP sockets.
> 
> Regards,
> Daniel
> -- 
> |: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org         -o-            https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

      reply	other threads:[~2019-03-04 19:36 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-11 17:09 [Qemu-devel] -device ipmi-bmc-sim attached to -netdev vde Robin Jarry
2019-02-20  3:07 ` Corey Minyard
2019-03-04 16:56   ` Robin Jarry
2019-03-04 17:09   ` Daniel P. Berrangé
2019-03-04 19:36     ` Corey Minyard [this message]

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=20190304193637.GC25395@minyard.net \
    --to=minyard@acm.org \
    --cc=berrange@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=robin.jarry@6wind.com \
    /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).