Am 05.05.2015 um 19:15 schrieb Will Deacon: > On Tue, May 05, 2015 at 06:09:57PM +0100, André Hentschel wrote: >> Am 05.05.2015 um 12:51 schrieb Will Deacon: >>> On Sun, May 03, 2015 at 05:24:18PM +0100, André Hentschel wrote: >>>> From: André Hentschel <nerv@xxxxxxxxxxx> >>>> >>>> Since commit a4780adeefd042482f624f5e0d577bf9cdcbb760 the user writeable TLS >>>> register on ARM is preserved per thread. >>>> >>>> This patch does it analogous to the ARM patch, but for compat mode on ARM64. >>>> >>>> Signed-off-by: André Hentschel <nerv@xxxxxxxxxxx> >>>> Cc: Will Deacon <will.deacon@xxxxxxx> >>>> Cc: Jonathan Austin <jonathan.austin@xxxxxxx> >>>> >>>> --- >>>> This patch is against Linux 4.1-rc1 (b787f68c36d49bb1d9236f403813641efa74a031) >>> >>> Curious, but why do you need this? iirc, we added this for arch/arm/ because >>> of some windows rt (?) emulation in wine. Is that still the case here and is >>> anybody actually using that? >> >> Yes, Windows ARM binaries are the well known use case, but also the compat >> mode should do what the arm kernel is doing I’d think and the code wasn't >> adjusted yet. > > Sure, I was just curious. OK :) So what about the patch? >> What i'm curious about is why the main TLS register on arm64 is the user >> writeable, I'm not an security expert but this looks odd. I could easily >> provoke a crash by writing to it... > > You've probably got the wrong TLS. Allowing a program to clobber it's own > thread-local storage is no worse than allowing it to write to its general > purpose registers, pc, etc. > > I'm assuming the crash you saw was just a userspace crash, rather than > the kernel? > True, but the system became horribly instable, files were overwritten by others, very strange. It was in a remote KVM VM on bare metal aarch64... I don't dare to try it again because it causes others some trouble, but if someone wants to try it out: https://github.com/AndreRH/tpidrurw-test -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
