diff options
author | Rich Felker <dalias@aerifal.cx> | 2015-05-16 01:15:40 -0400 |
---|---|---|
committer | Rich Felker <dalias@aerifal.cx> | 2015-05-16 01:15:40 -0400 |
commit | 707d7c30f3379441de9b320536ddfd354f4c2143 (patch) | |
tree | f2252cc09c6ae67ac14a025be2314ca8079280f5 /README | |
parent | c0f10cf06725bd0de37f3ced7954a653bf9f1049 (diff) | |
download | musl-707d7c30f3379441de9b320536ddfd354f4c2143.tar.gz musl-707d7c30f3379441de9b320536ddfd354f4c2143.tar.bz2 musl-707d7c30f3379441de9b320536ddfd354f4c2143.tar.xz musl-707d7c30f3379441de9b320536ddfd354f4c2143.zip |
in i386 __set_thread_area, don't assume %gs register is initially zero
commit f630df09b1fd954eda16e2f779da0b5ecc9d80d3 added logic to handle
the case where __set_thread_area is called more than once by reusing
the GDT slot already in the %gs register, and only setting up a new
GDT slot when %gs is zero. this created a hidden assumption that %gs
is zero when a new process image starts, which is true in practice on
Linux, but does not seem to be documented ABI, and fails to hold under
qemu app-level emulation.
while it would in theory be possible to zero %gs in the entry point
code, this code is shared between static and dynamic binaries, and
dynamic binaries must not clobber the value of %gs already setup by
the dynamic linker.
the alternative solution implemented in this commit simply uses global
data to store the GDT index that's selected. __set_thread_area should
only be called in the initial thread anyway (subsequent threads get
their thread pointer setup by __clone), but even if it were called by
another thread, it would simply read and write back the same GDT index
that was already assigned to the initial thread, and thus (in the x86
memory model) there is no data race.
Diffstat (limited to 'README')
0 files changed, 0 insertions, 0 deletions