Re: executable stacks, a few suggetions

Richard B. Johnson (
Thu, 17 Apr 1997 20:14:49 -0400 (EDT)

On Fri, 18 Apr 1997 wrote:

> Hello!
> > If so, shouldn't the proper course of action be to rewrite the user input
> > portion of the program so this was impossible? I see too may programs
> > that use gets(buffer) with buffer[] being a few hundred bytes allocated
> > on the stack. This is very bad coding. It's just luck that makes such
> > programs work.
> I guess I should state it clearly now. In my opinion, the programs should
> definitely be fixed. But still, there will remain some buggy ones. Also,
> there're programs that are spread as binaries only, and that are still
> widely used. So, why not decrease the number of exploitable overflows in
> these, by kernel means?
> Anyway, to the kernel patch stuff -- I've finally modified signal handler
> returns to use the GPF handler also, it works now. So no need to temporary
> enable execution permission for the signal handler execution period. This
> fixes the longjmp() problem also.
This is very nice if the changes have little or no impact upon performance.
However, if kernel performance suffers because it has to protect against
bad programs, there has to be some kind of trade-off involved. I note
that the safest way to use a computer is to power it off (use it as
an ornament). This gives you complete security but very little utility.
The other end of the spectrum is to run everything in kernel mode with
no protection at all. This gives you excellent utility, but no security.

Dick Johnson
Richard B. Johnson
Project Engineer
Analogic Corporation
Voice : (508) 977-3000 ext. 3754
Fax : (508) 532-6097
Modem : (508) 977-6870
Ftp :
Email :,
Penguin : Linux version 2.1.35 on an i586 machine (66.15 BogoMips).
Warning : I read unsolicited mail for $350.00 per hour. Supply billing address.