Finding bugs in java native interface programs

Kondoh, Goh; Onodera, Tamiya

doi:10.1145/1390630.1390645

Cited by 46 publications

(57 citation statements)

References 7 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Recent years have witnessed a string of systems that analyze and improve FFIs for safety and reliability [1,2,3,4,5,6,7,8]. However, lack of formal semantics of FFIs hampers progress in this domain.…”

Section: Motivationmentioning

confidence: 99%

JNI light: an operational model for the core JNI

Tan¹

2014

Math. Struct. Comp. Sci.

View full text Add to dashboard Cite

Abstract. Through foreign function interfaces (FFIs), software components in different programming languages interact with each other in the same address space. Recent years have witnessed a number of systems that analyze FFIs for safety and reliability. However, lack of formal specifications of FFIs hampers progress in this endeavor. We present a formal operational model, JNI Light (JNIL), for a subset of a widely used FFI-the Java Native Interface (JNI). JNIL focuses on the core issues when a high-level garbage-collected language interacts with a low-level language. It proposes abstractions for handling a shared heap, crosslanguage method calls, cross-language exception handling, and garbage collection. JNIL can directly serve as a formal basis for JNI tools and systems. The abstractions in JNIL are also useful when modeling other FFIs, such as the Python/C interface and the OCaml/C interface. MotivationMost modern programming languages support foreign function interfaces (FFIs) for interoperating with program modules developed in other programming languages. Recent years have witnessed a string of systems that analyze and improve FFIs for safety and reliability [1,2,3,4,5,6,7,8]. However, lack of formal semantics of FFIs hampers progress in this domain. The available specifications of FFIs are in prose. Relying on prose specifications has at least two unpleasant consequences. First, prose specifications are often ambiguous and sometimes incomplete. The situation is especially acute for an FFI, whose two sides involve different programming models and language features. For instance, Lee et al. reported that Sun's HotSpot and IBM's J9 behave differently for four out of ten JNI test cases [8, Table 1]. In such situations, the best an FFI user can do is to perform experiments on particular implementations and make an educated guess. This may cause inconsistencies and unsoundness. Second, without formal semantics, tools and analyzers cannot provide rigorous claims about their strength. As a result, previous systems that target FFIs have to argue their hypotheses and claims informally. This leaves their strength in doubt.While there have been many efforts in formalizing the semantics of programming languages, almost all have ignored the FFI aspect. The work by Matthews and Findler [9] formalizes the interoperation between two high-level functional languages, one typed and the other untyped. While this formalism represents significant progress in modeling language interoperation, it does not apply to FFIs. Most FFIs are about the interaction in the shared memory between a high-level language and a low-level language (assembly languages, C, and C++).This paper presents the first formal operational model, named JNI Light (JNIL), for a subset of a shared-memory foreign function interface-the JNI interface. The major challenge for the modeling effort is to have the right abstractions to accommodate differences between the programming models of Java and native code, without unduly complicating the model. This is challe...

show abstract

Section: Motivationmentioning

confidence: 99%

JNI light: an operational model for the core JNI

Tan¹

2014

Math. Struct. Comp. Sci.

View full text Add to dashboard Cite

show abstract

“…FFI-based software is often error-prone; recent studies found a large number of software bugs in the interface code between modules of different languages based on static analysis [7,8,32,14,18,19] and dynamic analysis [31,16], and new interface languages for writing safer multilingual code (e.g., [12]). JATO performs interlanguage analysis and lock insertion to ensure atomicity of native methods in JNI code.…”

Section: Related Workmentioning

confidence: 99%

JATO: Native Code Atomicity for Java

Liu

Tan

2012

Programming Languages and Systems

View full text Add to dashboard Cite

Abstract. Atomicity enforcement in a multi-threaded application can be critical to the application's safety. In this paper, we take the challenge of enforcing atomicity in a multilingual application, which is developed in multiple programming languages. Specifically, we describe the design and implementation of JATO, which enforces the atomicity of a native method when a Java application invokes the native method through the Java Native Interface (JNI). JATO relies on a constraint-based system, which generates constraints from both Java and native code based on how Java objects are accessed by threads. Constraints are then solved to infer a set of Java objects that need to be locked in native methods to enforce the atomicity of the native method invocation. We also propose a number of optimizations that soundly improve the performance. Evaluation through JATO's prototype implementation demonstrates it enforces native-method atomicity with reasonable run-time overhead.

show abstract

“…Native methods are notoriously unsafe and is a rich source of software errors. Recent studies have reported hundreds of interface bugs in JNI programs [6,31,14]. A number of systems are designed to improve and find misuses of the JNI interface.…”

Section: Related Workmentioning

confidence: 99%

“…They can be classified into three categories: (1) Jeannie [10] is a new interface language that allows programmers to mix Java with C code and a Jeannie program is then compiled into JNI code by the Jeannie compiler. (2) Several recent systems employ static analysis to identify specific classes of errors in JNI code [6,32,14,16]. (3) Jinn [15] generates dynamic checks at the language boundary to find interface errors.…”

Section: Related Workmentioning

confidence: 99%

Robusta

Siefers

Tan

Morrisett

2010

Proceedings of the 17th ACM Conference on Computer and Communications Security

View full text Add to dashboard Cite

Java applications often need to incorporate native-code components for efficiency and for reusing legacy code. However, it is well known that the use of native code defeats Java's security model. We describe the design and implementation of Robusta, a complete framework that provides safety and security to native code in Java applications. Starting from software-based fault isolation (SFI), Robusta isolates native code into a sandbox where dynamic linking/loading of libraries is supported and unsafe system modification and confidentiality violations are prevented. It also mediates native system calls according to a security policy by connecting to Java's security manager. Our prototype implementation of Robusta is based on Native Client and OpenJDK. Experiments in this prototype demonstrate Robusta is effective and efficient, with modest runtime overhead on a set of JNI benchmark programs. Robusta can be used to sandbox native libraries used in Java's system classes to prevent attackers from exploiting bugs in the libraries. It can also enable trustworthy execution of mobile Java programs with native libraries. The design of Robusta should also be applicable when other type-safe languages (e.g., C#, Python) want to ensure safe interoperation with native libraries.

show abstract

Finding bugs in java native interface programs

Cited by 46 publications

References 7 publications

JNI light: an operational model for the core JNI

JNI light: an operational model for the core JNI

JATO: Native Code Atomicity for Java

Robusta

Contact Info

Product

Resources

About