Stack Pointer Research Articles

FLAShadow: A Flash-based Shadow Stack for Low-end Embedded Systems

Runtime attacks are a rising threat to both low- and high-end systems with the spread of techniques such as Return-Oriented Programming (ROP), which aims at hijacking the control flow of vulnerable applications. Although several control flow integrity schemes have been proposed by both academia and the industry, the vast majority of them are not compatible with low-end embedded devices, especially the ones that lack hardware security features. In this article, we propose \(\sf {\textsc {FLAShadow}}\) , a secure shadow stack design and implementation for low-end embedded systems, relying on zero hardware security features. The key idea is to leverage a software-based memory isolation mechanism to establish an integrity-protected memory area on the Flash of the target device, where \(\sf {\textsc {FLAShadow}}\) can be securely maintained. \(\sf {\textsc {FLAShadow}}\) exclusively reserves a register for maintaining the integrity of the stack pointer and also depends on a minimal trusted runtime component to avoid trusting the compiler toolchain. We evaluate an open-source implementation of \(\sf {\textsc {FLAShadow}}\) for the MSP430 architecture, showing an average performance and memory overhead of 168.58% and 25.91%, respectively. While the average performance overhead is considered high, we show that it is application dependent and incurs less than 5% for some applications.

Buddy Stacks: Protecting Return Addresses with Efficient Thread-Local Storage and Runtime Re-Randomization

Shadow stacks play an important role in protecting return addresses to mitigate ROP attacks. Parallel shadow stacks, which shadow the call stack of each thread at the same constant offset for all threads, are known not to support multi-threading well. On the other hand, compact shadow stacks must maintain a separate shadow stack pointer in thread-local storage (TLS) , which can be implemented in terms of a register or the per-thread Thread-Control-Block (TCB) , suffering from poor compatibility in the former or high performance overhead in the latter. In addition, shadow stacks are vulnerable to information disclosure attacks. In this paper, we propose to mitigate ROP attacks for single- and multi-threaded server programs running on general-purpose computing systems by using a novel stack layout, called a buddy stack (referred to as Bustk ), that is highly performant, compatible with existing code, and provides meaningful security. These goals are met due to three novel design aspects in Bustk . First, Bustk places a parallel shadow stack just below a thread’s call stack (as each other’s buddies allocated together), avoiding the need to maintain a separate shadow stack pointer and making it now well-suited for multi-threading. Second, Bustk uses an efficient stack-based thread-local storage mechanism, denoted STK-TLS , to store thread-specific metadata in two TLS sections just below the shadow stack in dual redundancy (as each other’s buddies), so that both can be accessed and updated in a lightweight manner from the call stack pointer rsp alone. Finally, Bustk re-randomizes continuously (on the order of milliseconds) the return addresses on the shadow stack by using a new microsecond-level runtime re-randomization technique, denoted STK-MSR . This mechanism aims to obsolete leaked information, making it extremely unlikely for the attacker to hijack return addresses, particularly against a server program that sits often tens of milliseconds away from the attacker. Our evaluation using web servers, Nginx and Apache Httpd , shows that Bustk works well in terms of performance, compatibility, and security provided, with its parallel shadow stacks incurring acceptable memory overhead for real-world applications and its STK-TLS mechanism costing only two pages per thread. In particular, Bustk can protect the Nginx and Apache servers with an adaptive 1-ms re-randomization policy (without observable overheads when IO is intensive, with about 17,000 requests per second). In addition, we have also evaluated Bustk using other non-server applications, Firefox , Python , LLVM , JDK and SPEC CPU2006 , to demonstrate further the same degree of performance and compatibility provided, but the protection provided for, say, browsers, is weaker (since network-access delays can no longer be assumed).

HelaNER 2.0: A Novel Deep Neural Model for Named Entity Boundary Detection

