Edwin, 

Its definitely possible on the Windows side, so I assume it is also possible on Linux. For example on Windows where every process loads kernel32.dll and ntdll.dll, the library is broken down into sections (like .text for code, .rdata for read-only data, etc). Some sections can be shared between processes and is often done so with prototype PTEs. If one process needs to write inside one of these libraries, the change isn't propagated to all other processes that share the page. Instead, the writing process gets a write-copy page (a copy of the page that it can write to, independent of the originally shared one). Its definitely possible for that page to be swapped in one process but present in another process. 

Hope this helps,
MHL


On Thu, Jul 11, 2013 at 7:27 AM, Edwin Smulders <edwin.smulders@gmail.com> wrote:
I have a small follow-up question; Am I correct in my understanding
that a shared library can be (seemingly) swapped out for one process,
but not for another? For example, because the relevant PTE has not
been restored yet? I've read
https://www.kernel.org/doc/gorman/html/understand/understand014.html
but since it's written from a 'running system' point of view, it's not
quite clear to me yet.

Cheers,
Edwin

On 19 June 2013 17:06, Joe Sylve <joe.sylve@gmail.com> wrote:
> Edwin,
>
> If you read the intel manuals, swapping isn't actually terribly complicated.
> You could conceivably implement swapping functionality into volatility (of
> course you'd have to pass a swap file or partition as a parameter).  The
> problem that I for-see is that you might run into issues with smearing,
> since you're collecting memory from a running machine, but it might be worth
> the effort.
>
>
> On Wed, Jun 19, 2013 at 9:13 AM, Edwin Smulders <edwin.smulders@gmail.com>
> wrote:
>>
>> Ahh, that is really too bad, I was pretty sure I had enough memory,
>> but I suppose swapping might occur at any moment, even with a good
>> amount of free memory.
>> Thanks for your answer, it's yet another issue I can include in my thesis
>> :)
>>
>> On 19 June 2013 16:08, Michael Hale Ligh <michael.hale@gmail.com> wrote:
>> > Hi Edwin,
>> >
>> > This is the effect of swapping. When you dump a vma region to disk, we
>> > zero-pad pages that are swapped to retain the original size and offsets
>> > in
>> > the vma region. You can call proc_as.is_valid_address(0x7faf9d9b0e9b)
>> > and if
>> > its False then the page containing that address is in the pagefile. You
>> > can
>> > also use proc_as.zread() instead of read() which will automatically
>> > zero-pad
>> > pages that are not memory resident.
>> >
>> > MHL
>> >
>> >
>> > On Wed, Jun 19, 2013 at 9:15 AM, Edwin Smulders
>> > <edwin.smulders@gmail.com>
>> > wrote:
>> >>
>> >> Hi all,
>> >>
>> >> I am having a problem reading certain values in an address space. I
>> >> know for certain that the range I am trying to read is mapped, i.e.
>> >> there is a vma for it.
>> >>
>> >> The specific range in this case is shown in the vma list as this:
>> >>
>> >> 1206 0x00007faf9d98f000 0x00007faf9db4d000 r-x                   0x0
>> >>    8      1        241 /lib/x86_64-linux-gnu/libc-2.17.so
>> >>
>> >> The offset in this range that I am trying to read is 0x21e9b =
>> >> 0x7faf9d9b0e9b
>> >>
>> >> the call may look like this: proc_as.read(0x7faf9d9b0e9b, 10)
>> >> and it will return None, meaning it could not read that address.
>> >>
>> >> Using the linux_dump_map I exported the whole range and there's a
>> >> pretty big empty (inaccessible) chunk in the middle, which appears as
>> >> 0-bytes in the export. I know for a fact that my libc does not have a
>> >> big area of 0-bytes, so this is pretty weird. It also works just fine
>> >> for other processes in the same dump (so using the same libc).
>> >>
>> >> For research purposes I make my memory dumps with virtualbox, so I
>> >> don't think it's an issue with memory corruption; as far as i can
>> >> tell, virtualbox makes complete snapshots.
>> >>
>> >> Does anyone know what might cause this problem?
>> >>
>> >> Cheers,
>> >> Edwin
>> >> _______________________________________________
>> >> Vol-users mailing list
>> >> Vol-users@volatilityfoundation.org
>> >> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>> >
>> >
>> _______________________________________________
>> Vol-users mailing list
>> Vol-users@volatilesystems.com
>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>
>