Re: [ECOS] Calling Ubunutu users: testing please

[Bart Veer <bartv at ecoscentric dot com>]

>>>>> "Andrew" == Andrew Lunn <andrew@lunn.ch> writes:

    <snip>
    Andrew> Ubunutu have enabled the compiler flag stack-protector by
    Andrew> default in at least version 4.1.2 of gcc and i expect all
    Andrew> newer versions. For stack protector to work, the compiler
    Andrew> need a bit of help from the process/thread startup code to
    Andrew> allocate some memory and initialize a processor register
    Andrew> to point to it. eCos on synth is currently not doing this.
    Andrew> So when it tries to access this memory, it actually tries
    Andrew> to read/write from 0x0:0x14 which throws a segmentation
    Andrew> fault.

    >> And the only problem was the - -finit-priority option. When you
    >> turn it of everything works fine (Using not the CVS snapshot
    >> but the version from the site). I had the problem target.ld on
    >> our build server (Suse 9.x) -
    >> 
    >> MEMORY
    >> {
    >> rom : ORIGIN = 0x00000000, LENGTH = 0x800000

    Andrew> So you have moved ROM down from 0x01000000 to 0x0. This
    Andrew> actually fits. You have put memory where it is trying to
    Andrew> access. However, you now have 0x0:14 corrupted by the
    Andrew> stack checking code :-(

    Andrew> I expect with time stack-protector will be turned on for
    Andrew> other distributions. So either we need to set the synth
    Andrew> hal compiler flags to turn it off, or implement what it
    Andrew> needs to work.

Fedora core 7's gcc still has -fstack-protector disabled by default. I
am not sure whether the gcc developers' intention was that it should
ever be enabled by default, as opposed to specifically enabled for
vulnerable applications, since it does add some overhead.  Under
Fedora, if I explicitly add -fstack-protector to CYGBLD_GLOBAL_CFLAGS
I can reproduce the problem.

I don't fully understand yet what the compiler flag does, but it seems
to be something like the following. On x86 Linux the thread local
storage area or TLS can be accessed via the %gs segment register. Slot
0x14 within the TLS is used to point at a magic number at the base of
the stack. Stack protection involves reading the magic number on
function entry and checking that it has not been corrupted on function
exit.

So we would need a data area in eCos that looks a bit like a Linux TLS
structure and arrange for Linux to initialize %gs to access that
structure. A user-space application like the synthetic target cannot
easily manipulate %gs directly, that involves interacting with the
memory management settings etc. A simplistic implementation would just
involve %gs:0x14 pointing at a fixed location for the lifetime of the
eCos application. A more advanced implementation would update %gs:0x14
in the eCos context switch code to reflect the thread's stack.

What I have not yet figured out is what is needed in an executable to
get the TLS and %gs set up correctly. Presumably it requires some
magic in the linker script but I cannot find any relevant
documentation. Or maybe it is normally done at run-time somehow by the
glibc initialization code.


The alternative is to build with -fno-stack-protection. However the
flag was only added in gcc 4.1.0. Specifying the flag with older
compilers will give an error, and I am not sure we can assume gcc >=
4.1.0 yet. A partial work around would be some extra Tcl code in
hal_synth_i386.cdl: exec gcc --version, parse the output, and adjust
the default value of CYGBLD_GLOBAL_CFLAGS accordingly. That would go
wrong if CYGBLD_GLOBAL_COMMAND_PREFIX is set to something other than
"", e.g. when cross-compiling, but it would probably work for 99% or
so of users. It does add the overhead of a gcc invocation whenever the
CDL script is loaded, but that is barely going to be noticeable.

Bart

-- 
Bart Veer                                   eCos Configuration Architect
eCosCentric Limited    The eCos experts      http://www.ecoscentric.com/
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss