[haiku-commits] Re: BRANCH pdziepak-github.scheduler [b3723fd] src/system/kernel/arch/x86/32 headers/private/kernel/arch/x86/32 src/system/boot/platform/bios_ia32 headers/private/kernel/arch/x86 src/system/kernel/arch/x86/64
- From: Fredrik Holmqvist <fredrik.holmqvist@xxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Tue, 17 Dec 2013 22:02:12 +0100
2013/12/17 Pawel Dziepak <pdziepak@xxxxxxxxxxx>:
> It's actually a bit more complicated than that.
>
> GCC expects the canary value to be stored either in TLS at certain
> offset (e.g. %gs:0x14 on x86 platforms using glibc) or in global
> variable __stack_chk_guard. It chooses the former if there is 'gnu'
> somewhere in the target triple or GCC knows by any other means that
> the resulting code will be linked against glibc. Since Linux can be
> built without cross-compiler they have to provide support for that
> also in the kernel. In all other cases the latter option is used,
> hence we don't have to worry about it.
>
> However, if we want to support stack protectors with per thread
> canaries in userland as well as in the kernel (that would obviously
> require updating GCC configure) this patch actually makes it easier.
> On x86 only the first 4 bytes of the segment at gs are used to store
> the pointer to the thread and on x86_64 gs points to architecture
> dependent thread data. GCC expects to find the canary value at
> %gs:0x14 for x86, %gs:0x18 for x32 and %gs:0x28 for x86_64 so there
> would be no problem to put it there.
>
> Summing it up, as far as we use the same canary value to all threads
> in a team this patch is completely unrelated. When we want to start
> using different canary value for each thread then we only need to
> adjust the structures gs points to (and update the canary value at
> each task switch).
That would make an excellent code comment ;)
/Fredrik Holmqvist, TQH
Other related posts:
