linux-kernel - RE: [PATCH] arm64: Add config to limit user space to 47bits

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 14 Jul 2016 07:03:54 +0000
From:	Zheng Xu <Zheng.Xu@....com>
To:	"agraf@...e.de" <agraf@...e.de>,
	Steve Capper <Steve.Capper@....com>
CC:	Ard Biesheuvel <ard.biesheuvel@...aro.org>,
	Mark Rutland <Mark.Rutland@....com>,
	"mbrugger@...e.com" <mbrugger@...e.com>,
	"Catalin Marinas" <Catalin.Marinas@....com>,
	Will Deacon <Will.Deacon@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Stuart Monteith <Stuart.Monteith@....com>
Subject: RE: [PATCH] arm64: Add config to limit user space to 47bits

LuaJIT also fix the 48VA issue by allocating heap memory below 47 bits.

For mozjs issue, if there are pointers to .rodata, it can be a problem. Does it happen on master and do we have any case to reproduce the issue so that I can take a look?

Thanks,
Zheng

-----Original Message-----
From: Alexander Graf [mailto:agraf@...e.de]
Sent: 14 July 2016 14:39
To: Steve Capper
Cc: Ard Biesheuvel; Mark Rutland; mbrugger@...e.com; Catalin Marinas; Will Deacon; linux-kernel@...r.kernel.org; linux-arm-kernel@...ts.infradead.org; Stuart Monteith; Zheng Xu
Subject: Re: [PATCH] arm64: Add config to limit user space to 47bits


> On 14 Jul 2016, at 03:08, Steve Capper <steve.capper@....com> wrote:
>
> 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@...e.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) :-(.

Yup, that’s where I stumbled over it first. Gnome uses mozjs too, as do Firefox and Thunderbird obviously.

>
>>>
>>>> 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.

Exactly. If you’re interested in fixing it, be my guest :).

>
>>
>> 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.

Sure, that’s what we’ve done of course. I mostly mentioned it to answer the question where I had seen problems with 48 bits VA.

>
>>
>> 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.

Yeah, I’m torn on that one. I agree that we do allow broken code to work. However, going above 47 bits means we’re different from x86_64. And that *may* be a compatibility problem. Unfortunately we won’t know until at least a few hundred ISVs started to port their crufty user space code to ARM and things fell apart from time to time ;).

> 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).

Don’t blame the messenger :). For code that I write I tend to agree, but we’re talking about software that is a core dependency of other code (CouchDB uses Spidermonkey, polkit uses mozjs, etc) and that has been unmaintained for almost a decade by now, written in times when 47 bits of VA was more than the contents of the whole internet ;).


Alex

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.