qKVMDocs
All pages

Intel AMT

A business PC with Intel vPro Enterprise has a management engine beside its processor (Intel AMT) that answers while the PC is off, asleep or hung. qKVM speaks WS-Management to it, as Intel's own tools do, and reads its screen through the engine's own KVM. This is experimental: it was built from Intel's published class reference and MeshCommander's published source (read to learn the redirection handshake, not copied), tried against a stand-in, and tried on one real machine, a business PC with Intel AMT 16 set up by hand in admin control mode without user consent (see Limits for what exactly). Add a PC like a KVM: type its address, with the engine's user name (admin, as it comes) and password, and qKVM recognises it. Find KVMs on my network finds such PCs as well.

What a PC's tile gives:

  • Whether it is on, off, sleeping or hibernating, as the engine reports it. A PC that is off is there, and dark, as a server that is off is; one asleep is shown as on.
  • What the PC is: make, model and serial number, processor and memory, the BIOS version, the AMT firmware version, and the name the engine has for it (the tile's name, unless you give it one). The tile says PC with Intel AMT where a server's says Server.
  • Its screen, through the engine's KVM, where the PC was set up in admin control mode with user consent off, and its KVM is switched on: on the tile, enlarged, and on the live line, where Control sends its keys and the pointer. Send keys, Type text and the saved actions that press keys work as for a KVM. Where its screen cannot be had, the tile says why, in plain words: the KVM is switched off (on the engine, or in the MEBx), the PC is vPro Essentials (no KVM), or a session needs the code the PC shows on its own screen (client control mode always asks for one; admin control mode does where consent is on), which a wall cannot type. No session is opened then, not even to find out: the code would appear on the PC's screen for nothing.
  • Whether its KVM could be used, and the control mode the PC was set up in, client or admin, as the tile's enlarged view says.
  • The power buttons. Power on, and Shut down, which asks the operating system (that needs Intel's management service in the operating system; where the engine does not offer an orderly shutdown, the button says so and does not pull the plug instead); Hold power button cuts the power; Press reset button resets a PC that is on (one that is off is sent nothing, and the button says so, as for a guest of Proxmox). Start into BIOS setup arms the PC's firmware setup for its next boot (once) and then switches it on, or resets it if it is on, so it comes up straight in its BIOS setup; its large view opens so the setup screen shows from the start, and a session is opened before the press when that view is open (see below). A PC that is already on, or already off, is left as it is and says so, as a server is. Done means seen: after switching on or cutting the power, qKVM waits to see the PC in its new state, and says so if it does not. On the real machine: switched on, it was seen on after 2 to 13 seconds (its engine answers slowly while the PC starts); its power cut, the screen went dark at once and the engine said "off" after 12 to 15 seconds. A shutdown is done once the engine has taken it: Windows then says "You're about to be signed out" for a minute and shuts down, and the tile says Off about 80 seconds after the click. A reset is done once the engine has taken it too: the PC's power does not change, so there is nothing to see it by.
  • No power cut while a KVM session is open. The engine neither offers cutting the power (nor a power cycle) while somebody has its KVM or its serial console open, nor does it when asked, and lists it again about a second after the session ended. qKVM closes its own session for Hold power button, waits up to five seconds for the engine to offer the cut again, and opens no session until the PC is seen off; another viewer's session (Intel's own tools, say) it cannot close, and the button says why nothing was done. A PC that went off meanwhile is sent nothing. A command whose answer did not come back, or came back as something that cannot be read (no ReturnValue, or no SOAP at all), is said to have perhaps been done, as for every device: look at the PC before pressing again. Only a SOAP fault, a refusing ReturnValue or an answer of the 4xx kind says that it was not done.
  • The PC it was added for, and no other. Over plain HTTP, or with its certificate not checked, nothing else tells one engine from another, and PCs set up alike often have one password and one Digest realm: after a new lease another PC may answer at a tile's address. qKVM remembers the number the PC gives for itself (its PlatformGUID) when it is added, and keeps it in an export file. Before every power command and before switching its KVM it asks for the number again, and sends the command, and reads what the command is decided by (its power, its KVM's settings), only under the nonce that answer came under: an engine takes only nonces it handed out, so what takes the command is the PC that was asked. Where the engine hands out another nonce meanwhile, or says no, it is asked again (three times at the most, then the button says that nothing was done). No look runs in between. Before each session to its screen it asks again as well. A look reads the number every ten minutes, and at once where the engine answers in another realm. Where another PC answers, or one that names no number, nothing is done to it (no power command, no key, no session to its screen), and the tile says so from the moment that is seen (a look, a button, the screen) until this PC answers there again. If it is the PC this tile is for now (its board was changed, say), edit the tile and type its password. A tile with no number yet (added while its PC could not be reached, or from a file without it) takes the first one it sees, as a certificate is remembered on first contact. An account that may not read the hardware asset information gets no number, nor does an engine that cannot say it; such a PC is not told apart this way, and works as before. That an engine takes only its own nonces is how Digest is meant to work, and was tried on a real engine (see Limits).
  • Start into BIOS setup. Start into BIOS setup arms the firmware setup for the next boot, once (Intel's AMT_BootSettingData with BIOSSetup, made the next boot by CIM_BootService.SetBootConfigRole as a single use, with every other boot option set to its own safe value so nothing another tool left pending is carried out), then switches the PC on where it is off, or resets it where it is on, so it comes up in its BIOS setup. The question before it names the PC and says whether it will be switched on or reset. Where a boot option that destroys data (a secure erase) is already armed, qKVM does nothing (it neither clears it nor carries it out) and says so. The setup boot is single use: it clears at the next boot whether or not qKVM boots it; and where it could not be armed in full, or the power change is refused for certain (a refusal, or a SOAP fault), qKVM clears it again, so no ordinary boot lands in the setup (it reads first, and does not write over a boot option that destroys data which another tool armed by then: that is said instead; a setup boot armed already before the press is left as it was, and said). Where the power change's answer is lost or cannot be read, or a PC switched on is not seen to come on, the boot is left armed and the button says so; a reset the engine takes is not seen done, and the boot stays armed until the PC boots. A PC that is changing its power state just then is left alone. A press that has not come to its power change within two minutes (as over Redfish) sends nothing more and clears what it armed; nothing under way is cut off for that. An operator or an admin may press it; it is written in the activity log; it is for one machine at a time, not a bulk run (it opens the machine's large view to show the setup screen). A PC whose engine says it cannot do it (AMT_BootCapabilities) is not offered the button.
  • Consent is read at most every five minutes. How the KVM is set up (its control mode, whether user consent is on, whether it is switched on) is read afresh at most every five minutes. The engine enforces consent itself, so where consent was switched on since the last look, at most a few short sessions are begun (which the engine refuses, or shows its code for) until the next look re-reads it and no more are.

The screen, as the engine gives it. The KVM is reached on the engine's redirection port (16995 with TLS beside 16993, 16994 beside 16992), with the same account and password, a Digest sign-in of Intel's own, and the certificate qKVM remembered on 16993 (the engine shows the same one on both). Then the engine speaks RFB, as a VNC server does. qKVM knows the redirection port only beside the engine's own ports: an engine reached at another port (forwarded by a gateway) has its state and its power buttons on the tile, and the tile says that its screen needs the engine's ports forwarded as they are. What a real engine was seen to do, and what qKVM does about it:

  • A still now and then for a tile that is only shown; a held session only for the large or live view. A tile that is only shown on the wall gets a still picture every five minutes, each one a short session: qKVM opens the KVM, takes one frame, and closes it, so Intel's border is on the PC's own monitor only for the few seconds that takes. Between stills the tile shows the cached picture and says how old it is. Only while the machine is enlarged, or its live view is open, does qKVM hold a session open and ask it for what changed at a viewer's pace. A still is also taken at once when the tile first appears and after a power change is seen. While another viewer (Intel's tools, say) has the KVM, the engine refuses a session, and the tile says so; qKVM asks again every fifteen seconds (asking costs the engine nothing). A still that gives up waiting for its session (a slow engine: some forty seconds) closes the session it began, or, where its sign-in is on its way just then, closes it the moment it is open: it is not left open, and held, for a picture nobody takes.
  • The PC's own monitor shows a red and yellow border around the whole screen while a session is open: Intel AMT draws it there, and it is not in the picture the engine sends. So the border is on the PC only while somebody watches it close up (the large or live view), and for the few seconds each still takes, not for a tile that merely sits on the wall.
  • The first picture takes seconds. The engine takes only 16-bit colour, sent as raw pixels at about 1.5 MB/s: a whole screen of 2560 by 1440 came in about five seconds; after it, only what changes is sent, which is quick. (Offered the packed encoding it has, the engine packed one rectangle in thirteen and the whole screen came no sooner, so qKVM does not ask for it.)
  • The engine ends a session at its own time (its SessionTimeout, three minutes on that machine, whatever was asked meanwhile). qKVM opens the next one at once, and the tile keeps its last picture for the seconds that takes.
  • Keys sent in the first moments of a session are dropped by the engine, so qKVM waits half a second after the handshake before it sends any.
  • While the PC starts, its engine is too busy for a new session: on the real machine none was opened in time until 27 to 37 seconds after switching on, about when Windows began to load, and the tile says that the PC is starting. A session that is open when the PC is switched on, or reset, goes on through the start and shows it: the BIOS's "Waiting Up to 8 Minutes For KVM FW" (it waits a few seconds for the KVM when a session is open), the maker's logo, Windows loading. The engine opens a session for a PC that is off as well (a black screen of 800 by 600); qKVM opens none for a tile that is only shown then.
  • Showing the start. Because a session opened after Power on (or Start into BIOS setup) mostly does not get through until Windows loads, while one open before the press shows the whole start, qKVM opens a session before switching the PC on when the machine's large view or its live view is open (where its screen may otherwise be had; the page says so with the press, as it asks nothing of a PC that is off), and the press waits for that session: the setup or boot shows from the first moment. For a tile that is only shown, the press does not wait on a session, and Intel's border is not drawn on the PC for a start nobody is watching. A session held for the large or live view is let go of a minute after the view closes.

The serial console (Serial over LAN) is not on the wall. qKVM has a reader for it: the same port and sign-in as the KVM, read only (nothing is ever sent to the PC), what the PC writes kept in a bounded buffer, a ping every two seconds that the engine answers, and the console ended as the engine expects. On the real machine it opened, stayed open and was ended as it should be, and the PC wrote nothing there worth showing: nothing while Windows ran or started (Windows writes to it only where its Emergency Management Services are switched on), and, started into its BIOS setup with Serial over LAN asked for, a graphical BIOS sent the codes that clear a terminal and nothing else. So nothing in this version shows it: no PC that writes text there was at hand. While a serial console is open, the engine does not cut the power either.

What the owner of such a PC sets up, and what qKVM does with it:

  • Intel AMT is switched on in the MEBx (Ctrl+P at boot, or the BIOS setup): a password for it, network access, and the engine's host name. There are two ways of setting a PC up, and the engine remembers which: client control mode comes from a tool run inside the operating system (host-based setup) and makes user consent mandatory for every KVM session; admin control mode comes from the MEBx, a USB setup file or remote configuration with a certificate, and lets consent be switched off. Power and state need no consent either way. For its screen on a wall, set the PC up in the MEBx (that is admin control mode) and switch User Consent to None there. A wall cannot type the code a session asks for, and in client control mode every session after two minutes without one asks for a new code.
  • Its KVM switched on. In the MEBx, KVM is on as it comes; on the engine itself a PC set up by hand comes with its KVM and its redirection listener off. An admin can switch both on from the tile (enlarged: Switch on its KVM), which says first what that changes (the listener serves the engine's serial console and remote storage as well), and the KVM off again under Actions, which leaves the listener as it is; both are written in the activity log. It is a setting of the PC's, kept by its engine, and qKVM never changes it by itself. Intel's own tools switch it as well. Where the MEBx has it off, only somebody at the PC can switch it on.
  • Two ports. The engine listens on 16993 with TLS and on 16992 plain. qKVM asks both and takes TLS wherever the engine offers it; its certificate (the engine's own) is remembered on first contact, as a KVM's is. Intel has deprecated the plain port and refuses it from the network on newer platforms (from the CSME 16.1 firmware of 2022 on; CSME 19 is TLS only). Where nothing listens on 16993 and the plain port answers, the PC is added that way and the list of what was added says so, as does the tile. Where something on 16993 takes the connection and does not answer as an engine (no answer in time, or a TLS handshake that fails: an old engine, or one busy while its PC starts), nothing is added and qKVM says so; an address typed with https:// is never answered the plain way. Type the port yourself to settle it (http://192.168.1.60:16992). Find KVMs on my network goes by the same rule: it lists a PC at its plain address only where nothing listens on 16993, at its TLS address where something there is slow or fails the handshake, and not at all where something else answers there. Added with the kind amt through the API and no port, the engine is at its own port (16993, or 16992 for http://), not at 443 or 80.
  • The sign-in is HTTP Digest, as the engine wants it, on both ports: the password itself never travels, a hash made with a nonce from the engine does, and it is only ever sent to the address the password was saved for, after the engine has asked for it. Over the plain port a weak password can still be guessed from what travels by whoever listens on the network, which is one more reason for 16993. A password the engine refuses, on either port, is left alone as every device's is (see Servers): a minute, five, a quarter of an hour, then hourly. Intel AMT locks an account after a few wrong passwords.
  • The account decides what works. The engine's admin account can do everything here. An account of your own needs the realms for remote control (the power buttons), the hardware asset information and the general settings (the name), and for the screen the redirection realm (an account other than admin was not tried); whatever it may not read is shown as not said.