The success of modern computing can be largely attributed to abstractions. By abstracting away the intricate details of how lower level components work, users at higher levels of abstraction are able to focus their efforts on content creation instead. While abstractions can drastically reduce complexities, they can also hide important details resulting in lower performance and even unintended software vulnerabilities.
In this paper, we argue that today’s abstractions are overly generic resulting in the loss of important semantic and contextual information across abstraction boundaries. This loss of information leads to security vulnerabilities as well as inefficiencies. We suggest application specific abstractions as a potential solution and present a research agenda that builds upon recent results from the Electronic Design Automation and Program Analysis communities.
I. Introduction
In computing, abstraction is a technique used to hide certain complexities of machines. Users of an abstraction are presented with a simple and consistent model of the machine even though the underlying hardware and software could be extremely complex and ever changing. Abstractions effectively bisect developers into two groups (low and high) bounded together by an agreed upon interface specification. The low level developers ensure all operations defined in the interface are implemented for the low-level hardware and software configuration while the high-level developers focus on creating new systems by using the agreed upon interface. In this way, developers can focus on authoring software for a specific version of Windows, Linux, OSX, Android, iOS, or others without having to worry about how much physical memory is available or how files are organized on a disk.
Abstractions reduce development costs by ensuring that common low level operations are only implemented once and complexity is reduced. Take file access for example. One can require each application to implement their own filesystem or one can create a filesystem abstraction layer that implements the filesystem once, and allows the applications to reuse a single implementation through an abstraction interface. Modern computing systems use the latter approach because it is extremely rare that an application needs to worry about the specifics of how files are organized on a physical disk.
While abstractions can be a boon to productivity by simplifying the machine model and reusing code, it can also be a detriment to security and performance if they are used in a general purpose fashion as most modern usages are. We argue in this paper that security vulnerabilities can arise when abstraction layers fail to understand the semantics of high level requests. Similarly, there is a performance overhead when the high level applications fail to understand or have access to resources that have been abstracted away by the layer. Both cases arise because the abstraction layer was designed to be generic to support as many applications as possible, thus ignoring application specific requirements or opportunities.
We argue that more malleable application specific abstraction (ASA) layers are necessary to balance the competing factors of developmental cost/convenience, security and performance. We also argue that formal methods and automation can be used to facilitate the transition to ASA; and that these techniques are necessary for a future with an overabundance of transistors due to continued process scaling without power scaling.
The rest of the paper is organized as follows. We first present some background information on abstractions in modern computing as well as examples of how they can impact the security and performance of high level applications in Section II. We present background on why there is an overabundance of transistors in modern and future integrated circuits designs in the same section. These serve as the foundations to our research agenda discussions in Section III. In that section, we will present a small sampling of related work in the Electronic Design Automation (EDA) and Program Analysis (PA) research fields and discuss how ASAs require a multidisciplinary approach. Finally, we summarize our arguments in Section IV.