Re: safety of GCJ-generated code

[Andrew Haley <aph at cambridge dot redhat dot com>]

Adam Megacz writes:
 > 
 > Tom Tromey <tromey@redhat.com> writes:
 > > In practice, I think gcj-generated code is safe (barring unknown
 > > bugs).  However, nobody has done an audit of libgcj.
 > 
 > Of course -- that's all I'm looking for, though -- assurance that if
 > you assume there are no bugs in libgcj, then it is known that
 > gcj-compiled code is "safe".
 > 
 > > Note that libgcj doesn't yet fully conform to Java's security model.
 > > We don't really support having a SecurityManager.  Also, we never
 > > throw StackOverflowError -- instead you might see a crash.  These two
 > > things have been on the to-do list for years.  Unfortunately,
 > > implementing them isn't trivial.
 > 
 > Interestingly, in my mucking around with the win32 stuff, I though I
 > saw something about a special "Stack Overflow Signal" on
 > win32... perhaps it might be as simple as just catching that signal
 > and then "throw new StackOverflowException()"...

Erm, but you'd have no stack to call new().  :-)

However, given that simply receiving a signal requires stack space to
be allocated in order to save the user context, I assume that a kernel
must unprotect the guard area at the end of a thread's stack before
sending the signal?  Hmm, I need to have a chat with a kernel
engineer.

Another thing to bear in mind is that if the guard area is only one
page in size, a malicious adverary can subvert the protection and walk
into another thread's stack by allocating a frame that is known to be
bigger than the guard page.  AFAIK the only way to prevent this is to
insert code to check the stack extent into a each method's prologue.
Alternatively, I guess you could limit the number of local variables
in a stack frame.

Andrew.