Hello Again!
I wanted to give a quick technical overview of KVM Remote.


What is KVM?
I assume that everyone here knows what KVM is. No? Alrighty then. KVM is really an acronym that stands for Keyboard-Video-Mouse. Basically it’s a generic term for allowing one computer to see what is on the screen of another computer and to be able to interact (via keyboard and mouse) as though someone were sitting at that computer. There are different reasons why you might want to use a KVM. For example let’s say you have two computers at home and one monitor/keyboard/mouse on your desk. You could use a hardware KVM switch to access one machine at a time (these are fairly inexpensive for 2-4 machines). “That’s nice, but my other computer is in the other room or in another building. I don’t have cables that long, what should I do?” Well I’m glad you asked.
In this case you’ll need a KVM solution that works remotely over a network. Now you have two choices, you can use a software based remote desktop product or a hardware KVM solution (these are often called IP-KVM solutions). I use a 3rd party hardware KVM in my lab to connect many machine to my monitor when I do testing. It works great! (the down side is that the cost per connection is very high, in my case it’s well over $100/connection!). Software solutions also work well... Well, I guess it’s better to say that a software solution works well as long as everything else on the system is working well. With a software solution you can’t do things like reboot, change BIOS settings, or work in safe mode (without networking). If only there was an inexpensive hardware solution that was built into all your platforms. Voila! Enter KVM remote control stage left.

(after all that rambling I just realized there is a wikipedia article on it. Of course there is. If everything I said made no sense at all, try this: http://en.wikipedia.org/wiki/KVM_switch )



Ok, on to what you’re really here for, the Intel KMV Remote Control high level architecture (i.e. how it works).

When you look at your screen you’ll see lot of different objects (in my case I have a word processor running, a couple web browsers, etc). These objects will be layered on each and your operating system will figure which is on top and what to display. The OS will collect all these objects, figure out what is visible and what is not and push all that data down to what is called a framebuffer. The framebuffer is effectively the memory that your video card sends out to the monitor. Basically it’s the last stop. Since the manageability engine (the little processor that runs AMT) can access this memory we can package it up and send it out to a remote computer so an IT administrator can see exactly what is on the user’s screen.
When a KVM session is initiated the manageability engine will make a copy of the current framebuffer and send it to a remote viewer. After that it will compare the current frame buffer to the cache. The comparison is done in 64x64 pixel tiles left to right, top to bottom. If there are any differences between the two the manageability engine will update its cache with the new tile and send out the tile to the viewer (at this point there may be other functions performed on the tile such as compression and encryption before its sent).


The protocol that is used to transport the data is the Remote Frame Buffer protocol (You can find out more info and download the specs from here: http://en.wikipedia.org/wiki/RFB). The nice thing about the RFB protocol is that it’s been around for a long time. The v3.3 revision of the protocol came out in 1998. Since it’s been around for so long you can find viewers for pretty much any platform (Windows, Linux, Unix, MacOS, there are even iPhone viewers! Have I mentioned I love wikipedia? Here is a table of various remote desktop viewers: http://en.wikipedia.org/wiki/Comparison_of_remote_desktop_software).
So now that we’ve talked about how the video gets from the client to the viewer, how does the mouse and keyboard make it? When a connection is established a virtual USB keyboard and mouse is ‘plugged in’ to the client (you’ll see new devices appear in device manager once a session is established). Keyboard commands and mouse movements (and clicks) are sent to the manageability engine. The manageability engine will send those commands to the virtual USB devices and thus the OS.


Now let’s talk about security. When a session is initiated the client will show a user consent form. The user consent form is placed directly into the framebuffer (this protects the user consent code from being detected by malware and helps to protect from unauthorized access. It also allows the user consent screen to be seen when it normally wouldn’t be seen such as when running on non-graphical OS like DOS). The user consent code is read to the IT administrator that is connecting to the system and the IT admin is able to connect. Once connected there is a 1 pixel red border around the screen and a blinking icon in the upper right corner of the screen. The client system can be configured to use TLS for encryption just like other AMT connections.


That’s mostly it from a high level. Thanks for reading!