[ECOS] Calling Ubunutu users: testing please

[ECOS] Calling Ubunutu users: testing please

[Andrew Lunn]

Hi Folks

Any Ubuntu users out there? 

I've had reports that the synth target does not run on Ubunutu. It
dies very early on during startup. I think i have tracked this
down. If anybody has this problem, please could you try adding

-fno-stack-protector

to the compiler flags and let me know if this fixes the problem.

   Thanks
        Andrew

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

Re: [ECOS] Calling Ubunutu users: testing please

[Bart Veer]

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

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

    Andrew> I don't know much about the x86 architecture.

Lucky you - in areas like this it gets very unpleasant.    
    
    Andrew> Is %gs protected? Ring 0? Or can an application change it?
    Andrew> I was wounding about allocating a page and pointing %gs at
    Andrew> it. Is %gs a segment register? If so the page would have
    Andrew> to be allocated at the correct location in the segment.
    Andrew> This sounds more like a job for the linker, as you
    Andrew> suggested. I did not come across code in glibc, but i did
    Andrew> find a patch which adds support to the kernel. However,
    Andrew> that is not much use for us.

%gs is a segment register, so it is necessary to create an entry in
the local segment descriptor table, reload that, and then you can
update %gs to reference the new entry. Only the Linux kernel can do
that.

There does appear to be some relevant code in glibc, macro
TLS_INIT_TP() in libc/nptl/sysdeps/i386/tls.h. It looks like there is
a system call SYS_modify_ldt to update the local segment descriptor
table. I am still quite some way from figuring out how that all fits
together. However the work is done at run-time, not at link-time.
Hence the synthetic target changes would have to be done in assembler
in vectors.S - doing it in any C code would be too late.
    
    >> The alternative is to build with -fno-stack-protection.

    Andrew> It would be nice to get this working on synth. Do we
    Andrew> really need to be worried about the additional code size
    Andrew> and the run time penalty? It is a synthetic target after
    Andrew> all, used for development and debugging. Having additional
    Andrew> checks for stack corruption sounds like a good idea to me.
    Andrew> This must be one of the most common problems that new eCos
    Andrew> uses get.

We don't need to worry much about performance for the synthetic
target. However this additional check seems to offer only minimal
benefits - it currently checks the base of the stack, not the top of
the stack, so it will only catch some stack stomping attacks rather
than stack overflows. If it operated on a per stack frame basis then
I could see significant value in that, but checking only the base of
the stack seems pretty pointless.

Now, for eCos we could arrange things so that it did check the top of
the stack rather than the base, but that would require more work
including the context switch code. And we already have
CYGFUN_KERNEL_THREADS_STACK_CHECKING.

So we are talking about adding some pretty nasty assembler code to the
synthetic target for little or no gain, compared with insisting on
building with -fno-stack-protection. Worse, we would again be at the
mercy of the gcc/glibc/kernel folks whenever they decide to make some
subtly incompatible tweaks to the way this stuff works. We have
already had problems in this area with the signal handling
implementation. I am not convinced it is worth it.

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

Re: [ECOS] Calling Ubunutu users: testing please

[Andrew Lunn]

> Fedora, if I explicitly add -fstack-protector to CYGBLD_GLOBAL_CFLAGS
> I can reproduce the problem.

I did the same with Debian. 

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

That agrees with what i figured out, or found on a couple of mailing
lists.
 
> 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.

I don't know much about the x86 architecture.  Is %gs protected? Ring
0? Or can an application change it? I was wounding about allocating a
page and pointing %gs at it. Is %gs a segment register? If so the page
would have to be allocated at the correct location in the segment.
This sounds more like a job for the linker, as you suggested.  I did
not come across code in glibc, but i did find a patch which adds
support to the kernel. However, that is not much use for us.

> The alternative is to build with -fno-stack-protection.

It would be nice to get this working on synth. Do we really need to be
worried about the additional code size and the run time penalty? It is
a synthetic target after all, used for development and
debugging. Having additional checks for stack corruption sounds like a
good idea to me. This must be one of the most common problems that new
eCos uses get.

     Andrew

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

Re: [ECOS] Calling Ubunutu users: testing please

[Bart Veer]

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

Re: [ECOS] Calling Ubunutu users: testing please

[Andrew Lunn]

On Thu, Aug 09, 2007 at 02:39:29AM +0200, Ivan Kostov wrote:
> Hi ,
> 
> I'm using Ubuntu 6.06
> 
> Using built-in specs.
> Target: i486-linux-gnu
> Configured with: ../src/configure -v
> --enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
> --enable-shared --with-system-zlib --libexecdir=/usr/lib
> --without-included-gettext --enable-threads=posix --enable-nls
> --program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu
> --enable-libstdcxx-debug --enable-java-awt=gtk-default
> --enable-gtk-cairo
> --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre
> --enable-mpfr --disable-werror --with-tune=pentium4
> --enable-checking=release i486-linux-gnu
> Thread model: posix
> gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)

Hi Ivan

It seems like the problem happens with newer compilers. 

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

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

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

   Andrew

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

Re: [ECOS] Calling Ubunutu users: testing please

[Ivan Kostov]

Hi ,

I'm using Ubuntu 6.06

Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-awt=gtk-default
--enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre
--enable-mpfr --disable-werror --with-tune=pentium4
--enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)

GNU ld version 2.16.91 20060118 Debian GNU/Linux

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
    ram : ORIGIN = 0x02000000, LENGTH = 0x800000
}

this works for me. If you need further testing on ubuntu please let me know.

Cheers
Ivan






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