Re: [Various] libc/1609: Error in 'make check' origtest withtestobj1.so

[James Renken <jrenken at sandwich dot net>]

Yes, non-executable stack was the only option that I had disabled (that
I usually leave on).  I was indeed compiling glibc2 with 2.95, and I tried
both Secure-Linux 2.2.14ow1 and ow2, both of which failed.  With the stack
patch disabled, the origtest check worked as normal.

The system is already glibc 2.1 based, and has booted quite happily using
Secure-Linux for quite a while.

Here's the output from stacktest -b (with S-L stack patch enabled):

Attempting to call a trampoline...
Succeeded.
Attempting to simulate a buffer overflow exploit...
Segmentation fault

Thanks. :)

-- 
James Renken, System Administrator                    jrenken@sandwich.net
Sandwich.Net Internet Services    http://www.sandwich.net/    760-729-4609

On Tue, 29 Feb 2000, Solar Designer wrote:

> > 
> > The glibc2 sources were unchanged.  I was running Linux 2.2.14 with the
> > Secure-Linux patch (2.2.14-ow2); however, I looked at a few options, and
> > the check works perfectly with the non-executable stack option of
> > Secure-Linux disabled.
> 
> Yes, this sounds like it could be a bug in the patch, so I would
> definitely want you to do some more testing of this. ;-)
> 
> Is this the only option you've disabled?  If not, then we'll need to
> start with making sure it's the option that made the change.
> 
> First, one thing for your information: I am supporting the gcc 2.95+
> trampoline code (it's slightly different) starting with the patch for
> 2.2.14, so it is important that you weren't using a version earlier
> than this when compiling with gcc 2.95+.
> 
> Now, what you can try to track this problem:
> 
> 1. "stacktest -b" when running with non-executable stack, and mail me
> the results.
> 
> 2. I think that you should be able to run a glibc 2.1 system without
> the trampoline support in my patch (but with non-executable stack).
> I'm not 100% sure of that, though, as I'm not using glibc 2.1 on x86
> myself, yet (am going to after porting some hacks, etc) and the patch
> is indeed x86-specific.  So, if you're able to boot and login with
> that option disabled, you can try re-compiling glibc (don't forget
> "make clean") and see if the compile crashes (because it needed the
> trampoline support) or not.  If no process crashes before it gets to
> that testobj1 problem, then this is hardly related to trampolines.
> (If glibc 2.1 itself still uses trampolines, then we'd have to add a
> printk into linux/arch/i386/traps.c to see what's going on.)
> 
> Actually, it's possible Ulrich can answer this question without you
> having to try.  Does glibc 2.1 itself still use trampolines in some
> place that's critical to get a system running?  Does it require that
> trampolines work while it's being compiled?
> 
> To answer Ulrich's question, the patch will terminate the program
> that tries to execute code on the stack, but only if that isn't a
> trampoline call (if the emulation is enabled).
> 
> Your conclusion that the problem is definitely in the kernel patch is
> not correct (as you didn't have all the information) -- in addition
> to making the stack non-executable (which is not visible from user
> space until a process actually tries to branch to a stack address),
> the patch changes the default address for mmap(2), which also affects
> where shared libraries are mapped.  This can cause some application
> bugs or limitations to show up.  This can well be a bug in my code,
> I'm just pointing out that we can't be sure of that, yet.
> 
> Signed,
> Solar Designer
>