[M3devel] SEGV mapping to RuntimeError

[Daniel Alejandro Benavides D.]

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      
>