Type safety of the Dalvik VM?

[Patrick Walton]

Hi,

After perusing the Dalvik VM source code it does not seem to me that the
Dalvik VM is type safe. Consider, as an example, HANDLE_OP_APUT in
dalvik/vm/mterp/c/opcommon.c: there is no protection against vsrc1
containing an arbitrary pointer to any word in the Dalvik VM address
space, and there is also no type checking to ensure the array is
actually of the type corresponding to the instruction, which allows
Dalvik programs to alter the contents of any word in memory (by
creating, say, a byte array, then accessing it as an int array,
circumventing the bounds check). This could be used to execute a heap
spray attack.

I would report this as a bug, but since this is so pervasive within the
Dalvik VM I'm wondering whether it is a design goal of Dalvik to be type
safe. Since I'm interested in possibly writing an LLVM backend for
Dalvik (allowing C code to be compiled to Dalvik), this is something I'd
like to know. Certainly, the lack of type safety makes it easy to write
a C-to-Dalvik compiler, but I want to make sure that my methods won't
depend on exploiting bugs that are going to be fixed.

Patrick

[Andrew Stadler (Google)]

You should probably make yourself very familiar with the bytecode verifier, which runs over all bytecode before it gets to the actual Dalvik VM, and provides some of the safety checks I think you are expecting.

[Dan Bornstein]

On Fri, Jan 9, 2009 at 10:11 PM, Andrew Stadler (Google)
<sta...@android.com> wrote:
> You should probably make yourself very familiar with the bytecode verifier,
> which runs over all bytecode before it gets to the actual Dalvik VM, and
> provides some of the safety checks I think you are expecting.

What he said.

If you spot an actual case where type safety is violated, please
report it as a bug, including explicit steps to reproduce (compilable
source code, etc.) that we can use to confirm both the problem and the
fix.

Thanks!

-dan

[fadden]

On Jan 9, 10:04 pm, Patrick Walton <pcwal...@cs.ucla.edu> wrote:
> After perusing the Dalvik VM source code it does not seem to me that the
> Dalvik VM is type safe.

The only situation I'm aware of where you can do something that the VM
spec says you shouldn't is iput-object, which allows you to put an
object with a wrong type into a field; see the comment in dalvik/vm/
mterp/c/OP_IPUT_OBJECT.c and test 069 in dalvik/tests. (Use the
latest "cupcake" branch, not sure when exactly this went in.) The
test jumps through a couple of hoops to sneak past the checking in the
compiler and verifier. It turns out other popular desktop VMs have
the same behavior, i.e. the field store is allowed but the problem is
discovered when the field is actually used.

cd dalvik/tests
./run-test --reference 069

> I would report this as a bug, but since this is so pervasive within the
> Dalvik VM I'm wondering whether it is a design goal of Dalvik to be type
> safe.

It is a goal, and in some cases Dalvik is safe to a greater extent
than other VMs (e.g. it's more picky about the width of sub-32-bit
integers). Some details are available in dalvik/docs/verifier.html.

Identifying type-safety issues during verification allows us to avoid
making those checks at runtime, improving performance. Because DEX
files are read-only to everything but a couple of system processes, we
can (usually) do the verification at app install time and not have to
repeat it at app startup time.