<br /><br /><span>Am 13.03.21 19:09 schrieb <b class="name">Alan Coopersmith </b> <alan.coopersmith@oracle.com>:</span><blockquote cite="mid:536c572c-810b-bf72-b033-3f1c06c5710c@oracle.com" class="iwcQuote" style="border-left: 1px solid #00F; padding-left: 13px; margin-left: 0;" type="cite"><div class="mimetype-text-plain">On 3/12/21 11:58 PM, Carsten Grzemba via oi-dev wrote:<br />>It seems that this are raised by MOZ_ASSERTION because the JS-engine (spidermonkey) expects that  addresses for JS Values are not in the upper memory area:<br />><br />>ptr must be a valid user-mode pointer, with the top 16 bits clear<br /><br />Yes - spidermonkey expects to be able to store its own data in the top bits of<br />the pointer, which has known issues on Solarish kernels:<br /><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=577056" target="l">https://bugzilla.mozilla.org/show_bug.cgi?id=577056</a><br /><br />You can read more about what spidermonkey is doing at:<br /><a href="https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Internals#javascript_values" target="l">https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Internals#javascript_values</a><br /><a href="https://doar-e.github.io/blog/2018/11/19/introduction-to-spidermonkey-exploitation/#jsvalues-and-jsobjects" target="l">https://doar-e.github.io/blog/2018/11/19/introduction-to-spidermonkey-exploitation/#jsvalues-and-jsobjects</a><br /><br />>In solaris-userland Oracle has placed a patch but only for Sparc: sparc-47bit-VA-space.patch<br />>This use a mapfile with<br />>RESERVE_SEGMENT spidermonkey_reserve {<br />>       VADDR = 0x800000000000;<br />>       SIZE = 0xffff7fffffff0000;<br />>};<br />>Illumos ld don't know the option RESERVE_SEGMENT, but it is for Sparc how I already stated.<br /><br />This is the second version of the mapfile we've used - the first was:<br />CAPABILITY {<br />        SF += ADDR32;<br />};<br />but that limits a 64-bit program to a 32-bit address space, and Firefox really<br />needs more than 4gb of address space these days, so we had to find a better<br />solution.<br /><br />Fortunately, we already had added RESERVE_SEGMENT to the mapfile syntax and<br />ELF program headers to block out a part of the address space, and ensure that<br />the system wouldn't map anything in that range, even if ASLR happened to<br />randomly pick an address there, so we used that instead:<br /><a href="https://blogs.oracle.com/solaris/virtual-address-reservation-in-solaris-113-v2" target="l">https://blogs.oracle.com/solaris/virtual-address-reservation-in-solaris-113-v2</a><br /><a href="https://docs.oracle.com/cd/E37838_01/html/E36783/gjpky.html#OSLLGgjpte" target="l">https://docs.oracle.com/cd/E37838_01/html/E36783/gjpky.html#OSLLGgjpte</a><br /><br />>Do IllumOS use the whole 64bit address space and not only the expected 47bit? Or I am completly wrong here in the maze of physical and virtual address spaces?<br /><br />The address model is different than Linux - it's effectively just 47 bits, but<br />they're in different subsets of the 64-bit address space than Linux uses.<br /><br />To quote from one of the engineers who worked on this:<br />"On x86-64 they rely on the fact that Mac OS X, Windows and Linux all put the<br />userspace/kernelspace boundary at the VA hole. In Solaris, instead, we still<br />dynamically restrict it to some arbitrary (depending on amount of memory and<br />other factors) boundary line above the VA hole."<br />Another engineer just pointed to:<br /><a href="https://en.wikipedia.org/wiki/X86-64#Virtual_address_space_details" target="l">https://en.wikipedia.org/wiki/X86-64#Virtual_address_space_details</a><br /><br />This led to a workaround of putting this line in /etc/system:<br />set _userlimit=0x7fffc0000000<br />until the RESERVE_SEGMENT change was available.<br /><br />But then we also changed the x86 kernel in Solaris 11.4 to make that the default<br />userlimit on x86 systems, making us match the other OS'es and no longer need to<br />do anything special to deal with this on x86 systems, only SPARC.<br /><br />You can see this change in the address space layout diagrams for the AMD64 ABI<br />between the 11.3 & 11.4 docs:<br /><a href="https://docs.oracle.com/cd/E53394_01/html/E61689/fcowb.html#SSFDGfcpaf" target="l">https://docs.oracle.com/cd/E53394_01/html/E61689/fcowb.html#SSFDGfcpaf</a><br /><a href="https://docs.oracle.com/cd/E37838_01/html/E66175/fcowb.html#SSFDGfcpaf" target="l">https://docs.oracle.com/cd/E37838_01/html/E66175/fcowb.html#SSFDGfcpaf</a><br /><br />       -alan-<br /><br />------------------------------------------<br />illumos: illumos-developer<br />Permalink: <a href="https://illumos.topicbox.com/groups/developer/T85d63ca2deb8458a-M1425e543d5d14e98cf2884e7" target="l">https://illumos.topicbox.com/groups/developer/T85d63ca2deb8458a-M1425e543d5d14e98cf2884e7</a><br />Delivery options: <a href="https://illumos.topicbox.com/groups/developer/subscription" target="l">https://illumos.topicbox.com/groups/developer/subscription</a></div></blockquote><span>I can confirm that <br /></span><br /><span>set _userlimit=0x7fffc0000000<br /><br />works here, but is there an impact for the system or other applications with this system setting?<br /></span>-- <br signature="separator" />Carsten <br />