From: Steve Capper <steve.capper@arm.com>
To: Alexander Graf <agraf@suse.de>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Mark Rutland <mark.rutland@arm.com>,
mbrugger@suse.com, Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Stuart Monteith <Stuart.Monteith@arm.com>,
Zheng Xu <Zheng.Xu@arm.com>
Subject: Re: [PATCH] arm64: Add config to limit user space to 47bits
Date: Thu, 14 Jul 2016 02:08:16 +0100 [thread overview]
Message-ID: <20160714010812.GA17138@e103986-lin> (raw)
In-Reply-To: <578668D3.6010406@suse.de>
Hi Alex,
Thanks for posting this.
On Wed, Jul 13, 2016 at 06:14:11PM +0200, Alexander Graf wrote:
> On 07/13/2016 05:59 PM, Ard Biesheuvel wrote:
> >On 13 July 2016 at 17:42, Alexander Graf <agraf@suse.de> wrote:
> >>Some user space applications are known to break with 48 bits virtual
> >known by whom? At least I wasn't aware of it, so could you please
> >share some examples?
>
> Sure! Known to me so far are:
>
> * mozjs17
> * mozjs24
> * mozjs38
> * js-1.8.5
> * java-1.7 (older JITs, fixed in newer ones)
>
> I'm not sure if there are more, but the fact that I've run into this
> problem more than once doesn't make me incredibly happy :).
>
I came across this too: on bootup via polkitd (which pulled in mozJS) :-(.
> >
> >>address space. As interim step until the world is healed and everyone
> >>embraces correct code, this patch allows to only expose 47 bits of
> >>virtual address space to user space.
> >>
> >Is this a code generation/toolchain issue?
>
> mozjs uses a single 64bit value to combine doubles, ints and
> pointers into a single variable. It is very smart and uses the upper
> 17 bits for metadata such as "which type of variable is this".
> Coincidentally those bits happen to overlap the "double is an
> infinite number" bits, so that you can also express a NaN with it.
> When using such a value, the upper 17 bits get masked out.
>
> That one was fixed upstream by force allocating the javascript heap
> starting at a fixed location which is below 47 bits.
>
> js-1.8.5 has the same as above, but also uses pointers to .rodata as
> javascript pointers, so it doesn't only use the heap, it also uses
> pointers to the library itself, which gets mapped high up the
> address space. I don't have a solution for that one yet.
Is this Spidermonkey 1.8.5? I wasn't aware of this issue.
>
> IcedTea for java-1.7 had a bug where it incorrectly caused an
> overflow when trying to calculating a relative adrp offset from
> <address high up> to <address really low>, so that the resulting
> pointer had the upper bits set as 1s. That one is long fixed
> upstream, we only ran into it because we used an ancient IcedTea
> snapshot.
I would recommend updating the sources used for OpenJDK anyway as there
have been a few other stability and performance fixes put in over the
last year to my knowledge.
>
> My main concern however is with code that I do not know is broken today.
>
I think if we set the 47-bit VA we are just ignoring the fundamental
problem and even allowing the problem to get worse (as future code may
adopt unsafe pointer tagging); thus I agree with Mark Rutland's NAK.
Personally, I would only ever tag bits in the VA space that I control
(i.e. at the bottom of the pointer if I enforce alignment).
Cheers,
--
Steve
next prev parent reply other threads:[~2016-07-14 1:08 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-13 15:42 [PATCH] arm64: Add config to limit user space to 47bits Alexander Graf
2016-07-13 15:59 ` Ard Biesheuvel
2016-07-13 16:14 ` Alexander Graf
2016-07-14 1:08 ` Steve Capper [this message]
2016-07-14 6:38 ` Alexander Graf
2016-07-14 7:03 ` Zheng Xu
2016-07-14 7:14 ` Alexander Graf
2016-07-14 7:49 ` Zheng Xu
2016-07-14 8:01 ` Alexander Graf
2016-07-14 18:07 ` Jeremy Linton
2016-07-14 15:17 ` Ard Biesheuvel
2016-07-13 16:10 ` Mark Rutland
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=20160714010812.GA17138@e103986-lin \
--to=steve.capper@arm.com \
--cc=Stuart.Monteith@arm.com \
--cc=Zheng.Xu@arm.com \
--cc=agraf@suse.de \
--cc=ard.biesheuvel@linaro.org \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mbrugger@suse.com \
--cc=will.deacon@arm.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).