Although 3D integrated circuit technology has typically been used to solve specific design goals, it has great potential for protecting intellectual property from theft or unwanted modification while at a third-party fabrication facility. We present analysis of a technique for splitting a design across multiple die layers for this purpose. From the perspective of a third-party, this technique effectively encrypts the circuit, preventing unauthorized use of, or alteration to, the design. The device is “unencrypted” at a secure final assembly location where it is oriented and bonded according to its secret key. As is true for any cryptographic technique, analysis of the algorithm or implementation may result in attacks with lower combinatorial complexity. We look at some of these potential attacks and discuss a number of possible solutions. Finally, we introduce the inter-die routing layer, which effectively complements the 3D splitting technique, making it much more difficult to develop attacks to bypass a brute force approach.

This chapter contains sections titled: Introduction Previous Robustness Testing Work Evolution of Ballista Lessons Learned Conclusions Acknowledgments References

Vorrichtung mit: An apparatus comprising: einem ersten Die (111) mit einer ersten Mehrzahl von Speicherzellen (MC) fur eine Speichermatrix (102) und a first die (111) having a first plurality of memory cells (MC) for a memory array (102) and einem zweiten Die (112) mit einer zweiten Mehrzahl von Speicherzellen (MC) fur die Speichermatrix (102), wobei der zweite Die eine gemeinsame Leitung (125, 135) aufweist, damit die Speichermatrix digitale Signale fur Speicherzellen der ersten und der zweiten Mehrzahl von Speicherzellen ubertragt, wobei die ersten und zweiten Dies voneinander getrennt sind und gemeinsam die Speichermatrix bilden. a second die (112) having a second plurality of memory cells (MC) for the memory array (102), the second having a common line (125, 135) to allow the memory array digital signals for memory cells of the first and the second plurality of memory cell transfers, wherein the first and second These are separated from each other and together form the storage matrix.

3D die stacking is an exciting new technology that increases transistor density by vertically integrating two or more die with a dense, high-speed interface. The result of 3D die stacking is a significant reduction of interconnect both within a die and across dies in a system. For instance, blocks within a microprocessor can be placed vertically on multiple die to reduce block to block wire distance, latency, and power. Disparate Si technologies can also be combined in a 3D die stack, such as DRAM stacked on a CPU, resulting in lower power higher BW and lower latency interfaces, without concern for technology integration into a single process flow. 3D has the potential to change processor design constraints by providing substantial power and performance benefits. Despite the promising advantages of 3D, there is significant concern for thermal impact. In this research, we study the performance advantages and thermal challenges of two forms of die stacking: Stacking a large DRAM or SRAM cache on a microprocessor and dividing a traditional micro architecture between two die in a stack

Software developers identify two main reasons why software systems are not made robust: performance and practicality. We demonstrate the effectiveness of general techniques to improve robustness that are practical and yield high performance. We present data from treating three systems to improve robustness by a factor of 5 or more, with a measured performance penalty of under 5% in nearly every case, and usually under 2%. We identify a third possible reason why software systems are not made robust: developer awareness. A case study on three professional development groups evaluated their ability to estimate the robustness of their software. Two groups were able to estimate their software's robustness to some extent, while one group had more divergent results. Although we can overcome the technical challenges, it appears that even experienced developers can benefit from tools to locate robustness failures and training in robustness issues.

With the recent introduction of Itanium Processor Family (IPF) microprocessors for enterprise servers it is imperative to understand the behavior of server class applications. This paper analyzes the behavior of the Oracle Database Benchmark (ODB), an online transaction processing (OLTP) workload, and compares it with SPEC CPU2000. This study examines code mix, instruction and data supply, and value locality. The results show that while IPF's bundle constraints cause a large injection of NOPs into the code stream, IPFs register stack engine successfully reduces the number of memory operations by nearly 50%. The control-flow predictability of ODB is better than CPU2000, in spite of ODB's large active branch footprint. Due to ODB's large memory footprint, cache misses (particularly instruction cache misses) are a much more serious problem than in CPU2000.

Lack of data quantifying the performance cost of implementing good exception handling often causes developers to skimp on exception handling based on its overestimated perceived cost. In an effort to remedy this problem we provide performance data on the cost of building good exception handling into software. We use the Safe Fast IO library as a basis for this study. SFIO improves robustness by a factor of 3 to 10 over STDIO without sacrificing performance. We were able to improve the robustness of the critical SFIO functions by another factor of 5, thus quantifying and reducing robustness failure rates by a factor of up to 70 from standard I/O functions, with an average performance penalty of 1% as measured by the original SFIO benchmark scheme. Future processor architecture improvements will further improve checking speed, essentially eliminating performance as an obstacle to improving software robustness.

