Difference between revisions of "Trusted Execution Environment"

From MgmtWiki
Jump to: navigation, search
(Full Title or Meme)
(Full Title or Meme)
Line 1: Line 1:
 
==Full Title or Meme==
 
==Full Title or Meme==
For any digital [[Entity]] to make trustworthy statements, it must have embedded cryptographic means to sign any statement that it issues.
+
For any digital [[Entity]] to make trustworthy statements, it must have fully protected cryptographic means to sign any statement that it issues.
  
 
==Context==
 
==Context==

Revision as of 17:14, 27 July 2018

Full Title or Meme

For any digital Entity to make trustworthy statements, it must have fully protected cryptographic means to sign any statement that it issues.

Context

Early History

The origin of computers built with any sort of trusted execution is an IBM 7094 with two separate memory banks with a switch that was designed and built at MIT to support CTSS, the Compatible Time Sharing System. One bank ran kernel code and the other user code, although those were not the terms used at that time. The following quote describes the changes made for MIT.[1]

  • The hardware RPQs that made CTSS run on MIT's 7094s added an interval timer (B/M 570220) and memory boundary and relocation registers (RPQ E007291) to the 7094 processor. In addition, the MIT machines had two 32K core [36 bit word] memory banks instead of one (RPQ E02120). Core bank A held the CTSS supervisor, and B Core was used for user programs. (RPQ stood for Request Price Quotation. IBM, in those days, would engineer and sell features not part of the standard product, for a price.) More importantly, the RPQ made the 7094 a two-mode machine. When the machine was running a program in B-core, many instructions were forbidden: executing them caused the machine to trap and take its next instruction from A-core. In particular, I/O instructions were forbidden, as well as attempts to switch core banks.

The following quote is a description of the method to switch between user (slave) and kernel (master) modes in the GE 645.[2] Which was designed by MIT & GE specifically to take over operation of the CTSS. It was later replaced with the Honeywell 6180 that had modest success running the Multics operating system.

  • Because it was felt desirable to make it possible to branch easily between various programs including between slave and master programs, a certain degree of insurance has to be built into the hardware to guarantee that spurious branches would not take place into the middle of master mode programs from slave programs. As a consequence, a master mode procedure when viewed from a slave mode procedure appears to be a segment which can neither be written nor read. Further, the only method of addressing this segment that is permitted is a branch to the 0th location. Any attempt to get at other locations by branch, execute, return or any other instructions will result in an improper procedure fault causing an appropriate interrupt.

IBM did not want to be left out of the time-sharing market and so built the 360/67 to support time-sharing. It did not fit into their normal marketing program and was not successful in the same way that the rest of the 360 line of computers were.[3]

A1 classification

Co-processors

Security Boundaries

References

  1. Tom Van Vleck, The IBM 7094 and CTSS http://multicians.org/thvv/7094.html
  2. E. L. Glaser +2, System Design of a Computer for Time Sharing Applications, 1965 Fall Joint Computer Conference
  3. "IBM 360, Model 67, Computing Report for the Scientist and Engineer," 1, 1 (May 1965) p. 8, Data Processing Division, I.B.M. Corporation.