[Bug ld/12376] File offsets for PT_LOAD segments and resulting inequivalent memory aliases

[dave at hiauly1 dot hia.nrc.ca]

http://sourceware.org/bugzilla/show_bug.cgi?id=12376

--- Comment #5 from dave at hiauly1 dot hia.nrc.ca <dave at hiauly1 dot 
hia.nrc.ca> 2011-02-14 03:40:21 UTC ---
On Mon, 14 Feb 2011, amodra at gmail dot com wrote:

> > These in fact point to the same page in physical memory.
> 
> Really?  00010000-00011000 and 00011000-00012000 are not different pages?

They map to the same page as far as I can tell (both maps appear in the
list iterated using vma_prio_tree_foreach(mpnt, &iter, &mapping->i_mmap,
pgoff, pgoff)).  This can also be seen by looking at /proc/$PID/maps.
When multiple shared writeable mappings exist, I believed they are COWed.
So, effectively only one map is writeable.

Non equivalent aliases are a problem for architectures such as PA8800/PA8900.
They don't support non equivalent aliases in the sense that a write doesn't
invalidate non equivalent aliases.  The only thing that saves us is the
former address range is write protected, and it's rare to try to read using
the text map.  It seems possible that the text map could be corrupted
via the data map.  So, this might be a security issue.

The V-Class machines are even worse than PA8800/PA8900 because they don't
support non equivalent aliases regardless of whether they are read-only
or not.

These non equivalent aliases occur typically on the boundary page between
text and data.  The linux dynamic loader mmaps these regions as MAP_FIXED.
They are not mapped with MAP_SHARED but it seems the maps are shared
for shared libraries.  So far, it seems the hppa linux dynamic loader
always maps shared pages with equivalent aliases except for the boundary
page.

I think this is potentially an issue for certain MIPS and ARM cpus but
I don't know the details on whether they support non equivalent aliases
or not.  As far as I can tell, the same occurs for x86, etc, but I don't
think the non equivalent aliases matter, at least on linux.  On the
other hand, it looks like windows starts sections on page boundaries.

Probably, it would be best if load segments were aranged in executables
to optionally start on a file page boundary.  This would avoid the double
flush and having two non equivalent address ranges map to the same page.
Don't really want to start all sections on a page boundary as this would
waste a lot of file space.

I have looked a bit at trying to do this, but don't have a solution at
the moment.

Dave

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.