Safe Java Native Interface S J v N v c Gang Tan*, Andrew W. Appel - - PowerPoint PPT Presentation

safe java native interface s j v n v c
SMART_READER_LITE
LIVE PREVIEW

Safe Java Native Interface S J v N v c Gang Tan*, Andrew W. Appel - - PowerPoint PPT Presentation

Safe Java Native Interface S J v N v c Gang Tan*, Andrew W. Appel # , Srimat Chakradhar , Anand Raghunathan , Srivaths Ravi , and Daniel Wang # *Boston College # Princeton University NEC Labs America Heterogeneous Programming


slide-1
SLIDE 1

Safe Java Native Interface S J v N v c

Gang Tan*, Andrew W. Appel#, Srimat Chakradhar◊, Anand Raghunathan◊, Srivaths Ravi◊, and Daniel Wang# *Boston College

#Princeton University ◊NEC Labs America

slide-2
SLIDE 2

d Heterogeneous Programming Paradigm

… C code C# code Java code Application

Reuse legacy code Mix-and-match benefits of different languages

E.g., C is faster and more flexible than Java E.g., Java based GUIs are easier to develop

2

slide-3
SLIDE 3

F i F i I f (FFI ) Foreign Function Interfaces (FFIs)

Most modern languages have FFIs

Java, ML, OCaml, Haskell, …

FFIs address issues such as

Representation of data

p

Calling conventions Memory management

y g

3

slide-4
SLIDE 4

What about Safety and Security?

Same address space C code Java code Same address space Application Weakly typed Strongly typed Memory unsafe Memory safe Memory unsafe Memory safe The whole application becomes memory unsafe!

4

pp y

slide-5
SLIDE 5

A h f S f Approaches for Safe Interoperation:

Component models: COM, DCOM, SOAP,

CORBA

Different address spaces Communication via RPCs But, high performance overhead and inflexible

Rewrite every component in a safe

y p language

Substantial programming effort

p g g

Hard/impossible sometimes

5

We focus on FFI-based approaches.

slide-6
SLIDE 6

Our Focus: Java Native Interface (JNI)

C code Java code J N I J ll C i l d h d

Java can call C-implemented methods C code can

Access update and create Java objects Access, update and create Java objects Call a Java method Catch and raise exceptions

6

slide-7
SLIDE 7

l Our Goal

Make calling native C code in Java as safe

as calling Java code in Java

Benefits:

Reuse legacy C code in Java safely and

g y y conveniently

Improve the security of Java platform

JDK 1.4.2 contains over 600,000 lines of C code

under the cover of JNI

More lightweight and flexible comparing to

More lightweight and flexible comparing to

RPC-based approaches

7

slide-8
SLIDE 8

T S b bl Two Subproblems

Provide internal safety for C Code.

CCured [Necula, Condit, et al.]

Ensure memory-safety by source-to-source

transformation

Insert runtime checks Insert runtime checks Heavily optimized

Cyclone [Jim, Morrisett, et al.]

Cyclone [Jim, Morrisett, et al.]

Safe interoperation between C and Java

Ensure that C uses JNI in a principled way Ensure that C uses JNI in a principled way

8

slide-9
SLIDE 9

l Outline

Motivation JNI and its loopholes

p

SafeJNI system Preliminary experiments Preliminary experiments Future work

9

slide-10
SLIDE 10

An E ample Of Using JNI An Example Of Using JNI

class IntArray { … native int sumArray(int arr[]); … }

Java code C code

10

slide-11
SLIDE 11

d Using JNI in C Code

Pass in a pointer to the int array Get a pointer into C code Pass in a pointer to the int array Get a pointer into the Java heap Pointer arith.

Well behaved C code manipulates Java

Get the length of the array

11

Well-behaved C code manipulates Java

  • bjects through JNI APIs
slide-12
SLIDE 12

Loophole: Out-of-Bounds Accesses

Out-of-bound write;

12

; destroys JVM’s state

slide-13
SLIDE 13

Loophole: Arguments of Wrong Classes

JNI completely ignores the Java class

hierarchy

All Java classes are mapped to jobject * in C

C can pass objects of

13

wrong classes to Java

slide-14
SLIDE 14

Loophole: Calling Wrong Methods

Nothing prevents C from calling GetFloatArrayElements

14

GetFloatArrayElements

slide-15
SLIDE 15

Loophole: Manual Memory Management

Dangling pointers; memory leak; release twice

15

g g p ; y ;

slide-16
SLIDE 16

Safety/Security Vulnerabilities in JNI

Bypassing JNI: direct read/write through Java

pointers

Out-of-bounds array access Passing objects of wrong classes to Java No access control Manual memory management Calling wrong methods Exception handling Out of the Java sandbox security model

At best: causes a JVM crash

16

At best: causes a JVM crash At worst: security violation

slide-17
SLIDE 17

l Outline

Motivation JNI and its loopholes

p

SafeJNI system Preliminary experiments Preliminary experiments Future work

17

slide-18
SLIDE 18

Safe Java Native Interface (SafeJNI) Safe Java Native Interface (SafeJNI)

Goal: Goal:

Make calling native C code in Java as safe as

calling Java code in Java calling Java code in Java C code Java code JNI

  • A pointer kind system
  • Safe mem. management

V i d i h k

18

  • Various dynamic checks
slide-19
SLIDE 19

b l f Restricting Capabilities of Pointers

Opaqueness of Java object pointers

Can pass them as arguments to JNI APIs No pointer arith./cast/read/write