Although our society increasingly relies on computing systems for smooth, efficient operation; computer “errors” that interrupt our lives are commonplace. Better error and exception handling seems to be correlated with more reliable software systems [shelton00] [koopman99]. Unfortunately, robust handling of exceptional conditions is a rarity in modern software systems, and there are no signs that the situation is improving. This dissertation examines the central issues surrounding the reasons why software systems are, in general, not robust, and presents methods of resolving each issue. Although it is commonly held that building robust code is too impractical, we present methods of addressing common robustness failures in a simple, generic fashion. We develop uncomplicated checking mechanisms that can be used to detect and handle exceptional conditions before they can affect process or system state (preemptive detection). This gives a software system the information it needs to gracefully recover from the exceptional condition without the need for task restarts. The perception that computing systems can be either robust or fast (but not both) is a myth perpetuated by not only a dearth of quantitative data, but also an abundance of conventional wisdom whose truth is rooted in an era before modern superscalar processors. The advanced microarchitectural features of such processors are the key to building and understanding systems that are both fast and robust. This research provides an objective, quantitative analysis of the performance cost associated with making a software system highly robust. It develops methods by which the systems studied can be made robust for less than 5% performance overhead for nearly every case, and often much less. Studies indicate that most programmers have an incomplete understanding of how to build software systems with robust exception handling, or even the importance of good design with respect to handling errors and exceptional conditions [maxion98]. Those studies, while large in scope and thorough in analysis, contain data from students with little professional programming experience. This work presents data collected from professional programming teams that measured their expected exception handling performance against their achieved performance. The data provides an indication that despite industry experience or specifications mandating robustness, some teams could not predict the robustness response of their software, and did not build robust systems.

Operating systems form a foundation for robust application software, making it important to understand how effective they are at handling exceptional conditions. The Ballista testing system was used to characterize the handling of exceptional input parameter values for up to 233 POSIX functions and system calls on each of 15 widely used operating system (OS) implementations. This identified ways to crash systems with a single call, ways to cause task hangs within OS code, ways to cause abnormal task termination within OS and library code, failures to implement defined POSIX functionality, and failures to report unsuccessful operations. Overall, only 55 percent to 76 percent of the exceptional tests performed generated error codes, depending on the operating system being tested. Approximately 6 percent to 19 percent of tests failed to generate any indication of error despite exceptional inputs. Approximately 1 percent to 3 percent of tests revealed failures to implement defined POSIX functionality for unusual, but specified, situations. Between 18 percent and 33 percent of exceptional tests caused the abnormal termination of an OS system call or library function, and five systems were completely crashed by individual system calls with exceptional parameter values. The most prevalent sources of these robustness failures were illegal pointer values, numeric overflows, and end-of-file overruns.

Robustness is becoming more important as critical software increasingly affects our daily lives. Success in building robust software requires understanding and improving the robustness of the operating system API, but to date there has been no accurate, reproducible way to measure robustness. This paper presents the first full-scale, quantitative measurements of operating system robustness. Each of 15 different operating system’s robustness is measured by automatically testing up to 233 POSIX functions and system calls with exceptional parameter values. The work identifies repeatable ways to crash operating systems with a single call, ways to cause task hangs within OS code, ways to cause task core dumps within OS code, failures to implement defined POSIX functionality for unusual conditions, and false indications of successful completion in response to exceptional input parameter values. Overall, only 55% to 76% of tests performed were handled robustly, depending on the operating system being tested. Approximately 6% to 19% of tests failed to generate any indication of error in the presence of exceptional inputs. Approximately 1% to 3% of calls tested failed to implement defined POSIX functionality for unusual, but specified, conditions. Between 18% and 33% of calls tested dumped core from within a POSIX function or system call, and five operating systems were completely crashed by individual user mode system calls with exceptional parameter values. The most prevalent sources of robustness failures were illegal pointer values, numeric overflows, and end-of-file overruns. The results indicate that there is significant opportunity for increasing robustness within current operating systems. However, the role of signals vs. error return codes is both controversial and the source of divergent implementation philosophies, forming a potential barrier to writing portable, robust applications. Acknowledgments: This research was sponsored by DARPA contract DABT63-96-C-0064.

Critical system designers are turning to off-the-shelf operating system (OS) software to reduce costs and time-to-market. Unfortunately, general-purpose OSes do not always respond to exceptional conditions robustly, either accepting exceptional values without complaint, or suffering abnormal task termination. Even though direct measurement is impractical, this paper uses a multiversion comparison technique to reveal a 6% to 19% normalized rate at which exceptional parameter values cause no error report in commercial POSIX OS implementations. Additionally 168 functions across 13 OSes are compared to reveal common mode robustness failures. While the best single OS has a 12.6% robustness failure rate for system calls, 3.8% of failures are common across all 13 OSes examined. However, combining C library calls with system calls increases these rates to 29.5% for the best single OS and 17.0% for common mode failures. These results suggest that OS implementations are not completely diverse, and that C library functions are both less diverse and less robust than system calls.