This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Calling Ubunutu users: testing please


> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]