All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.