>>>>> "Andrew" == Andrew Lunn <[EMAIL PROTECTED]> 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