From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Corey Minyard <minyard@acm.org>
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 17:09:00 +0000 [thread overview]
Message-ID: <20190304170900.GS4239@redhat.com> (raw)
In-Reply-To: <20190220030707.GA5504@minyard.net>
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.
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.
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 :|
next prev parent reply other threads:[~2019-03-04 17:09 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é [this message]
2019-03-04 19:36 ` Corey Minyard
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=20190304170900.GS4239@redhat.com \
--to=berrange@redhat.com \
--cc=minyard@acm.org \
--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).