From: Will Deacon <will.deacon@arm.com>
To: "André Hentschel" <nerv@dawncrow.de>
Cc: "linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
Jonathan Austin <Jonathan.Austin@arm.com>,
Nathan Lynch <nathan_lynch@mentor.com>,
Catalin Marinas <Catalin.Marinas@arm.com>
Subject: Re: [PATCH] arm64: Preserve the user r/w register tpidr_el0 on context switch and fork in compat mode
Date: Tue, 5 May 2015 18:15:58 +0100 [thread overview]
Message-ID: <20150505171558.GO1550@arm.com> (raw)
In-Reply-To: <5548F965.9070302@dawncrow.de>
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@dawncrow.de>
> >>
> >> 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@dawncrow.de>
> >> Cc: Will Deacon <will.deacon@arm.com>
> >> Cc: Jonathan Austin <jonathan.austin@arm.com>
> >>
> >> ---
> >> 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.
> 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?
Will
WARNING: multiple messages have this Message-ID (diff)
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64: Preserve the user r/w register tpidr_el0 on context switch and fork in compat mode
Date: Tue, 5 May 2015 18:15:58 +0100 [thread overview]
Message-ID: <20150505171558.GO1550@arm.com> (raw)
In-Reply-To: <5548F965.9070302@dawncrow.de>
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@dawncrow.de>
> >>
> >> 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@dawncrow.de>
> >> Cc: Will Deacon <will.deacon@arm.com>
> >> Cc: Jonathan Austin <jonathan.austin@arm.com>
> >>
> >> ---
> >> 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.
> 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?
Will
next prev parent reply other threads:[~2015-05-05 17:15 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-03 16:24 [PATCH] arm64: Preserve the user r/w register tpidr_el0 on context switch and fork in compat mode André Hentschel
2015-05-03 16:24 ` André Hentschel
2015-05-05 10:51 ` Will Deacon
2015-05-05 10:51 ` Will Deacon
2015-05-05 17:09 ` André Hentschel
2015-05-05 17:09 ` André Hentschel
2015-05-05 17:15 ` Will Deacon [this message]
2015-05-05 17:15 ` Will Deacon
2015-05-05 17:19 ` André Hentschel
2015-05-05 17:19 ` André Hentschel
2015-05-05 17:36 ` Will Deacon
2015-05-05 17:36 ` Will Deacon
2015-05-06 17:05 ` Will Deacon
2015-05-06 17:05 ` Will Deacon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150505171558.GO1550@arm.com \
--to=will.deacon@arm.com \
--cc=Catalin.Marinas@arm.com \
--cc=Jonathan.Austin@arm.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=nathan_lynch@mentor.com \
--cc=nerv@dawncrow.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.