Open Toaster Architecture
From OSDVwiki
The Open Toaster Architecture (OTA) is a way of describing the high-level structure of an operating system, software, and hardware platform for a Fixed Function Device (FFD). A FFD is, briefly, a computing device that exists to perform a fixed set of functions, and need not be changed in any way during the course of its life.
Contents |
[edit] Definitions
One key aspect of the OTA is that it supports a high-integrity FFP that is highly resistant to change. In this context, change means any of: running new software (new meaning not present at the time the FFD was created); modifying existing software as stored; changing the behavior of existing software via changes to configuration data; changing the behavior of the system by tampering with running software.
The use of the term “open” indicates that an OTA-based FFD can be created from commodity components without requiring proprietary technology. Open also indicates that an FFD, if composed of platform and application software that was open (including but not limited to open source), could be demonstrated to be a high-assurance high-integrity system.
The use of the term “toaster” is a whimsical way to indicate that an OTA implementation is typically intended to support devices that are as fixed in function as a toaster.
The term FFD is sometimes used as a shorthand for an OTA-based computing device.
The term IOTA, for Isolated OTA is a variant with this architecture, with the additional constraint that an IOTA implementation can support FFDs with I/O requirements that can be met by sneaker-net, that is, removable physical media used for input data sets and output data sets, together with local devices for additional data acquisition such as human interfaces and sensors.
In the context of OSDV, devices that are part of an election system are FFDs based on an IOTA implementation.
[edit] Stateless Hardware
Stateless hardware is a key architectural principle for OTA, and is in direct contrast to the standard PC architecture where:
- a read/write storage device contains the code and data needed to complete the boot process by loading an OS kernel, starting OS services, etc.,
- the boot device contains application software,
- as well as configuration data for the OS and applications,
- and all are modifiable within constraints implemented by the OS.
In an OTA-based system, R/W storage is not used for any state data. Rather, the foundation of the OTA is:
- A boot image that resides on read-only removable media.
- The boot image contains all the code and data for the OS, and other platform software (such as interpreters), and applications, and configuration data for all.
- The code on the boot image does not rely on any code or data stored on R/W storage devices in the hardware platform.
Note that truly "stateless hardware" has huge practical problems (and thanks to Rop for pointing this out in the discussion page), so in this context a more accurate description would just be the 3 bullets above plus a caveat, something like: "The execution of the code in the boot image can be affected by code and data in the hardware platform itself (such as BIOS or firmware in devices), which can be subject to change." (A crisper statement would be appreciated.)
[edit] Integrity Properties
For a FFD to be truly fixed in function, its platform must implement several integrity properties that are part of the OTA.
[edit] Read-Only System Image
Given such an FFD system image, the system image a whole must be un-writeable, and the OS should prevent modification of any of the files that reside in file-systems on the boot media. Given RO boot media, this architectural requirement is intended to be straightforward.
[edit] Exclusive-Execute System Image
The OTA-based platform of an FFD must enforce the constraint that the files on the boot media are the only files that can “launched” or “loaded”, or more generally, used as containers from which binary executable or interpreted code is accessed for execution. So, for example, if an FFD included application software that created new files (e.g., on a RW storage device), placed code in the file, and attempted to run code from the file, then the platform would prevent execution of that code.
Another way of looking at this aspect of an OTA is that an OTA platform enforces a sort of execution white list where the system image is the white list.
The use of the term “platform” here allows inclusion of non-OS software such as interpreters to have functions that help implement the property of exclusive-execute system image. For example, an interpreter could have an interface in which code is executed only via specification of files performed in launching the interpreter’s executable; and either the OS or the interpreter would do the white-list check for instances of an interpreter’s binary being executed.
[edit] Memory Execution Protection
An FFD’s integrity depends on the above properties. However, they are not sufficient to prevent “new code” from running on an FFD, because of the possibility of binary code injection. Therefore, the OTA includes properties for memory protection and controlled execution. Memory protection is essentially a set of OS memory management features that ensure that writable memory regions are not executable, and vice versa.
[edit] Controlled Execution Protection
Adequate memory protection features are sufficient to ensure that “new code” can find no place to “land” and execute. However, memory protection alone must be supplemented with countermeasures to instances in which a programming error allow carefully crafted input data to result in execution re-direction, that is, arbitrary execution of existing software. A well-known and reasonably effective countermeasure is address space layout randomization (ASLR).
Pax is good reference implementation of ASLR and memory execution protection.
Although ASLR can still permit execution re-directions that are “lucky guesses”, ASLR can be quite effective in the limited operational environment of an OTA-based FFD, especially an IOTA-based system, in which the ability to make multiple “guesses” is limited.
[edit] The Integrity Tipi
All the above properties taken together can be thought of as a tipi, a structure in which each supporting strut is supported by other struts, which together comprise a whole structure. In the case of OTA, the above properties comprise an integrity tipi; that is, each integrity mechanism can be bypassed, but the bypass is controlled by another integrity mechanism. The whole set of integrity mechanisms comprise an integrity control mechanism that is intended to un-bypassable, and always involved whenever code executes.
(Historical note: “Reference monitor” is a somewhat Jurassic term for a set of platform software that is intended to by un-bypassable and always invoked. Likewise “trusted computing base” (TCB) is a term used to describe a set of software that either implements a reference monitor, or implements a function upon which the reference monitor depends, or which could tamper with or bypass the reference monitor. For an OTA-based system, the OTA implementation, the platform, is a TCB for the integrity properties of a FFD.)
One common confusion about these specific integrity measures could be summed up in the question: “If these mechanisms are so useful, why aren’t they used in general purpose computing?” The answer is that some or even all of the mechanisms are each incompatible with a variety of existing and popular software packages, and even OS components. It is not possible to have a system that is both backwards compatible with such software, and implements “the whole tipi”.
Note that such issues can arise in the construction of an FFD, for example if a pre-existing software package can be used as part of the FFD’s application software, but that package is incompatible with the OTA. As part of the development of the FFD, it may be possible to either modify the package to be compatible, or to obtain or build comparable software is that is OTA-compatible.
For general-purpose computing, almost needless to say, the same is not true for the deployment of a required specific software package.
[edit] Execution Failure and Fault Tolerance
An important OTA concept is that execution failure does not compromise integrity.
It is possible that a programming error in OTA platform software, or FFD application software, could result in a scenario where there is an attempt to execute arbitrary code on an FFD, via use of the programming error. In practice, such a scenario would be likely to be intentional, an attack on the system via a security vulnerability resulting from the programming error. In some such cases, the result would be that some software on FFD would experience an execution exception; depending on how the system is constructed, a secondary result might be system shutdown or system crash. (In other, non-intentional cases, execution exception would be the typical direct effect of the programming error being exercised.)
Even in such cases, the integrity of the FFD is not compromised, and the next time the specific FFD is booted, it will start in the same expected state.
As a result, however, a robust FFD requires not only the use of the OTA, but also fault-tolerant system design and implementation to ensure orderly processing in spite of execution failures.
[edit] Residual Risk
TBD: a brief discussion of residual risk in that any tipi is not perfect. A longer discussion should be its own page.
[edit] OTA and the FFD Lifecycle: System Build Integrity
In many cases, a FFD needs to change behavior to respond to changes in the operational environment. To indicate how the OTA accommodates change, there is an excellent historical example: the Lucent Managed Firewall, which was notable as a commercial FFD product that used elements of the OTA.
The Lucent Managed Firewall used commodity hardware to run a system image that was delivered to the hardware on WORM media. The system boot disk was created by management system running on an ordinary PC. The management system included an administrative interface for defining network firewall configuration settings. These settings were recorded in configuration files that became part of the system boot disk. Hence, in order to “re-configure the firewall” one actually created a new system image for the firewall device, and re-booted the device on the new image.
The same approach is part of the OTA, with the extension that in addition to changing configuration data, in may be possible to “configure away” certain elements of the application software.
In automated election systems, polling place devices (e.g. ballot scanners, ballot markers, and DREs) are examples of devices that could be built as FFDs, but for which the “configure out code” function might be required. The reason is that in some use cases, a certain function is required, while in other cases it is not only not required, but there may be certification requirement that the un-required function be not implemented on the device.
A much more common case for voting devices would be changes in configuration data. Each election has its own distinct ballot— or rather distinct set of ballot styles – and data definitions of the ballot styles are part of the configuration data of, for example, a ballot scanner device. Thus, each election would have its own system image composed of the FFD software, the ballot definitions, and other configuration data.
[edit] Voting Devices: Example FFDs
Continuing the example of voting devices, a hypothetical FFD would consist of hardware, plus a system image as described above, delivered on a RO optical disk, and containing code that was compiled for the processor architecture of the hardware. The hardware would be commodity hardware that has the following components and properties: an optical disk device that can read the boot disk; firmware that boots the system from that device; hardware architecture that supports memory protection; a display device and human input device(s) needed for interacting with people during startup and shutdown, and (if required) interacting with a voter; a WORM disk writing device used to record output data such as ballots, tallies, etc. In addition, some types of device may have printers in order meet functional requirements for printing, for example, an EMB system printing a ballot, or a DRE system printing a paper record of the electronic ballot dataset.
[edit] Summary
The Open Toaster Architecture is a set of system architecture principles and system properties that is generally applicable to the design, construction, and operation of a variety of fixed function devices. Use of the OTA can result in an FFD being a high-integrity device. Use of the OTA, combined with sound development and documentation practices intended to support an independent system review (including source code disclosure), can result in a system with a high degree of assurance of integrity and potentially other properties.
Voting devices can be relatively simple, isolated FFDs, and hence are used as an explanatory example of OTA.
[edit] Acknowledgments and References
This stuff is hardly new thinking or rocket science by an stretch of the imagination. The foundational thinking, esp. for voting systems, was from Peter Neumann in 1993, and just as relevant today
The toaster concept is also descended from some nifty ideas in the Lucent Managed Firewall, and some avionics systems work on system-build security.
I'm sure there are more that belong on the list, and I'd be happy for more contributed references.
