Note: I worked out this method for my own language, Neat, but the basic
approach should be portable to D's exceptions as well.
I've seen it argued a lot over the years (even argued it myself) that it's
impossible to throw from Linux signal handlers. This is basically correct,
because they const
Le 13/03/2012 11:09, FeepingCreature a écrit :
Note: I worked out this method for my own language, Neat, but the basic
approach should be portable to D's exceptions as well.
I've seen it argued a lot over the years (even argued it myself) that it's
impossible to throw from Linux signal handler
On 03/13/12 11:23, deadalnix wrote:
> Le 13/03/2012 11:09, FeepingCreature a écrit :
>> Note: I worked out this method for my own language, Neat, but the basic
>> approach should be portable to D's exceptions as well.
>>
>> I've seen it argued a lot over the years (even argued it myself) that it's
On Tuesday, 13 March 2012 at 10:09:55 UTC, FeepingCreature wrote:
However, there is a method to turn a signal handler into a
regular function call that you can throw from.
Very nice!
The only similarity with a buffer overflow exploit is that we're
overriding the continuation address. There is
On Tue, Mar 13, 2012 at 11:09:54AM +0100, FeepingCreature wrote:
[...]
> I've seen it argued a lot over the years (even argued it myself) that
> it's impossible to throw from Linux signal handlers. This is basically
> correct, because they constitute an interruption in the stack that
> breaks excep
On 03/13/12 23:24, Vladimir Panteleev wrote:
> On Tuesday, 13 March 2012 at 10:09:55 UTC, FeepingCreature wrote:
>> However, there is a method to turn a signal handler into a regular function
>> call that you can throw from.
>
> Very nice!
>
> The only similarity with a buffer overflow exploit i
Le 13/03/2012 23:24, Vladimir Panteleev a écrit :
On Tuesday, 13 March 2012 at 10:09:55 UTC, FeepingCreature wrote:
However, there is a method to turn a signal handler into a regular
function call that you can throw from.
Very nice!
The only similarity with a buffer overflow exploit is that w
On 03/14/12 12:13, deadalnix wrote:
> Le 13/03/2012 23:24, Vladimir Panteleev a écrit :
>> I think something like this needs to end up in Druntime, at least for
>> Linux x86 and x64.
>
> You are loosing EAX in the process.
It's somewhat unavoidable. One way or another, you need to find _some_
thr
On Wednesday, 14 March 2012 at 11:11:54 UTC, deadalnix wrote:
You are loosing EAX in the process.
When would this matter? EAX is a scratch register per ABIs, no?
On Wednesday, 14 March 2012 at 07:35:50 UTC, FeepingCreature
wrote:
Sweet. Yeah, I think you need to use naked and reconstruct the
stackframe. Not sure how it'd look; I'm not familiar with the
x86_64 ABI.
I think it might be safe to just reconstruct the stack frame in
the signal handler, and
Le 14/03/2012 17:08, Vladimir Panteleev a écrit :
On Wednesday, 14 March 2012 at 11:11:54 UTC, deadalnix wrote:
You are loosing EAX in the process.
When would this matter? EAX is a scratch register per ABIs, no?
You may want to return from the function the standard way an resume
operations.
Le 14/03/2012 17:34, Vladimir Panteleev a écrit :
On Wednesday, 14 March 2012 at 07:35:50 UTC, FeepingCreature wrote:
Sweet. Yeah, I think you need to use naked and reconstruct the
stackframe. Not sure how it'd look; I'm not familiar with the x86_64 ABI.
I think it might be safe to just recons
Le 14/03/2012 14:43, FeepingCreature a écrit :
On 03/14/12 12:13, deadalnix wrote:
Le 13/03/2012 23:24, Vladimir Panteleev a écrit :
I think something like this needs to end up in Druntime, at least for
Linux x86 and x64.
You are loosing EAX in the process.
It's somewhat unavoidable. One way
On Wednesday, 14 March 2012 at 16:39:29 UTC, deadalnix wrote:
Le 14/03/2012 17:34, Vladimir Panteleev a écrit :
On Wednesday, 14 March 2012 at 07:35:50 UTC, FeepingCreature
wrote:
Sweet. Yeah, I think you need to use naked and reconstruct the
stackframe. Not sure how it'd look; I'm not familiar
On Wednesday, 14 March 2012 at 16:37:45 UTC, deadalnix wrote:
Le 14/03/2012 17:08, Vladimir Panteleev a écrit :
On Wednesday, 14 March 2012 at 11:11:54 UTC, deadalnix wrote:
You are loosing EAX in the process.
When would this matter? EAX is a scratch register per ABIs, no?
You may want to r
On Wed, Mar 14, 2012 at 05:39:38PM +0100, deadalnix wrote:
> Le 14/03/2012 17:08, Vladimir Panteleev a écrit :
> >On Wednesday, 14 March 2012 at 11:11:54 UTC, deadalnix wrote:
> >>You are loosing EAX in the process.
> >
> >When would this matter? EAX is a scratch register per ABIs, no?
>
> You may
Le 14/03/2012 18:00, Vladimir Panteleev a écrit :
On Wednesday, 14 March 2012 at 16:37:45 UTC, deadalnix wrote:
Le 14/03/2012 17:08, Vladimir Panteleev a écrit :
On Wednesday, 14 March 2012 at 11:11:54 UTC, deadalnix wrote:
You are loosing EAX in the process.
When would this matter? EAX is a
On Wednesday, 14 March 2012 at 17:18:06 UTC, deadalnix wrote:
Le 14/03/2012 18:00, Vladimir Panteleev a écrit :
On Wednesday, 14 March 2012 at 16:37:45 UTC, deadalnix wrote:
Le 14/03/2012 17:08, Vladimir Panteleev a écrit :
On Wednesday, 14 March 2012 at 11:11:54 UTC, deadalnix wrote:
You are
Le 14/03/2012 18:28, Vladimir Panteleev a écrit :
On Wednesday, 14 March 2012 at 17:18:06 UTC, deadalnix wrote:
Le 14/03/2012 18:00, Vladimir Panteleev a écrit :
On Wednesday, 14 March 2012 at 16:37:45 UTC, deadalnix wrote:
Le 14/03/2012 17:08, Vladimir Panteleev a écrit :
On Wednesday, 14 Ma
Le 14/03/2012 18:01, Vladimir Panteleev a écrit :
On Wednesday, 14 March 2012 at 16:39:29 UTC, deadalnix wrote:
Le 14/03/2012 17:34, Vladimir Panteleev a écrit :
On Wednesday, 14 March 2012 at 07:35:50 UTC, FeepingCreature wrote:
Sweet. Yeah, I think you need to use naked and reconstruct the
s
On Wednesday, 14 March 2012 at 19:48:28 UTC, deadalnix wrote:
Le 14/03/2012 18:28, Vladimir Panteleev a écrit :
On Wednesday, 14 March 2012 at 17:18:06 UTC, deadalnix wrote:
Le 14/03/2012 18:00, Vladimir Panteleev a écrit :
On Wednesday, 14 March 2012 at 16:37:45 UTC, deadalnix wrote:
Le 14/0
On 13/03/12 11:09, FeepingCreature wrote:
Note: I worked out this method for my own language, Neat, but the basic
approach should be portable to D's exceptions as well.
I've seen it argued a lot over the years (even argued it myself) that it's
impossible to throw from Linux signal handlers. Th
t turning SIGSEGV into an exception that 1) you can
catch 2) will print a stack trace when uncaught. You've brought in stack
overflows, moving garbage collectors, etc. I assure you, we are
well-aware of the problems when using this exact code for other purposes.
The topic is *Turning a SIGSEG
On Wednesday, 14 March 2012 at 20:20:05 UTC, deadalnix wrote:
The topic is *Turning a SIGSEGV into a regular function call
under Linux, allowing throw*, not only Exception. I don't
understand what is the problem here ? Can't we talk about how
we could keep trash register clean in cas
On Wed, 14 Mar 2012 16:08:29 -0400, Don Clugston wrote:
Now, your user space handler will cause another segfault when it does
the mov [ESP], 0. I think that gives you an infinite loop.
SEGFAULT inside a SEGV signal handler aborts the program (no way to turn
this off IIRC).
-Steve
On 14/03/12 21:31, Steven Schveighoffer wrote:
On Wed, 14 Mar 2012 16:08:29 -0400, Don Clugston wrote:
Now, your user space handler will cause another segfault when it does
the mov [ESP], 0. I think that gives you an infinite loop.
SEGFAULT inside a SEGV signal handler aborts the program (no
On 03/14/12 21:08, Don Clugston wrote:
>
> I didn't realize that was possible. Very interesting.
> As it stands, though, that's got some pretty serious issues.
>
> You are on the stack of the function that was called, but you don't know for
> sure that it is a valid stack.
>
> asm {
> push
On Wed, 14 Mar 2012 16:45:49 -0400, Don Clugston wrote:
On 14/03/12 21:31, Steven Schveighoffer wrote:
On Wed, 14 Mar 2012 16:08:29 -0400, Don Clugston wrote:
Now, your user space handler will cause another segfault when it does
the mov [ESP], 0. I think that gives you an infinite loop.
S
On Mar 14, 2012, at 1:54 PM, FeepingCreature wrote:
>
> I think that case is sufficiently rare that it'd have to count somewhere
> between "act of god" and "outright developer malice". The assumption that the
> stack frame is valid is, I'd say, safe to make in the vast majority of cases.
> You
Le 14/03/2012 21:28, Vladimir Panteleev a écrit :
On Wednesday, 14 March 2012 at 20:20:05 UTC, deadalnix wrote:
The topic is *Turning a SIGSEGV into a regular function call under
Linux, allowing throw*, not only Exception. I don't understand what is
the problem here ? Can't we talk ab
Le 14/03/2012 21:53, Steven Schveighoffer a écrit :
On Wed, 14 Mar 2012 16:45:49 -0400, Don Clugston wrote:
On 14/03/12 21:31, Steven Schveighoffer wrote:
On Wed, 14 Mar 2012 16:08:29 -0400, Don Clugston wrote:
Now, your user space handler will cause another segfault when it does
the mov [
Le 14/03/2012 21:59, Sean Kelly a écrit :
On Mar 14, 2012, at 1:54 PM, FeepingCreature wrote:
I think that case is sufficiently rare that it'd have to count somewhere between "act of
god" and "outright developer malice". The assumption that the stack frame is valid
is, I'd say, safe to make i
On Wed, 14 Mar 2012 17:25:28 -0400, deadalnix wrote:
Le 14/03/2012 21:53, Steven Schveighoffer a écrit :
On Wed, 14 Mar 2012 16:45:49 -0400, Don Clugston wrote:
On 14/03/12 21:31, Steven Schveighoffer wrote:
On Wed, 14 Mar 2012 16:08:29 -0400, Don Clugston
wrote:
Now, your user space
On 14/03/12 21:59, Sean Kelly wrote:
On Mar 14, 2012, at 1:54 PM, FeepingCreature wrote:
I think that case is sufficiently rare that it'd have to count somewhere between "act of
god" and "outright developer malice". The assumption that the stack frame is valid
is, I'd say, safe to make in the
On Wed, Mar 14, 2012 at 05:35:04PM -0400, Steven Schveighoffer wrote:
[...]
> I get that. What I was saying is, I thought even the signal handler
> uses the stack (thereby it would abort if invalid). And even if it
> doesn't, simply accessing the stack by loading it into a register
> should be su
Here is a proof of concept of how we can recover from segfault.
This isn't perfect as it doesn't protect everything (like floating point
registers). This is mostly because I can't find the precise
documentation about what must be saved or not.
The handler call a naked function that will set u
Does it recover from
void function() f=null;
f();
On 03/15/12 16:16, Kagamin wrote:
> Does it recover from
>
> void function() f=null;
> f();
Not as currently written, no. It should be possible to detect this case and get
a proper stackframe back, though.
Le 15/03/2012 21:20, FeepingCreature a écrit :
On 03/15/12 16:16, Kagamin wrote:
Does it recover from
void function() f=null;
f();
Not as currently written, no. It should be possible to detect this case and get
a proper stackframe back, though.
It is supported as written in my sample code.
39 matches
Mail list logo
