[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Any correlation between malloc return value and physical location?

At 2003-10-13T08:01:55Z, Harald Gutsche <hg42@gmx.net> writes:

> generally, when using virtual memory, all programs have their own adress
> space, which means they all start at the same memory adresses for program,
> data, stack etc. So identical programs should run in identical virtual
> memory addresses.

That's what I was expecting from my classes on operating systems.  In fact,
we had to write a malloc() where each program's virtual allocations (that
is, the value that the program received from malloc()) began at 0x0, but the
physical address was completely different and mapped via the MMU.

> I never tried in reality, but...

I did before asking, but wanted an outside opinion.  Here's my test program
that returns the same value every time:

    #include <stdlib.h>
    #include <stdio.h>

    int main()
            void *newmem = malloc(1024);
            printf("newmem address: %p\n", newmem);
            return 0;

A similar Python program is:

    $ python
    Python 2.3.2 (#2, Oct  6 2003, 08:02:06)
    [GCC 3.3.2 20030908 (Debian prerelease)] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> def foo():
    ...     pass
    >>> foo
    <function foo at 0x4020ff0c>

I liked that example because I could trivially test it in several shells at
the same time.

> Why do you want to know?

Well, I'm reading the sequel to "Applied Cryptography", namely "Practical
Cryptography".  It has a discussion on hardware information leaks, including
the case where RAM can begin to remember values stored in it for long
periods of time.  It mentioned several ways to work around this problem, but
some of them involved working with memory location's physical address.  I'm
not sure that I agree with the author on some of the details because I don't
believe a userspace program has access to that information (although kernel
module implementers should probably follow the advice).
Kirk Strauser
In Googlis non est, ergo non est.

Attachment: pgpswdSVg9jrL.pgp
Description: PGP signature

Reply to: