Re: [RFC 00/15] x86_64: Optimize percpu accesses

[Eric W. Biederman]

Arjan van de Ven <arjan@xxxxxxxxxxxxx> writes:

>> I think the unification is valid and useful, and that trying to keep
>> that stupid stack canary working is currently more trouble then it is
>> worth.
>
> I think that "unification over everything" is stupid, especially if it
> removes useful features.

After looking at this some more any solution that actually works will
enable us to make the stack canary work, as we have a 32bit offset to
deal with.  So there is no point in killing the feature.

That said I have no sympathy for a thread local variable that is
compiled as an absolute symbol instead of using the proper thread
local markup.  The implementation of -fstack-protector however useful
still appears to be a nasty hack, ignoring decades of best practice in
how to implement things.

Do you have a clue who we need to bug on the gcc team to get the
compiler to implement a proper TLS version of -fstack-protector?

- Unification over everything is stupid.  
- Interesting features that disregard decades implementation experience
  are also stupid.

Since we know that the code stack_canary is always a part of the
executable.  Being a fundamental part of glibc and libpthreads etc.
We can use the local exec model for tls storage.  The local exec model
means the compiler should be able to output code such as 
"movq %fs:stack_canary@tpoff, %rax" to read the stack canary in user space.
Instead it emits the much more stupid "movq "%fs:40, %rax".   Not even
letting the linker have a say in the placement of the variable.

So we either need to update the gcc code to do something proper or
someone needs to update the sysv tls abi spec so %fs:40 joins %fs:0 in
the ranks of magic address in thread local storage, so that other
compilers can reliably use offset 40, and no one will have an excuse
for changing it in the future.  Frankly I think updating the ABI is
the wrong solution but it at least it would document this stupidity.

Does -fstack-protector compiled code even fail to run with gcc that
does not implement a thread local variable at %fs:40?  Or does it
just silently break.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/