[M3devel] SEGV mapping to RuntimeError

Tue Feb 22 05:40:34 CET 2011

Hi all:
sorry missed the second link in the comments about HP--UX and Nil dereferences:
http://www.usenix.org/publications/library/proceedings/sd96/full_papers/small.txt

Still they seemed to be some option in the compiler to check where platform needed to catch the RuntimeError either from compiler inserted checks for NIL and from trapped OS call or just ignore it in some circunstances like HP-UX case, see for that it.
Thanks in advance 

--- El lun, 21/2/11, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribió:

> De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
> Asunto: Re: [M3devel] SEGV mapping to RuntimeError
> Para: "Mika Nystrom" <mika at async.caltech.edu>
> CC: m3devel at elegosoft.com
> Fecha: lunes, 21 de febrero, 2011 23:31
> Hi all:
> yes I see, things are harder than I thought here but still
> seems the problem is not directly in the runtime environment
> system, perhaps this is more just another time of System
> native restrictions:
> according to this guys:
> http://grsecurity.net/confighelp.php/
> (see for Automatically emulate sigreturn trampolines) 
> that's why perhaps the SPIN could do that without requiring
> the process to terminate which is otherwise is very odd I
> believe for such restrictions, still need to check more
> details:
> Interesting this emails go into the details of more
> advanced programs to analyze ine ach platform the runtime
> behavior many years ago, look for Hp-UX implementation
> "bug".
> Again grsecurity OS doers talk again even of (see CVSup):
> http://pax.grsecurity.net/docs/randexec.txt
> I hope it helps a bit, thanks in advance 
> 
> --- El lun, 21/2/11, Mika Nystrom <mika at async.caltech.edu>
> escribió:
> 
> > De: Mika Nystrom <mika at async.caltech.edu>
> > Asunto: Re: [M3devel] SEGV mapping to RuntimeError
> > Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> > CC: m3devel at elegosoft.com
> > Fecha: lunes, 21 de febrero, 2011 21:12
> > 
> > There are several issues here and yes this the
> > RuntimeError.E exception
> > is taken either from SPIN or the CM3 JVM, I don't
> know
> > which.
> > 
> > I only understand the user threads code so I have made
> that
> > raise the
> > RuntimeError.E instead of dumping core on a segfault.
> 
> > I think this is what
> > the CM JVM was supposed to do as well---but honestly
> I
> > can't tell if that
> > work was ever completed.  They do support
> mapping
> > various other runtime
> > errors (subrange mismatch, e.g.) into exceptions, and
> that
> > works well.
> > However the segmentation fault mapping was not
> functional:
> > there was no
> > other way of handling it than dumping core on the
> whole M3
> > environment
> > and runtime before my changes last week.
> > 
> > My last email was about a bug in my changes---not in
> the
> > actual functionality
> > but the fact that if you *don't* catch the
> RuntimeError.E
> > exception that
> > results from a bad memory reference, the runtime quits
> with
> > a slightly
> > confusing error message, apparently implicating the
> > threading system when
> > the bug is actually in normal, non-UNSAFE code.
> > 
> >      Mika
> > 
> > "Daniel Alejandro Benavides D." writes:
> > >Hi all:
> > >although this is not of my full understanding, CM3
> JVM
> > was supposed to hand=
> > >le in such a way the exceptions of jvm =B5-op
> fault
> > script programs, given =
> > >that: there was a runtime above the CM3 runtime
> and
> > besides having its own =
> > >spaces for stack, thread stacks and runtime
> machinery,
> > loader, etc.
> > >Please just to advert this is and I guess was the
> case
> > for CM3 JVM, if so, =
> > >let the system handle it in that way, why do you
> need
> > to fully manage to ha=
> > >ndle that as in Modula-3 runtime per se, my
> believe is
> > that you could do th=
> > >at for the language environment routines
> separately,
> > that's why pragmas are=
> > > really useful. I don't believe it allowed to
> signal
> > like in Modula-3 terms=
> > > threads but you could for instance lock a thread
> until
> > you have time in th=
> > >e scheduler from Modula-3, still this is more
> flexible
> > nowadays I believe w=
> > >ith multiprocessors, etc.
> > >Similarly SPIN used or performed protection
> mechanism,
> > like domain level, a=
> > >nd at language level the heap freezes when
> handling
> > untrusted code (even ex=
> > >tra checked array bounds violation faults in
> > non-Modula-3 code), so you hav=
> > >e same runtime I believe for doing that too in
> > Modula-3, again, is just ano=
> > >ther time of problem arises, perhaps this can be
> tried
> > for thread stacks, e=
> > >tc and in kernel threads well as something alike,
> I
> > really think could be d=
> > >one.
> > >Thanks in advance
> > >
> > >--- El lun, 21/2/11, Mika Nystrom <mika at async.caltech.edu>
> > escribi=F3:
> > >
> > >> De: Mika Nystrom <mika at async.caltech.edu>
> > >> Asunto: Re: [M3devel] SEGV mapping to
> > RuntimeError
> > >> Para: "Jay K" <jay.krell at cornell.edu>,
> > m3devel at elegosoft.com
> > >> Fecha: lunes, 21 de febrero, 2011 19:01
> > >>=20
> > >> There is in fact a small problem with my
> change to
> > the way
> > >> SIGSEGV is
> > >> handled.  It now appears that bad
> memory
> > references
> > >> are all happening
> > >> in ThreadPosix.m3 (i.e., we've lost some of
> the
> > debugging
> > >> help of the
> > >> error message).
> > >>=20
> > >> I'm not quite sure how to fix this although
> I'm
> > sure all
> > >> the bits are
> > >> around.  My guess is that instead of
> > performing RAISE
> > >> RuntimeError.E
> > >> in the thread switcher, the code ought to
> call
> > >> RTHooks.Raise with an
> > >> argument derived from the faulting address
> as
> > reported to
> > >> the signal
> > >> handler.  This is probably quite easy,
> but
> > does anyone
> > >> know the=20
> > >> right routines to call?  One would need
> to
> > track down
> > >> the routine that
> > >> faulted as well as the RT0 record
> corresponding to
> > the
> > >> exception
> > >> RuntimeError.E.
> > >>=20
> > >>      Mika
> > >>=20
> > >> Jay K writes:
> > >> >Letting any code run after a SIGSEGV is
> > dubious.
> > >> >Imagine the heap is corrupted.
> > >> >And then you run more code.
> > >> >And the code happens to call malloc.
> > >> >Or printf to log something.
> > >> >=3D20
> > >> >I suppose there might be an application
> that
> > maps
> > >> memory
> > >> >gradually=3D2C as pieces of a buffer are
> hit.
> > Might.
> > >> =0A=0A=0A      
> > 
> 
> 
> 
> 