Hi Igor, On Jan 20 10:33, Igor Podgainoi wrote: > Hello! > > I am a developer at Arm working on improving Cygwin compatibility on > the AArch64 architecture. I will soon be posting a series of bugfix > patches that allow additional unit tests to pass. Some (but not all) of > these patches are based on earlier work posted by Thirumalai Nagalingam, > itself authored by multiple contributors. > > One of my patches is related to changing the memory layout that is > described in the file winsup/cygwin/local_includes/memory_layout.h, > and I am writing to ask for feedback on this change. > > * Background/observed issue > --------------------------- > > Currently, the range from 0x800000000 to 0xa00000000 is reserved for > the cygheap. However, on Windows on Arm (AArch64), where mandatory > userspace ASLR is enforced, I have observed this region occasionally > being occupied by the PEB, TEB, and stack.
Question here is: Is just ASLR enforced or High Entropy ASLR? If the first, we have to make sure to compile all Cygwin binaries as non-HEVA. If the latter, we have a really hard fork() problem which can't be fixed by your patch... > [...] > * Proposed change > ----------------- > > My proposal is to shift cygheap, user heap and mmap_storage to > the end of the largest FREE block of memory. > [...] > + 1`0041e000 7ff4`fdec0000 7ff3`fdaa2000 MEM_FREE > PAGE_NOACCESS Free > [...] > * Questions > ----------- > > I have not been able to find any authoritative documentation that > would describe the exact mapping of these ranges whether on x86_64 > or AArch64, on Microsoft's website or elsewhere. Leaving HEVA aside, the usual memory usage of the OS on x86_64 is so that the OS is basically using the lower 2 Gigs (stacks, heaps) and the upper N Gigs for PEB, TEBs and DLLs. That leaves the huge middle of the VM free for the application. The memory layout of Cygwin tries to accomodate that by starting at the second 4 Gigs block with the executable image (EXECUTABLE_ADDRESS), and ending at a reasonable high address with memory maps allocated top-down (MMAP_STORAGE_HIGH). If you're observing PEB and TEB reservations in the area from 0x800000000 up to 0xa00000000 without HEVA, then that's IMHO a design flaw in the ARM64 memory allocator, which should be fixed by Microsoft. > I would therefore appreciate any guidance from the community on: > * whether this relocation has potential downsides I may be missing, > +#define CYGHEAP_STORAGE_LOW 0x0ff700000000UL > +#define CYGHEAP_STORAGE_INITIAL 0x0ff700300000UL > +#define CYGHEAP_STORAGE_HIGH 0x0ff900000000UL > [...] > +#define USERHEAP_START 0x0ff900000000UL > [...] > +#define MMAP_STORAGE_LOW 0x0fff00000000UL > +#define MMAP_STORAGE_HIGH 0x7fef00000000UL I'm a bit puzzeled that you're moving MMAP_STORAGE_HIGH up, from 0x700000000000UL. Granted, this may be somewhat over the top, but the general idea was to allow a lot of space left for ASLR'ed DLLs. Other than that, I don't see much of a problem. Your patch restricts the VM usable for heap and maps to a mere 112 TB, which is, of course, worrisome /*grin*/ > * whether there are known constraints on placing cygheap/user heap > in this region, I'm not aware of any. > * or whether there is a more appropriate approach to handling this > under mandatory ASLR. It all depends on the fact if HEVA is mandatory, or just ASLR with default characteristics. For normal ASLR we can redefine the memory layout as we see fit. The DLL areas REBASED_DLL_STORAGE_LOW/ REBASED_DLL_STORAGE_HIGH and AUTOBASED_DLL_STORAGE_LOW/ AUTOBASED_DLL_STORAGE_HIGH will be basically unused because all DLLs will be ASLR'ed anyway. IMHO more reason to stick to the current MMAP_STORAGE_HIGH, but that's a point of discussion. > With regard to shared-memory interactions, my understanding is that > this change should not introduce new issues. The Cygwin FAQ already > notes that mixing executables from different Cygwin installations is > not a supported configuration > (https://cygwin.com/faq.html#faq.using.multiple-copies), and the > proposed change does not alter that assumption. Indeed. Thanks, Corinna > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential [etc] Tell your employer to drop these disclaimers for postings to public mailing lists. They just don't make any sense.
