[Webkit-unassigned] [Bug 214142] New: [WTF] Fix PackedAlignedPtr for X86_64 canonical addresses
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Thu Jul 9 08:58:43 PDT 2020
https://bugs.webkit.org/show_bug.cgi?id=214142
Bug ID: 214142
Summary: [WTF] Fix PackedAlignedPtr for X86_64 canonical
addresses
Product: WebKit
Version: WebKit Nightly Build
Hardware: Unspecified
OS: Unspecified
Status: NEW
Severity: Normal
Priority: P2
Component: Web Template Framework
Assignee: webkit-unassigned at lists.webkit.org
Reporter: jmason at ibinx.com
PackedAlignedPtr assumes the effective address width is <= 48 bits in 64-bit architectures. This facilitates NaN boxing with the remaining bits. (ref: wtf/PlatformOS.h)
This is fine for x86_64, as it has a 48-bit address space. However, PackedAlignedPtr incorrectly assumes the 'hole' in the address space is at the high-end (i.e., that the most significant 16 bits are always zero). For x86_64, the high order bits may be zero or one: "The AMD specification requires that the most significant 16 bits of any virtual address, bits 48 through 63, must be copies of bit 47 (in a manner akin to sign extension)." Reference: https://en.wikipedia.org/wiki/X86-64#Virtual_address_space_details
The patch to wtf/Packed.h fixes the getter of PackedAlignedPtr to reconstitute the canonical address by 'sign-extending' bit 47 (which we already store) across the most significant 16-bits:
#if CPU(X86_64)
if(value & 0x1ULL << 47)
value |= 0xffffULL << 48;
#endif
In this way, both the getter and setter of PackedAlignedPtr will work correctly for all X86_64 canonical addresses: The setter continues to discard the upper 16 bits and store only the lower 48 bits, while the getter now reconstitutes the upper 16 bits at retrieval time.
The patch to wasm/js/WebAssemblyFunction.cpp is a related fix for an address pointer test: Currently, the test uses a signed value (intptr_t) for the comparison. If the high order bit is set, this number is negative, which makes the test fail. The fix changes intptr_t to uintptr_t so the test will work as expected for all addresses.
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200709/5307904e/attachment-0001.htm>
More information about the webkit-unassigned
mailing list