[ECOS] Calling Ubunutu users: testing please
Tue Aug 21 10:20:00 GMT 2007
>>>>> "Andrew" == Andrew Lunn <firstname.lastname@example.org> writes:
>> 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
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
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 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
More information about the Ecos-discuss