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

[Solar Designer <solar at false dot com>]

> 
> 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