Named entity recognition (NER) is a sequential labelling task in categorizing textual nuggets into specific types. Named entity boundary detection can be recognized as a prominent research area under the NER domain which has been heavily adapted for information extraction, event extraction, information retrieval, sentiment analysis etc. Named entities (NE) can be identified as per flat NEs and nested NEs in nature and limited research attempts have been made for nested NE boundary detection. NER in low resource settings has been identified as a current trend. This research work has been scoped down to unveil the uniqueness in NE boundary detection based on Sinhala related contents which have been extracted from social media. The prime objective of this research attempt is to enhance the approach of named entity boundary detection. Considering the low resource settings, as the initial step, the linguistic patterns, complexity matrices and structures of the extracted social media statements have been analyzed further. A dedicated corpus of more than 100,000 tuples of Sinhala related social media content has been annotated by an expert panel. As per the scientific novelties, NE head word detection loss function, which was introduced in HelaNER 1.0, has been further improved and the NE boundary detection has been further enhanced through tuning up the stack pointer networks. Additionally, NE linking has been improved as a by-product of the previously mentioned enhancements. Various experimentations have been conducted, evaluated and the outcome has revealed that our enhancements have achieved the state-of-art performance over the existing baselines.

Active Processor Hardware Stack

The characteristic features of the reduced instruction set computer (RISC) architecture are used to develop high-performance microprocessors and microcontrollers. Complex operations, which include subroutine calls and interrupt service, are difficult to implement in hardware for the same time interval with all the other commands. Such operations, when executed, involve recording the value of the transition address in the register of the processor’s software counter while saving the return address from the subroutine. A specific design of the processor hardware stack is proposed in the work, which allows performing complex machine operations in one clock cycle. It is established that the required technical result can be achieved by introducing in the design of the processor N identical software counters, which are actually analogues of the stack registers. It is shown that a stack pointer (SP) with the logic of the register selection connected to a block of program counters (PCs) activates the next PC when a subroutine is called or an interrupt is serviced, while the previous counter stores the return address from the subroutine. This excludes the procedures of saving the return address from the PC in the registers of the stack or the RAM cells and restoring its state from the stack. This allows us to make a subroutine call or jump along the interrupt vector and return to the call point in one clock cycle of the master oscillator. As a result of this, it becomes possible to increase the processor’s speed during such operations by 30–50% and improve overall performance without increasing the clock frequency.

KnightSim: A Fast Discrete Event-Driven Simulation Methodology for Computer Architectural Simulation

In this paper we introduce a fast discrete event-driven simulation methodology, called KnightSim, that is intended for use in the development of future computer architectural simulations. KnightSim extends an older event-driven simulation library by (1) incorporating corrections to functional issues that were introduced by the recent additions of stack protection, pointer mangling, and source fortification in the Linux software stack, (2) incorporating optimizations to the event engine, and (3) introducing a novel parallel implementation. KnightSim implements events as independently executable x86 “KnightSim Contexts”. KnightSim Contexts comprise a mechanism for fast context execution and automatically model occupancy and contention, which readily lends itself to use in computer architectural simulations. We present the implementation methodologies of KnightSim and Parallel KnightSim with a detailed performance analysis. Our performance analysis makes direct comparisons between KnightSim, Parallel KnightSim, and the discrete event-driven simulation engines found in three different mainstream computer architectural simulators. Our results show that on average KnightSim achieves speedups of 2.8 to 11.9 over the other discrete event-driven simulation engines. Our results also show that on average Parallel KnightSim can achieve speedups over KnightSim of 1.89, 3.33, 5.84, and 9.24 for 2, 4, 8, and 16 threaded executions respectively.

Analyzing pushdown systems with stack manipulation

Pushdown systems with transductions (TrPDSs) are an extension of pushdown systems (PDSs) by associating each transition rule with a transduction, which allows to inspect and modify the stack content at each step of a transition rule. In this work, we propose two novel saturation procedures to compute pre⁎(C) and post⁎(C) for finite TrPDSs. From these two saturation procedures, we present two algorithms to compute pre⁎(C) and post⁎(C) that are suitable for implementation. We also show that the algorithms for computing pre⁎(C) and post⁎(C) also work for weak finite TrPDSs, where closure is defined with respect to the underlying PDSs. These results are extended to left contextual TrPDSs, which is an extension of finite TrPDSs. Finally, we show how the presence of transductions enables the modeling of Boolean programs with call-by-reference parameter passing and low-level assembly programs that manipulate the program stack content via a stack pointer.

Using Binary Code Instrumentation in Computer Security

