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 :|
prev parent 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).