Java primitive array pointers

p y p

Allow pointer arith., but must be within bounds Carry bounds information at runtime

y

19

slide-20
SLIDE 20

A d S A Pointer Kind System

Classify pointers with different capabilities Classify pointers with different capabilities An extension of CCured’s pointer kinds

Pointer Kind Description Capabilities

t * HNDL Java handle Pass to JNI APIs; t * HNDL Java handle Pointers Pass to JNI APIs; equality testing t * RO Read-only read Model JNI interface pointers pointers t *SAFE Safe pointer read/write t *SEQ Sequence Above + pointer M d l J t *SEQ Sequence pointers Above + pointer arithmetic t *WILD Wild pointers Above + casts Model Java primitive array pointe s

20

pointers

slide-21
SLIDE 21

Memory Management in JNI

Java Heap C Heap GC Java Heap

  • bjects

C Heap Java

After step 4

pointer 2 pointer 1

After step 4, “Pointer 1” is dangling if GC

pointer 2

dangling if GC recycles the buffer

  • 1. C calls GetIntArrayElements and gets “pointer 1”
  • 2. In GetIntArrayElements, JVM pins the buffer so that

y , p GC will not move it

  • 3. When it’s done, C calls ReleaseIntArrayElements

21

  • 4. JVM unpins the buffer
slide-22
SLIDE 22

S l f Our Solution for Mem. Management

Java Heap C Heap

validity tag

GC 0/1 Java Heap

  • bjects

C Heap Java 0/1 pointer 1 pointer 2 pointer 2

Create a validity tag Change the representation of a pointer to a struct

g p p

In GetIntArrayElements, init the tag to 1 In ReleaseIntArrayElements, change the tag to 0

22

In ReleaseIntArrayElements, change the tag to 0 Before dereferencing, check that the tag is 1

slide-23
SLIDE 23

Various Dynamic Checks

Runtime type checking

E.g., when GetIntArrayElements is called, check

g , y , the second arg. is an int-array object

When a Java method is called, check the

number and classes of arguments

Access control

Check during “get field ID”

Exception checking Exception checking Non-null checking

23

Java maintains all information at runtime

slide-24
SLIDE 24

S f S T f d SafeJNI System: On Top of CCured

C code Annotated jni.h

Insert Checks

J d Kind Inference Engine

Checks Safe

Java code

J

Inference Engine Annotated C code

Safe C code Java Compiler

Annotated C code

Type gcc

Lib Bytecode

link Type Checker

Library code

link

24

NO Yes

slide-25
SLIDE 25

l Outline

Motivation JNI and its loopholes

p

SafeJNI system Preliminary experiments Preliminary experiments Future work

25

slide-26
SLIDE 26

Microbenchmarks

2.19 2.09 2 2.5 1.49 1 29 1.5 2 1.29 1.14 1 SafeJNI/JNI Ratio 0.5

26

slide-27
SLIDE 27

Zlib Experiment

Zlib compression library

9,000 lines of C code + 262 lines of glue

9,000 lines of C code 262 lines of glue code

The basis for java util zip The basis for java.util.zip

SafeJni Ratio CCured Ratio JZlib* Ratio Zlib 1 6 3 1 46 1 74 Zlib 1 .6 3 1.46 1.74

* JZlib is a 100% pure Java reimplemention of Zlib

27

* JZlib is a 100% pure Java reimplemention of Zlib

slide-28
SLIDE 28

A Safety Loophole in java.util.zip

Zlib maintains a z_stream struct

For keeping state info

The Deflater object needs to store a

pointer to this C struct p

However, it’s difficult to define a pointer to a C

struct in Java! class Deflater { private long strm; p g ; … }

28

Then C casts it back to a pointer

slide-29
SLIDE 29

A Safety Loophole in java.util.zip

With reflection support, we can change

the private long.

import java.lang.reflect.*; import java.util.zip.Deflater; public class Bug { public static void main(String args[]) { Deflater deflate = new Deflater(); Deflater deflate new Deflater(); byte[] buf = new byte[0]; Class deflate_class = deflate.getClass(); try { Field strm = deflate_class.getDeclaredField("strm"); strm setAccessible(true);

Crashed Sun’s JVM and IBM’s VM

strm.setAccessible(true); strm.setLong(deflate,1L); } catch (Throwable e) { e.printStackTrace(); } deflate.deflate(buf); } } /* Policy file needed in a secure environment */ grant {

29

grant { permission java.lang.RuntimePermission "accessDeclaredMembers"; permission java.lang.reflect.ReflectPermission "suppressAccessChecks"; };

slide-30
SLIDE 30

Related Work

OCaml’s FFI [Furr and Foster]

Track OCaml types in C to prevent misuse

yp p

NestedVM [Alliet and Megacz]

Put native code into a separate VM Put native code into a separate VM Slowdown ratio: 200% to 900%

Janet [Bubak et al ] Janet [Bubak et al.]

A cleaner interface

“ X h k j i”

“-Xcheck:jni”

Incomplete and undocumented

30

slide-31
SLIDE 31

Future Work

Reduce the amount of dynamic checks

Keep track of Java types in C code

p yp

Use static analysis/theorem proving

.Net: interaction between managed and .Net: interaction between managed and

unmanaged code

31

slide-32
SLIDE 32

SafeJNI: Conclusions

Reuse legacy C code safely and

conveniently

More lightweight and flexible comparing

to RPC-based approaches to RPC based approaches

32

slide-33
SLIDE 33

The End