The paper approaches the low-level details of the code generated by compilers whose format permits outside actions. Binary code modifications are manually done when the internal format is known and understood, or automatically by certain tools developed to process the binary code. The binary code instrumentation goals may be various from security increasing and bug fixing to development of malicious software. The paper highlights the binary code instrumentation techniques by code injection to increase the security and reliability of a software application. Also, the paper offers examples for binary code formats understanding and how the binary code injection may be applied.Keywords: Binary Code, Code Instrumentation,Code Injection1 Binary Code FormatsThe binary code is the output of the compiling process. It uses two binary digits, 0 and 1, to represent symbols or computer processor instructions as bit strings.The binary code is directly executed by the computer processor or is interpreted by a specialized software component which translates the binary code into the format understood by the computer processor. Therefore, the binary code is classified into two groups:· Native code - is generated by the compiler depending on the hardware features; the binary files containing native code are executed only by computer processor units (CPU) having the same features like the computer processor used to generate it; some significant advantages are execution speed and absence of other software components;· Intermediate code - is generated by the compiler according to intermediate language specifications to be interpreted by a virtual machine; some examples of virtual machines are Java Virtual Machine (JVM) for Java platform and Common Language Runtime (CLR) for .NET framework; a big advantage is the binary code portability for different hardware and software platforms.Some considerations related to binary code and file formats are presented in [1], [2], [4], [5], [6], [8] and [9].The memory layout of native code file for a C program is depicted in figure 1 [11].The user space is structured into the following segments:· Code segment - contains executable instructions in binary format; it is a read- only segment and is shared among concurrent users;· Data segment - contains static and global data initialized in the program code; each process has its own data segment; the data segment is not a executable one;· Block Started by Symbol (BSS) segment - contains static and global data uninitialized in the program code; it is not an executable segment;· Stack segment - is used to store local variables (declared inside the functions) and to pass parameters to functions; the stack addresses are allocated from higher memory to lower memory; it is managed by Stack Pointer (SP)/Extended Stack Pointer (ESP)/ Register Stack Pointer (RSP) register;· Heap segment - is used to allocate memory at running time; heap allocation is managed by operating system; the heap addresses are managed by pointer variables.Segment registers are memory pointers placed inside the computer processor unit. They point to memory address where a data storage or code execution starts. The segment registers for x86 architecture are presented in Table 1.It considers the folowing C++ program source:The native code built by MicrosoftVisual Studio 2010, x64 version, for each method is presented in Table 2.The main function has the following native code content:Tables 2 and 3 contain numerical values for memory addresses and binary code in base- 16 format. The assembly instructions and their binary codes are generated for x86 computer architecture.The intermediate code provides the portability feature to a software application. A virtual machine interprets the operation codes from intermediate code and translates them into native code for the machine which runs the virtual machine. …

Fast interprocedural linear two-variable equalities

In this article we provide an interprocedural analysis of linear two-variable equalities. The novel algorithm has a worst-case complexity of 𝒪( n ⋅ k 4 ), where k is the number of variables and n is the program size. Thus, it saves a factor of k 4 in comparison to a related algorithm based on full linear algebra. We also indicate how the practical runtime can be further reduced significantly. The analysis can be applied, for example, for register coalescing, for identifying local variables and thus for interprocedurally observing stack pointer modifications as well as for an analysis of array index expressions, when analyzing low-level code.

Detection techniques of format-string vulnerabilities in binary files

Current detection techniques are mostly limited to the source code level, and research on the binary files is few. Based on the stack pointer and the argument pointer of the format-string, the attacking principles of format-string vulnerabilities were researched. A new method to detect format-string vulnerabilities in binary files was brought forward. By analyzing the method that the model adopted, the particular means and processes to construct the attacking codes were presented. In order to improve the effectiveness of the detection, the attacking code constructions for different systems were studied. At last, an example was given to demonstrate the validity of the detection model.

An anomaly in an interpreter using GCC source-code-level register allocation

An anomaly of unexpected performance in an interpreter whose frequently accessed variables are manually assigned to hard registers by GCC source-code-level register allocation is presented. A hard-registered virtual program counter and stack pointer as well as a byte-code translation are experimented on both register-rich PowerPC and register-limited Intel x86. According to the study of the anomaly, a hard register should not be assigned singly to a variable in an interpreter due to higher register pressure.

Software Watermarking Resilient to Debugging Attacks

