bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

c-stack vs. older platforms


From: Eric Blake
Subject: c-stack vs. older platforms
Date: Thu, 5 Jun 2008 15:28:08 +0000 (UTC)
User-agent: Loom/3.14 (http://gmane.org/)

I'm considering abandoning m4's stack overflow detector[1] (first written in 
Apr 94) with gnulib's c-stack module (first written for diffutils in Feb 02) 
because m4's version does not obey signal safety rules.  Also, I've noticed 
m4's version tends to misdiagnose failure on Linux and dump core rather than 
print a nice diagnostic, because its somewhat dated heuristics are tied to 
checking whether the fault fell in a narrow window determined from getrlimit, 
but the window didn't always match the actual end of stack (by the time Linux 
rounds the soft limit up to a nicer boundary, and in the presence of stack 
start randomization designed to make buffer overflow exploits more difficult).  
Meanwhile, c-stack goes further in evaluation of the faulting address in 
relation to the fault context, and diagnoses failure correctly on Linux, so 
using c-stack would be a bug fix on multiple fronts.

But before making the swap, I'm wondering whether there are any current porting 
targets where m4's attempts to use the fallbacks of sigstack in place of 
missing sigaltstack, and/or sigvec/SV_ONSTACK in place of missing 
sigaction/SA_ONSTACK, are worth porting into the c-stack module.  Or put 
another way, are there any platforms where switching to c-stack would cause a 
regression in m4's stack detection abilities if we don't port m4's fallbacks 
for supporting older APIs?

[1]http://git.savannah.gnu.org/gitweb/?p=m4.git;a=blob;f=src/stackovf.c

-- 
Eric Blake






reply via email to

[Prev in Thread] Current Thread [Next in Thread]