From: gback@facility.cs.utah.edu
Date: Wed, 24 Jan 1996 02:33:42 +0800
To: rsalz@osf.org (Rich Salz)
Subject: Re: Hack Java
In-Reply-To: <9601231630.AA07540@sulphur.osf.org>
Message-ID: <199601231756.KAA03101@sal.cs.utah.edu>
MIME-Version: 1.0
Content-Type: text


> 
> This illustrates the difference between a language with no dangerous
> constructs, and one where you must trust the implementation.
> >From some internal OSF email:
> ---------- Begin Forwarded Message ----------
> 
> class Data { // an object storing 16 bytes 
> 	byte word[16];
> }
> 
> 
> class Trick {
> 	Data data;
> 	long tricky_pointer;
> 	}
> 
> 
> Now suppose, I fake a compiler (or I have a malicious compiler)
> and I generate by hand malicious byte code such that
> in the symbol tables, tricky_pointer and data have the same
> offset.
> 

 What offset do you mean? The offset in the struct as in C++?
Java bytecode does not store such information. Fields are
accessed using putfield/getfield, which use an index to a
field reference in the constant pool. (pg. 66, lang spec)

Field references contain a name index (pg. 19) which points
to a name, i.e., a CONSTANT_Utf8 (pg. 18) field.

To my knowledge, the Java, and Java bytecode does not imply
any memory layout. I doubt it makes sense to demand to check
that 'offset do not overlap in memory'.

Could you describe in more detail the manipulation you are
proposing?

 - Godmar