This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] vfprintf: validate nargs and maybe allocate from heap
On Tue, Feb 14, 2012 at 04:20:17PM -0600, Ryan S. Arnold wrote:
> On Fri, Feb 10, 2012 at 1:24 PM, Kees Cook <firstname.lastname@example.org> wrote:
> > Just checking in on this. Is anyone willing to ACK this patch?
> The patch passed make check for PowerPC 32-bit and Libdfp 32-bit
> regression testing of the printf-hooks mechanism.
> Currently I'm testing PowerPC 64-bit and bug-vfprintf-nargs is getting
> killed by the skeleton code due to a timeout before the expected
> SEGV happens.
Hrm, I wonder if this timeout is from it allocating giant memory region
using a layout that actually allows it without crashing into other things.
(i.e. x86_64 would always very rapidly crash, but I don't know about
> >From my tests it looks like the test-case needs a TIMEOUTFACTOR
> environment variable to give the test time to SEGV on PowerPC64. On a
> system that's not under load a timeoutfactor of 10 seemed to be
> in sysdeps/powerpc/powerpc64/Makefile:
> ifeq ($(subdir),stdio-common)
> bug-vfprintf-nargs-ENV = TIMEOUTFACTOR="10"
> The problem with this method is that this may still fail with a
> SIGALRM before the SEGV happens on a system under load (for instance
> under a parallel make check).
> The other possibility is to changed the expected signal to SIGALRM for
> powerpc64 in bug-vfprintf-nargs.c:
> #if __WORDSIZE == 32
> # define EXPECTED_STATUS 0
> #elif defined __powerpc64__
> # define EXPECTED_SIGNAL SIGALRM
> # define EXPECTED_SIGNAL SIGSEGV
> Of course, on a system that's not under loader this may SEGV before
> the timeout is hit and SIGALRM is raised.
Perhaps under 64-bit, it should just skip the test entirely? The 64-bit
case is meaningless anyway.
Kees Cook @outflux.net