(The official version of this article was made available in October, 2014.)
This article is actually co-written by Timothy D. Greer and a nameless technical writer. The tech writer had the first go at it based on the original invention disclosure, then Mr. Gwier tried to fix it up with clarifications, correction of falsehoods, etc. Legally powerful terms like "proactively" generally originated from the technical writer, while proletarian words such as "phony" came from later editing by the other guy.
Method and System for Controlling Guest Operating System Using A Covert Channel
Disclosed is a method and system for controlling guest operating systems (OS) using a covert channel. The method and system proactively sets up a covert channel between multiple levels of systems as, for example 1st level, 2nd level, etc. A controller continuously monitors, via the covert channel, activities of one or more guest OS running on any of the multiple levels of systems such as, for example on 2nd level systems. Monitored activities are thus evaluated and analyzed for controlling guest OS by the 1st level controller. The key aspect of controlling is messaging the systems when to start or stop, what memory configuration to use, and what workload to run, along with requesting status reports and receiving responses to those requests via the covert channel. Optionally, a plurality of controllers may issue requests and note responses. Third-level and higher systems may be controlled in the same manner, and by the same 1st level controller, by using the same CP1STLVL exit described later to pass through intervening levels.
The covert channel employed is a pair of 1st level commands SET/QUERY PRODUCT, whose original use was to indicate to guests whether a particular product was licensed to run. The use of the commands is redirected by specifying a phony product with a name chosen to correspond to a guest hosting a 2nd level OS. Except in the unlikely case that it conflicts with an actual product name, the phony product name chosen is the same as the 1st level UserID (Host UserID) hosting the 2nd level OS. Two key elements of control enabled via this channel are specification of the initial memory configuration of the 2nd level OS, and on-going status reports, load reconfiguration, etc. A guest, in particular a server, on the 2nd level system cannot normally issue commands (in particular SET/QUERY PRODUCT) to the 1st level system, so a CP exit, CP1STLVL, is added to the 2nd level OS to make possible the issuing of 1st level commands by a 2nd level guest. The covert channel communication mechanism depends on the 1st-level operating system having some function like SET/QUERY PRODUCT that allows guests to leave messages lying around for each other, and the 2nd-level operating system having a capability like CP1STLVL to allow its guest OS to issue 1st-level commands.
In accordance with the method and system, a configuration file is created which predefines a set of workloads. The configuration file is then placed on a storage disk for allowing it to be read-only to the 2nd-level systems and read-write to a controller. This allows the 2nd level systems to be directed to employ a particular workload to run, instead of needing to communicate workload details to the 2nd level system. Further, start and stop of guest operating system can be controlled by having the 2nd-level system come up automatically whenever a host user is logged in. For example, when the 1st level system is running the z/VM operating system, starting and stopping of the guest operating system in a virtual machine utilizes XAUTOLOG and FORCE commands respectively. However, before utilizing XAUTOLOG, a controlling user issues a command of the form,
SET PRODUCT Host UserID** STATE ENABLED DESCRIPTION desired memory configuration
**Product IDs are exactly 8 letters; the UserID is extended with dashes as required to meet the 8-letter requirement.
Upon getting auto-logged, the host user issues a corresponding command of form, QUERY PRODUCT PRODID Host UserID, which enables it to learn a type of memory configuration that is intended. If the host user is not already in the intended memory configuration, it changes its memory configuration to the intended configuration and re-starts. Further, when the host user receives an intended memory configuration, the 2nd level system starts a workload automatically, by reading the workload configuration file. Further, the 2nd level system loads a CP exit and starts a server. The CP exit is invoked with the command CP1STLVL. The exit allows the guest on the 2nd-level system to issue 1st-level CP commands and record responses from the 1st-level system. The server loops alternating sleep periods with issuing a command, CP1STLVL QUERY PRODUCT PRODID Host UserID.
Once the 2nd-level system is up, the controlling user periodically queries the system status and conveys start and stop commands and other requests by use of the same SET PRODUCT command, except modifying the description field to contain specific requests:
SET PRODUCT Host UserID STATE ENABLED DESCRIPTION request
The server on the 2nd level system sees such a request when it issues CP1STLVL QUERY PRODUCT as described earlier. Accordingly, the server checks the description field for keywords indicating some request from a list of expected requests. For example, "SEEKDUMP" is a request that the server check for dumps on the 2nd-level system. Further, when the server observes a request, it generates appropriate one-line response such as, for example, "No unprocessed dumps found" or timestamp and type information for the most recent unprocessed dump. Thereafter, the system issues CP1STLVL SET PRODUCT Host UserID STATE DISABLED DESCRIPTION one-line response and returns to its sleep/query loop. Thus, the server can tell whether there is a new request that it has not acted upon, because in that case the product state will be ENABLED. Likewise, the controlling user recognizes that the product description contains a response from the server when the product state is DISABLED. To indicate more general requests, eliminating excessive requirements for keywords, a few general keywords may be included, such as CPCMD to request that the server issue a CP command and respond with its output.
The controlling user on the 1st level system utilizes a controlling program for issuing requests via SET PRODUCT Host UserID STATE ENABLED DESCRIPTION request (e.g. "SET PRODUCT Host UserID STATE ENABLED DESCRIPTION SEEKDUMP"). Thereafter, the controlling program is allowed to halt for a sleep time of the 2nd-level server, and can eventually expect to see the reply by issuing a command, QUERY PRODUCT PRODID Host UserID. Accordingly, if the state is ENABLED, the control program understands that the 2nd-level server is not responding and if the state is DISABLED, the control program understands the description as the response.
An entire request/response sequence has the following form:
1st-level controller issues
SET PRODUCT Host UserID
STATE ENABLED DESCRIPTION request
2nd level server issues
2nd level server reacts to the request by taking some action and,
depending on the result of that action, forms a one-line response
message response.
2nd level server issues
CP1STLVL QUERY PRODUCT PRODID Host UserID
and notices that the state is ENABLED.
It therefore reads the request.
CP1STLVL SET PRODUCT Host UserID STATE DISABLED
DESCRIPTION response
1st-level controller issues
QUERY PRODUCT PRODID Host UserID
and notices that
the state is DISABLED. It therefore reads the response.
Except when the 1st-level controller has initiated a request/response sequence as above, the 2nd level server alternates sleep periods with issuing CP1STLVL QUERY PRODUCT PRODID Host UserID to watch for the ENABLED state.
Advantageously, the covert channel has little impact on other activities and would not be expected to show up in measurements. This particular covert channel is also trivial to use and requires no additional setup other than agreement by the parties on protocol. Compare, for example, the well-known communications method of reserving a portion of the guest operating system's memory for a communication pathway. That implementation means guest resources, employed externally, remain forever off-limits.
Thus, the method and system efficiently controls a guest operating system using a covert channel.
The information provided, and views expressed on this site are my own and do not represent the IBM Corporation.