Re: 2nd Linux kernel patch to remove stack exec

Richard Henderson (
Mon, 14 Apr 1997 11:05:30 -0500 (CDT)

> Adding a check for RETF also will help somewhat, but not much, since there're
> many two-byte instructions to pass the control onto the stack, and that
> still leaves quite a high probability that some suitable bytes exist in the
> code segment. The solution I did now (running this while typing this message)
> is to only allow a few instructions, not reject a few, in the GPF handler.

But what's to say the retf needs to GPF? Can it not change segments
back to HUGE_CS at the same time? Should be trivial since it is already
modifying the stack to get to the retf insn.

> Another fix might be to keep a flag for each task, whether it should
> have its stack executable or not, and another flag, if it's inside a signal
> handler or not, both are quite easy to implement, and set the CS on return
> from every syscall accordingly.

Unfortunately, it is not possible to tell if we've actually finished
with the signal or not. While not strictly ANSI or POSIX, most Unices,
Linux included, allow processes to stay indefinitely in the signal
handler, and to do arbitrary things.

You can kind of tell from user space, if you hack set/longjmp, but not
from the kernel.