Bug#762195: libc6: libpthread: hardware-assisted lock elision hazardous on x86
On Mon, 29 Sep 2014, Henrique de Moraes Holschuh wrote:
> On Fri, 19 Sep 2014, Henrique de Moraes Holschuh wrote:
> Apparently there's at least one codepath that attempts to use lock elision
> regardless of --enable-lock-elision in x86 in rwlock. I'm searching for it.
Indeed it looks like glibc 2.19 also fails to disable hardware lock elision
entirely, even in a --disable-lock-elision build.
The blacklist patch would disable it, though, as setting HAS_RTM to zero
must be enough to disable any use of Intel TSX. Otherwise libpthread would
SIGILL on every processor that doesn't have Intel TSX instructions enabled,
and we know it isn't doing that.
After looking at it a bit closer, I have changed my instance: I recommend
that lock elision support in glibc should be disabled for Debian jessie.
This thing doesn't look nearly stable enough in glibc 2.19, and any bugs it
might cause *will be subtle*.
Patch source: Fedora RPM (glibc-2.20-5.fc21)
http://koji.fedoraproject.org/koji/buildinfo?buildID=581316
Original patch author: Carlos O'Donell <carlos@redhat.com>
This patch required some manual fixup. I've done some light inspection of
the code to make sure it is sane.
NOTE: it looks like HLE is always attempted in rwlocks in any boxes that
advertise HAS_RTM, even if __libc_enable_secure is set. The patch _does
not_ change this behaviour, be it safe or unsafe. Fedora's patch doesn't
change this, and I don't know enough to judge.
The patch was compile-tested. Some tests on the testsuite are failing, but
apparently not because of the patch.
objdump tells me Intel TXS opcodes DO leak into libpthread (inside the
__lll_*_elision routines) no matter what you do, i.e. --disable-lock-elision
is indeed a lie if you don't take pains to make sure these routines are not
called at runtime.
Since we shouldn't trust --disable-lock-elision to do the full job, it seems
best to make doubly sure Intel TSX won't be used: patch to override HAS_RTM
to really disable this stuff attached (glibc_2.19-really-disable-hle.patch).
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--- a/nptl/sysdeps/unix/sysv/linux/x86/elision-conf.c 2014-02-07 07:04:38.000000000 -0200
+++ b/nptl/sysdeps/unix/sysv/linux/x86/elision-conf.c 2014-09-29 11:19:55.899095112 -0300
@@ -62,9 +62,15 @@
char **argv __attribute__ ((unused)),
char **environ)
{
- __elision_available = HAS_RTM;
#ifdef ENABLE_LOCK_ELISION
+ __elision_available = HAS_RTM;
__pthread_force_elision = __libc_enable_secure ? 0 : __elision_available;
+ if (!HAS_RTM)
+ __elision_aconf.retry_try_xbegin = 0; /* Disable elision on rwlocks */
+#else
+ __elision_available = 0;
+ __pthread_force_elision = 0;
+ __elision_aconf.retry_try_xbegin = 0;
#endif
}
--- a/sysdeps/x86_64/multiarch/init-arch.h 2014-09-29 11:36:07.511536944 -0300
+++ b/sysdeps/x86_64/multiarch/init-arch.h 2014-09-29 11:36:59.622947602 -0300
@@ -152,7 +152,7 @@
# define HAS_SSSE3 HAS_CPU_FEATURE (COMMON_CPUID_INDEX_1, ecx, bit_SSSE3)
# define HAS_SSE4_1 HAS_CPU_FEATURE (COMMON_CPUID_INDEX_1, ecx, bit_SSE4_1)
# define HAS_SSE4_2 HAS_CPU_FEATURE (COMMON_CPUID_INDEX_1, ecx, bit_SSE4_2)
-# define HAS_RTM HAS_CPU_FEATURE (COMMON_CPUID_INDEX_7, ebx, bit_RTM)
+# define HAS_RTM (0)
# define index_Fast_Rep_String FEATURE_INDEX_1
# define index_Fast_Copy_Backward FEATURE_INDEX_1
Reply to: