Bug#873778: mozjs52 on s390x and other big-endian machines

[Emilio Pozuelo Monfort]

On 12/10/17 01:16, Simon McVittie wrote:
> On Mon, 09 Oct 2017 at 10:36:52 +0100, Simon McVittie wrote:
>> On Sun, 01 Oct 2017 at 23:36:52 +0200, Michael Biebl wrote:
> The remaining problem seems to be a big-endian issue (mips, s390x, 
> hppa, powerpc, sparc64). ppc64 fails in a slightly different
> manner, might just be it's failing earlier for a different reason
> but would also suffer from this bug.
>>
>> Here is some work-in-progress on this:
>>
>> https://anonscm.debian.org/git/users/smcv/mozjs52.git
>>
>> I've made it regenerate the data file on both endiannesses in the hope
>> that this will make us more likely to catch errors. The generated file
>> on little-endian is not the same as the pregenerated one :-(
>>
>> This is only build-tested on x86_64 at this point, not runtime-tested.
> 
> The unit tests all pass or are skipped on x86_64 (on barriere).
> 
> On s390x (zelenka), I now see meaningful test results, with the unexpected
> failures listed below. So something is wrong on s390x in at least a
> few cases, but it's basically a functional JavaScript interpreter,
> and a lot of the tests pass. That seems a lot better than the current
> situation. Good enough for experimental, at least?

Agreed. I'd say let's get this uploaded, and then if we can't fix the test suite
even further, disable it (it was already disabled on older mozjs and on firefox
as you pointed out so no regression here...) and call for help to interested
parties.

Thanks!
Emilio

Bug#873778: mozjs52 on s390x and other big-endian machines

[Simon McVittie]

On Mon, 09 Oct 2017 at 10:36:52 +0100, Simon McVittie wrote:
> On Sun, 01 Oct 2017 at 23:36:52 +0200, Michael Biebl wrote:
> > >> The remaining problem seems to be a big-endian issue (mips, s390x, 
> > >> hppa, powerpc, sparc64). ppc64 fails in a slightly different
> > >> manner, might just be it's failing earlier for a different reason
> > >> but would also suffer from this bug.
> 
> Here is some work-in-progress on this:
> 
> https://anonscm.debian.org/git/users/smcv/mozjs52.git
> 
> I've made it regenerate the data file on both endiannesses in the hope
> that this will make us more likely to catch errors. The generated file
> on little-endian is not the same as the pregenerated one :-(
> 
> This is only build-tested on x86_64 at this point, not runtime-tested.

The unit tests all pass or are skipped on x86_64 (on barriere).

On s390x (zelenka), I now see meaningful test results, with the unexpected
failures listed below. So something is wrong on s390x in at least a
few cases, but it's basically a functional JavaScript interpreter,
and a lot of the tests pass. That seems a lot better than the current
situation. Good enough for experimental, at least?

---8<

## ecma_6/TypedArray/Tconstructor-fromTypedArray-byteLength.js: rc = 3, run 
time = 0.025008
ecma_6/TypedArray/Tconstructor-fromTypedArray-byteLength.js:8:9 Error: 
Assertion failed: got 3, expected 0
Stack:
  @ecma_6/TypedArray/Tconstructor-fromTypedArray-byteLength.js:8:9
TEST-UNEXPECTED-FAIL | 
ecma_6/TypedArray/Tconstructor-fromTypedArray-byteLength.js | (args: "")

## ecma_6/TypedArray/set-same-buffer-different-source-target-types.js: rc = 3, 
run time = 0.022477
896116: When setting a typed array from an overlapping typed array of different 
element type, copy the source elements into properly-sized temporary memory, 
and properly copy them into the target without overflow (of either source *or* 
target) when finished
ecma_6/TypedArray/set-same-buffer-different-source-target-types.js:27:11 
RangeError: attempting to construct out-of-bounds TypedArray on ArrayBuffer
Stack:
  @ecma_6/TypedArray/set-same-buffer-different-source-target-types.js:27:11
TEST-UNEXPECTED-FAIL | 
ecma_6/TypedArray/set-same-buffer-different-source-target-types.js | (args: "")

## ecma_6/TypedArray/subarray.js: rc = 3, run time = 0.021673
ecma_6/TypedArray/subarray.js:8:26 RangeError: attempting to construct 
out-of-bounds TypedArray on ArrayBuffer
Stack:
  @ecma_6/TypedArray/subarray.js:8:26
TEST-UNEXPECTED-FAIL | ecma_6/TypedArray/subarray.js | (args: "")

## ecma_6/TypedArray/indexOf-and-lastIndexOf.js: rc = 3, run time = 0.023659
ecma_6/TypedArray/indexOf-and-lastIndexOf.js:53:9 Error: Assertion failed: got 
0, expected 8
Stack:
  @ecma_6/TypedArray/indexOf-and-lastIndexOf.js:53:9
TEST-UNEXPECTED-FAIL | ecma_6/TypedArray/indexOf-and-lastIndexOf.js | (args: "")

## ecma_6/TypedArray/sort_snans.js: rc = 3, run time = 0.055719
ecma_6/shell.js:93:23 Error: Assertion failed: got -1.8938930325389462e+304, 
expected NaN at _[0]
Stack:
  assertSameValue@ecma_6/shell.js:93:23
  check@ecma_6/shell.js:198:21
  assertSameProps@ecma_6/shell.js:162:25
  check@ecma_6/shell.js:213:25
  assertDeepEq@ecma_6/shell.js:221:13
  testFloat64NaNRanges@ecma_6/TypedArray/sort_snans.js:60:5
  @ecma_6/TypedArray/sort_snans.js:68:1
TEST-UNEXPECTED-FAIL | ecma_6/TypedArray/sort_snans.js | (args: "")

## ecma_6/ArrayBuffer/CloneArrayBuffer.js: rc = 3, run time = 0.021813
1264941: CloneArrayBuffer should be called with byteLength of source typedArray
ecma_6/ArrayBuffer/CloneArrayBuffer.js:16:7 Error: Assertion failed: got 8, 
expected 0
Stack:
  test@ecma_6/ArrayBuffer/CloneArrayBuffer.js:16:7
  @ecma_6/ArrayBuffer/CloneArrayBuffer.js:27:1
TEST-UNEXPECTED-FAIL | ecma_6/ArrayBuffer/CloneArrayBuffer.js | (args: "")

## js1_8_5/extensions/clone-transferables.js: rc = 3, run time = 0.022512
js1_8_5/extensions/clone-transferables.js:42:17 Error: Assertion failed: got 0, 
expected NaN
Stack:
  test@js1_8_5/extensions/clone-transferables.js:42:17
  @js1_8_5/extensions/clone-transferables.js:111:1
TEST-UNEXPECTED-FAIL | js1_8_5/extensions/clone-transferables.js | (args: "")

## js1_8_5/extensions/clone-many-transferables.js: rc = -11, run time = 0.783352
 PASSED! ok
TEST-UNEXPECTED-FAIL | js1_8_5/extensions/clone-many-transferables.js | (args: 
"")
## js1_8_5/extensions/clone-errors.js: rc = -11, run time = 0.03348
 PASSED! ok
TEST-UNEXPECTED-FAIL | js1_8_5/extensions/clone-errors.js | (args: "")

## js1_8_5/extensions/typedarray.js: rc = 0, run time = 0.167332
BUGNUMBER: 532774
STATUS: js typed arrays (webgl arrays)
=== FAILED ===
check@js1_8_5/extensions/typedarray.js:62:22
test@js1_8_5/extensions/typedarray.js:488:5
@js1_8_5/extensions/typedarray.js:17:1

==
=== FAILED ===
check@js1_8_5/extensions/typedarray.js:62:22
test@js1_8_5/extensions/typedarray.js:489:5
@js1_8_5/extensions/typedarray.js:17:1

==
=== FAILED ===
check@js1_8_5/extensions/typedarray.js:62:22

Bug#873778: mozjs52 on s390x and other big-endian machines

[Simon McVittie]

On Sun, 01 Oct 2017 at 23:36:52 +0200, Michael Biebl wrote:
> >> The remaining problem seems to be a big-endian issue (mips, s390x, 
> >> hppa, powerpc, sparc64). ppc64 fails in a slightly different
> >> manner, might just be it's failing earlier for a different reason
> >> but would also suffer from this bug.

Here is some work-in-progress on this:

https://anonscm.debian.org/git/users/smcv/mozjs52.git

I've made it regenerate the data file on both endiannesses in the hope
that this will make us more likely to catch errors. The generated file
on little-endian is not the same as the pregenerated one :-(

This is only build-tested on x86_64 at this point, not runtime-tested.

I'm a little concerned that when mips(el) are dropped from Debian in
favour of mips64el (which I believe is the mips porters' long term plan?),
s390x will be the only big-endian release architecture, which doesn't
seem particularly sustainable - few DDs understand that architecture,
and given its category of hardware, probably none will ever own one.

> > [17:18:15]  a local js engine does not have the same attach vector 
> > as a browser
> > [17:18:52]  So passing untrusted contents to mozjs will be a CVE in 
> > GNOME?

GNOME applications that want a web engine capable of interpreting normal
HTML/CSS/JS from the Internet use WebKit, not mozjs52.

The major user of mozjs52 is gjs. Passing untrusted JavaScript to gjs
would definitely be CVE-worthy, regardless of mozjs' code quality, because
gjs has full user privileges and can call arbitrary GObject-Introspection
APIs: passing untrusted JavaScript to it would be equivalent to passing
untrusted Python, Perl, Ruby or shell script to their respective
interpreters. gjs is used by GNOME Shell (and its extensions), GNOME
Sushi and Polari, which are all trusted apps that happen to be partially
or entirely written in JS: JS as programming language, rather than JS
as web content.

polkit (PolicyKit) in experimental currently uses mozjs 1.8.5, but should
eventually move to mozjs52. Again, this is entirely trusted: the ability
to install polkit rules is equivalent to the ability to install sudoers.d
fragments, and it would already be a serious security vulnerability if
a non-root-equivalent user could edit or install those rules.

libproxy has a plugin to interpret PAC (proxy auto-config) using mozjs,
currently mozjs 1.8.5. This is at a security boundary, so it might well
be relying on mozjs to be able to interpret untrusted JS safely; but
mozjs52 presumably can't be any worse than mozjs 1.8.5 in that respect?

gxine, mediatomb and oolite also use mozjs 1.8.5 and should probably
move to a newer version eventually. I don't know what they use it for,
but again, mozjs52 surely can't be any worse than mozjs 1.8.5...

smcv