>From owner-simulators Wed Aug 16 11:37:47 1995 Received: from meitner.cs.washington.edu (meitner.cs.washington.edu [128.95.2.104]) by june.cs.washington.edu (8.6.12/7.2ju) with ESMTP id LAA17785; Wed, 16 Aug 1995 11:37:47 -0700 Received: from localhost (localhost [127.0.0.1]) by meitner.cs.washington.edu (8.6.12/7.2ws+) with SMTP id LAA00522; Wed, 16 Aug 1995 11:37:47 -0700 Message-Id: <199508161837.LAA00522@meitner.cs.washington.edu> To: rtcg@cs, simulators@cs Subject: [Deutsch & Grant 71] -- dynamic instrumentation, n-code verification Date: Wed, 16 Aug 1995 11:37:47 PDT From: " pardo@cs.washington.edu" X-Message-Id: simulators@cs.washington.edu, message #1995-08-007 X-Unsubscribe: e-mail `majordomo@cs.washington.edu', body `unsubscribe simulators' X-URL: `pending' [Summary: dynamically download machine code into another program; use machine-code verification to ensure the recipient can't suffer errors.] %A Peter Deutsch %A C. A. Grant %T A Flexible Measurement Tool for Software Systems %J International Federation for Information Processing Congress 71 (IFIP), booklet TA-3 %C Ljubljana %D August 1971 %P 7-12 %I North-Holland Publishing Co. %W ghost@aladdin.com %X The `Informer' is a debugging/profiling tool for inserting user-defined instrumentation/debugging code into another software entity (in this case, the operating system) without allowing the user code to cause failures. RTCG interest: code is dynamically loaded into the OS. Describes one solution to the ``moving code across protection domain boundaries'' problem. History of instruction patching. ABSTRACT: ``Implementors of large programming systems have come to realize the desirability of a flexible facility for measuring these programs. The applications of such a facility are tracing, monitoring for special conditions, and gathering statistics for performance evaluation. Our work will discuss a particular measurement tool, called the Infomer, now being used to measure the time-sharing operating system of the SDS-40 at Berkeley. The Informer provides an environment in which user written programs may serve as measurement routines. Measurement routines may be inserted dynamically to be called when control reaches arbitrary locations within the measured program. An important quality of this mesaurement facility is that no error in its use can cause a system failure. Also, system degradatation due to measurement programs can be automatically controlled. The Informer is a software system -- no hardware probes are employed. (pg 8) One goal is to minimize the time to compose, submit and debug measurement code. Thus, Informer accepts any code that can be transformed to machine language. Machine language is then examined/rewritten to ensure that when it is run it can't corrupt the system being studied. Assurance process takes ``milliseconds''. (pg 8) Reinserting measurement code is also a part of the standard crash recovery process so that measurements can continue for a long time. (pg 8) Informer uses a general user<->system communication facility. (pg 8) The basic tool augments the studied system with user code fragment so that the user code is invoked every time a particular address is executed. Implemented by the ``time-honored'' technique of patching the address with a branch instruction that branches to code that saves state, calls the user code, restores state, executes the displaced instruction, and returns to the successor. The system receiving the code is supposed to be unaware of the code; thus state saving uses an area specifically set aside for the purpose. (pg 9) Beware cost of saving and restoring state. (pg 9, 10) Complications from varying priority levels. (pg 9) Forbid instrumentation of (1) data areas (2) nonstandard references such as `execute' instruction, modified or sometimes used as data (3) severe timing constraints. The author of the system must identify critical areas where instrumentation is disallowed. (pg 9) Arbitrary machine code can be used for instrumentation. A program verifier ensures that the user code cannot modify or invoke the system; execute illegal or privileged instructions; run for ``too long''; modify instructions; read private data. Checking is simplified by structuring the memory according to usage, e.g. program, literals, temporaries, address temporaries, switches. (pg 9-10) Checking is also simplified by restricting the machine code constructs, e.g., backwards branches are only allowed where they implement bounded iteration, thus ensuring timliness. Dubious instructions, such as some runtime address computations, are checked by transliterating instructions into calls to runtime-checked equivalents. Mutual recursion is prevented by interprocedural verification; when a user routine is reimplemented, causes reverfication of all callers. (pg 9) As for ``cannot modify themselves'', Pardo has the same problem as with [Wahbe et. al. '93: Software-Based Fault Isolation], namely that self-modification can be allowed if includes the the verification mechanism. For example, verification could be one part of the `fly' implementation [Keppel 91: A Portable Interface ...]. (pg 10) Timing checking uses a worst-case estimate of the time with upper bounds for instructions with variable timing. The author of the system being measured provides a map of maximum allowable instrumentation times. User code is rejected if it might take too long. Since user routines can call other user routines, verification is rerun when the call order changes (e.g., a routine is replaced). (pg 9-10) Unclear to Pardo how page faults interact with timing and correctness analysis. One answer might be that all addressing uses physical addresses. (pg 12) Experience with Informer includes frequence and duration of system calls; response times; analysis of OS overhead; analysis of user characteristics. Took four person-months to construct. Once operational has not been known to cause an OS crash. Does not provide the facility to execute code on data accesses. (pg 12) Idea/technique due to Remi F. Despres, 1968.