Subject: Re: signal(SIGSEGV, SIG_IGN) -> 100% CPU
To: None <>
From: Greg A. Woods <>
List: tech-kern
Date: 06/13/1999 00:08:37
[ On Saturday, June 12, 1999 at 18:38:54 (-0700), Gandhi woulda smacked you wrote: ]
> Subject: Re: signal(SIGSEGV, SIG_IGN) -> 100% CPU
> The statement that it's tantamount to
> main() { char *0xdeadbeef = 1; }
> is not true, or shouldn't be, as in a call, you're not dereferencing
> the bad address until you actually try to modify or read it, while the
> above attempts to modify the address immediately.

Well, it is true currently because of the way the pipe() system call has
actually been implemented in the kernel to return its results in two CPU
registers that are then loaded into the int vector after the call
returns.  I.e. the pointer never makes it to kernel land and thus can
never be bounds checked....

I agree that this is wrong, which is what I was attempting to say in my
last message in this thread.

I don't see any reason to play tricks with registers any more (and in
the case of pipe() I'm not sure there ever were any *real* reasons -- it
was just a hack carried on from the days when the entire kernel was
written in assember, so far as I can see).  These days it's just one
more bit of special assembler code that must be separately ported to
every new architecture.

> # > That is probably true for many or all of the system calls.
> ...really?  are there any other broken calls we don't know about yet?
> System calls are supposed to do bounds checking.

Not all of, but at least some of, /usr/src/lib/libc/arch/*/sys/*.S, but
not all system calls in general -- I know from experience that at least
some really do return EFAULT when handed a NULL pointer, etc.

							Greg A. Woods

+1 416 218-0098      VE3TCP      <>      <robohack!woods>
Planix, Inc. <>; Secrets of the Weird <>