[Qemu-devel] -device ipmi-bmc-sim attached to -netdev vde

[Qemu-devel] -device ipmi-bmc-sim attached to -netdev vde

[Robin Jarry]

Hi,

I have several QEMU VMs connected via a vde_switch (with "-netdev vde"
interfaces). I use this to create virtual network topologies without
requiring root access (i.e. no tap + bridge on host). Performance is not
a concern here. To emulate "real" platforms, I would like one of the VMs
to control the others via remote IPMI over this "vde" link without any
implication of the host.

The current implementation in QEMU does not seem to support this. I only
found ways to create a "local" (i.e. only reachable from the guest
itself) IPMI interface with "isa-ipmi-kcs" or "isa-ipmi-bt" devices. Or
"remote" IPMI interfaces by using an external daemon that runs on the
host [1]. This makes communication from one of the VMs to the others
quite complex.

I am enclined to try an develop another IPMI device that can be
"attached" to a -netdev with a dedicated mac address + IP configuration
to support my use case.

However, this would be my first steps into QEMU code and I have a few
questions first:

- Did I miss something and is that already possible with the current
  code base?
- Is there another way to do this or is my idea completely stupid?
- I am aware that allowing to "attach" a simplistic bmc (without any
  authentication) to a netdev may be a security problem. This is not
  a concern for me at the moment.
- Could someone point me to what would need to be added for this? Do
  I need to implement a new ipmi device type that accepts
  a "netdev=<id>" argument? If so, would that make sense for this new
  device to also accept mac-address and ip configuration for this IPMI
  interface? Or does that need to go elsewhere?

Thanks in advance for your guidance.

[1] https://github.com/Zexi/vbmc-qemu

-- 
Robin

Re: [Qemu-devel] -device ipmi-bmc-sim attached to -netdev vde

[Corey Minyard]

On Mon, Feb 11, 2019 at 06:09:24PM +0100, Robin Jarry wrote:
> Hi,
> 
> I have several QEMU VMs connected via a vde_switch (with "-netdev vde"
> interfaces). I use this to create virtual network topologies without
> requiring root access (i.e. no tap + bridge on host). Performance is not
> a concern here. To emulate "real" platforms, I would like one of the VMs
> to control the others via remote IPMI over this "vde" link without any
> implication of the host.
> 
> The current implementation in QEMU does not seem to support this. I only
> found ways to create a "local" (i.e. only reachable from the guest
> itself) IPMI interface with "isa-ipmi-kcs" or "isa-ipmi-bt" devices. Or
> "remote" IPMI interfaces by using an external daemon that runs on the
> host [1]. This makes communication from one of the VMs to the others
> quite complex.
> 
> I am enclined to try an develop another IPMI device that can be
> "attached" to a -netdev with a dedicated mac address + IP configuration
> to support my use case.
> 
> However, this would be my first steps into QEMU code and I have a few
> questions first:

Sorry, I've been overfocused on something else and this has been sitting
waiting for a response.

The QEMU code is not going to be your problem here, but more on that later.

> 
> - Did I miss something and is that already possible with the current
>   code base?

I assume you want to use ipmitool or something like that to control the
remote system.

No, it is not possible at the moment, not without something like vbmc
like you mention.

> - Is there another way to do this or is my idea completely stupid?

It's not completely stupid.  Building a system with no security and a
partial IPMI implementation wouldn't be too hard, though the IPMI spec
is very hard to understand.  You could probably steal from the openipmi
library (what vbmc uses) to get the pieces you want an get it working.

Getting all the user management and other standard required IPMI
things would be a nightmare.  But you don't need all that to make
it do what you want.

There are obvious security concerns here with an open IPMI interface.

> - I am aware that allowing to "attach" a simplistic bmc (without any
>   authentication) to a netdev may be a security problem. This is not
>   a concern for me at the moment.

<semi-rant> Security is always a concern at the moment.  If you build
a base infrastructure on something that is insecure, it's hard to
rearchitect in the future to build a secure system.</semi-rant>

> - Could someone point me to what would need to be added for this? Do
>   I need to implement a new ipmi device type that accepts
>   a "netdev=<id>" argument? If so, would that make sense for this new
>   device to also accept mac-address and ip configuration for this IPMI
>   interface? Or does that need to go elsewhere?

If you really wanted to do this, you would need to implement the IPMI
LAN protocol inside QEMU and sit it on top of a UDP chardev.  It could
then plug into the standard IPMI infrastructure in QEMU.  The power
management functions are already there.

The openipmi lanserv code is something you can steal from, it's at
https://github.com/cminyard/openipmi/tree/master/lanserv

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>
But there are many tools to accomplish this.

-corey

> 
> Thanks in advance for your guidance.
> 
> [1] https://github.com/Zexi/vbmc-qemu
> 
> -- 
> Robin
> 

Re: [Qemu-devel] -device ipmi-bmc-sim attached to -netdev vde

[Robin Jarry]

Hi Corey,

Thanks a lot for your detailed answer!

2019-02-19, Corey Minyard:
> If you really wanted to do this, you would need to implement the IPMI
> LAN protocol inside QEMU and sit it on top of a UDP chardev.  It could
> then plug into the standard IPMI infrastructure in QEMU.  The power
> management functions are already there.
> 
> The openipmi lanserv code is something you can steal from, it's at
> https://github.com/cminyard/openipmi/tree/master/lanserv
> 
> 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>
> But there are many tools to accomplish this.

Ugh, I feared this would not be a walk in the park :)

This is unfortunately too much work for me at the moment. I don't like
it but I think I will have to live with vms communicating through
a SLIRP device to access the ipmi lanserv daemon.

I just need to figure out how this works, because vbmc-qemu does not cut
it for me. It does not allow fine-tuning the QEMU command line.

-- 
Robin

Re: [Qemu-devel] -device ipmi-bmc-sim attached to -netdev vde

[Daniel P. Berrangé]

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 :|

Re: [Qemu-devel] -device ipmi-bmc-sim attached to -netdev vde

[Corey Minyard]

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 :|