KVM Support?

[Tanous, Ed]

> 
> Well, the VNC server (and Video Engine driver) integration is targeted for the
> OpenBMC release in February 2019. Hopefully in master before then. There
> is currently no plan or work being done to integrate a viewer into the BMC
> webui. But patches are certainly welcome in this area! It could be as simple as
> dropping in a noVNC html file... not sure.
> 

Not to disagree with you, but there's some work here:

https://gerrit.openbmc-project.xyz/#/c/openbmc/phosphor-webui/+/10268/

The webui side of it was just a matter of dropping novnc into the webui and routing the websocket back to the BMC.  The BMC side of it, implementing appropriate security on the websocket, and some other cleanup is on my back burner.  I'm at a bit of a crossroads, and I have two thoughts on how to proceed.

1. Rejigger the existing VNC kvm websocket implementation here to update to the new driver API, and delete all the JPEG to bitmap decoding code.  This solution essentially runs a websocket-only VNC server inside bmcweb. https://github.com/openbmc/bmcweb/blob/master/include/web_kvm.hpp
Pros:
A. Smaller overall binary size.  Libvncserver supports a lot of things that I suspect openbmc will never need to.  For example, the password authentication mechanisms for VNC/RFB protocol are woefully out of date by modern standards, so I suspect there's no sense in having that code at all.
B. Better security.  There is no VNC port that could be abused/ported to get access to the KVM session.  The websocket authentication and authorization infrastructure uses the same mechanisms as the rest of the webserver, so it reduces the attack surface.  Said another way, it's unlikely an attack on bmcweb would be able to target the VNC server specifically.
C. Fewer framebuffer copies compared to a websocket proxy (at least in theory).  It is one fewer trip of the large framebuffers through userspace, which should save us some copies.  At some point in the future if we got the Linux TLS subsystem going, we could likely build a no-copy, or single copy framebuffer solution, which should net us some performance by essentially keeping the buffers in the kernel.

Cons:
A. It needs to be written.  Hopefully the changes should be mostly deletes, and regiggering to pull framebuffers from the driver.  Keyboard and mouse would need to be hooked up to the gadget driver using the example from obmc-kvm.
B. It is a specific solution for openbmc, so it's unlikely to have much utility outside of the project.  Contributing to libvncserver "gives back" more to the open source community.

2. Use bmcweb as a websocket proxy to obmc-kvm server in a very similar way to how we proxy to obmc-console.
Pros:
A. Gives us full compatibility with standard socket VNC, which could be useful for debugging purposes.  I wouldn't recommend enabling it in practice without some other kind of authentication and encryption pipeline ahead of it.
B. The work to do this should be relatively minimal.  It should be essentially a copy-paste of the obmc-console socket code, a little debugging, and it should be mostly good to go.

Cons:
A. Larger binary size.  I need to get more exact numbers here, but adding a relatively large library (libvncserver) and another application (obmc-kvm) seems unlikely to be good for our flash usage.  As is, we're already pushing the limits of a 32MB flash.
b. Extra framebuffer copies.  Driver -> obmc-kvm -> bmcweb(with TLS)  -> browser  in theory is at least one extra copy.  It would be interesting to set up both in practice.
	
3. Some other option that I'm missing?

I'm very interested in what the community thinks here.  Is there a use case for having the standalone vncserver?

-Ed