In 2006, Gaurav Gupta and Josef Pieprzyk presented an attack on the branch-based software watermarking scheme proposed by Ginger Myles and Hongxia Jin in 2005. The software watermarking model is based on replacing jump instructions or unconditional branch statements (UBS) by calls to a fingerprint branch function (FBF) that computes the correct target address of the UBS as a function of the generated fingerprint and integrity check. If the program is tampered with, the fingerprint and/or integrity checks change and the target address is not computed correctly. Gupta and Pieprzyk's attack uses debugger capabilities such as register and address lookup and breakpoints to minimize the requirement to manually inspect the software. Using these resources, the FBF and calls to the same is identified, correct displacement values are generated and calls to FBF are replaced by the original UBS transferring control of the attack to the correct target instruction. In this paper, we propose a watermarking model that provides security against such debugging attacks. Two primary measures taken are shifting the stack pointer modification operation from the FBF to the individual UBSs, and coding the stack pointer modification in the same language as that of the rest of the code rather than assembly language to avoid conspicuous contents. The manual component complexity increases from O (1) in the previous scheme to O (n) in our proposed scheme.

The case for virtual register machines

Virtual machines (VMs) are a popular target for language implementers. A long-running question in the design of virtual machines has been whether stack or register architectures can be implemented more efficiently with an interpreter. Many designers favour stack architectures since the location of operands is implicit in the stack pointer. In contrast, the operands of register machine instructions must be specified explicitly. In this paper, we present a working system for translating stack-based Java virtual machine (JVM) code to a simple register code. We describe the translation process, the complicated parts of the JVM which make translation more difficult, and the optimisations needed to eliminate copy instructions. Experimental results show that a register format reduced the number of executed instructions by 34.88%, while increasing the number of bytecode loads by an average of 44.81%. Overall, this corresponds to an increase of 2.32 loads for each dispatch removed. We believe that the high cost of dispatches makes register machines attractive even at the cost of increased loads.

Early load address resolution via register tracking

Higher microprocessor frequencies accentuate the performance cost of memory accesses. This is especially noticeable in the Intel's IA32 architecture where lack of registers results in increased number of memory accesses. This paper presents novel, non-speculative technique that partially hides the increasing load-to-use latency, by allowing the early issue of load instructions. Early load address resolution relies on register tracking to safely compute the addresses of memory references in the front-end part of the processor pipeline. Register tracking enables decode-time computation of register values by tracking simple operations of the form reg±immediate. Register tracking may be performed in any pipeline stage following instruction decode and prior to execution. Several tracking schemes are proposed in this paper: Stack pointer tracking allows safe early resolution of stack references by keeping track of the value of the ESP register (the stack pointer). About 25% of all loads are stack loads and 95% of these loads may be resolved in the front-end. Absolute address tracking allows the early resolution of constant-address loads. Displacement-based tracking tackles all loads with addresses of the form reg±immediate by tracking the values of all general-purpose registers. This class corresponds to 82% of all loads, and about 65% of these loads can be safely resolved in the front-end pipeline. The paper describes the tracking schemes, analyzes their performance potential in a deeply pipelined processor and discusses the integration of tracking with memory disambiguation.

CONS should not CONS its arguments, part II

Previous Schemes for implementing full tail-recursion when compiling into C have required some form of "trampoline" to pop the stack. We propose solving the tail-recursion problem in the same manner as Standard ML of New Jersey, by allocating all frames in the (garbage-collected) heap. The Scheme program is translated into continuation-passing style, so the target C functions never return. The C stack pointer then becomes the allocation pointer for a Cheney-style copying garbage collection scheme. Our Scheme can use C function calls, C arguments, C variable-arity functions, and separate compilation without requiring complex block-compilation of entire programs. Our C version of the "Boyer" benchmark is available at ftp://ftp.netcom.com/pub/hb/hbaker/cboyer13.c.

A commercial use of stacks

Publisher Summary This chapter presents a description of the philosophy used in translating and running TALK, a commercial language used on the English Electric-Leo KDF6. TALK is in essence similar to ALGOL but does includes certain essential data processing facilities. Its implementation, therefore, relies to a large extent on existing ALGOL translators, all of which use the storage device known as a stack. ALGOL's use of stacks is mainly concerned with the evaluation of arithmetic expressions where the type of operand is numeric. Commercial data processing requires the addition of a third type of operand—alpha. A stack is merely an area of storage with an associated administrative quantity called the stack pointer, which controls the addressing of the stack. There is no necessity to limit the system to one stack; in fact, the TALK object program uses two stacks: (1) the Work stack and (2) the Call stack.