lkml.org 
[lkml]   [1997]   [Jan]   [17]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
FromKeith Rohrer <>
SubjectRe: Linux for JavaVM
DateFri, 17 Jan 1997 14:53:26 -0600 (CST)
> > Yes: you are wrong. The bytecode does NOT support such C features as
> > "dereference an arbitrary pointer". 
I don't know about the bytecode, but I do know that Java is paranoid about
pointers to the extent that, short of a few classes in java.lang.io (or
somewhere like that) grab a contiguous block of memory; afaik, the
code "byte foo[50];" declares foo to be 50 _references_ to ints...
Plus, absolutely everything is signed.

> > The Java VM is supposed to afford a
> > safe, "boxed", environment for arbitrary Java code snippets. You can't do
> > that if you would ever allow the bytecode equivalent of perfectly-legal C
> > code such as "*(char *)0x123456 = 0x78" to run.
> Sure you can.  You just have to either make sure 0x123456 is a memory
> location the applet is allowed to access, or fault.  This is a
> function of the byte code interpreter.  
And the last thing I expect to see in Java is an option for "inline
bytecode"...

> The Linux kernel allows C
> programs to do *(char *)0x123456 = 0x78; for example, but that doesn't
> give them access to arbitrary memory locations.  This is a feature of
> the CPUs used.  When you write a byte code interpreter (or compiler)
> you are doing a "virtual CPU", in effect, so you can define it to have
> whatever security features you choose.
However, needing a special java vm which is lax enough to run linuj is
likely to defeat whatever point there was to using java in the first place.

> Note that that doesn't mean the Java spec supports this kinds of
> operations (AFAIK it doesn't) but it doesn't mean it isn't possible.
Sorry I didn't get in on this thread early enough to know just what
reason someone had for suggesting "linuj", but I can't think of any of
the usual reasons besides "portability"...

	Keith



\
 
 \ /
  Last update: 2005-03-22 12:38    [from the cache]
©2003-2008