Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > memmove: works on C's abstraction layer? or no?

Reply
Thread Tools

memmove: works on C's abstraction layer? or no?

 
 
Kobu
Guest
Posts: n/a
 
      07-22-2006

Hi,

The addresses seens in C's "layer" aren't necessarily the same as the
actual physical addresses in computer core (in fact, this is almost
always true for big OSes because of memory management).

So does this also mean that a certain number of contiguous bytes of
memory in C's layer (say, an array of chars or ints) is not necessarily
adjacent/contiguous bytes in core (but it probably is in big OSes)?

If the above is correct (not necessarily the same), then is memmove
guaranteed to make up for the differences? Say I have a char[40] array
in a program in any hosted C compiler in the world, and I memove the 40
bytes in the array to some other buffer in my program. Is it
guaranteed to be contiguous (at C's level) and in the same order?

Thanks..

 
Reply With Quote
 
 
 
 
Tom St Denis
Guest
Posts: n/a
 
      07-22-2006

Kobu wrote:
> Hi,
>
> The addresses seens in C's "layer" aren't necessarily the same as the
> actual physical addresses in computer core (in fact, this is almost
> always true for big OSes because of memory management).
>
> So does this also mean that a certain number of contiguous bytes of
> memory in C's layer (say, an array of chars or ints) is not necessarily
> adjacent/contiguous bytes in core (but it probably is in big OSes)?
>
> If the above is correct (not necessarily the same), then is memmove
> guaranteed to make up for the differences? Say I have a char[40] array
> in a program in any hosted C compiler in the world, and I memove the 40
> bytes in the array to some other buffer in my program. Is it
> guaranteed to be contiguous (at C's level) and in the same order?


memmove() is a userspace C library function, it only "knows about" your
processes virtual memory. So no, it doesn't matter if your physical
memory is contiguous. That's the point of virtual memory [well among
other goals].

Tom

 
Reply With Quote
 
 
 
 
Richard Heathfield
Guest
Posts: n/a
 
      07-22-2006
Kobu said:

>
> Hi,
>
> The addresses seens in C's "layer" aren't necessarily the same as the
> actual physical addresses in computer core (in fact, this is almost
> always true for big OSes because of memory management).
>
> So does this also mean that a certain number of contiguous bytes of
> memory in C's layer (say, an array of chars or ints) is not necessarily
> adjacent/contiguous bytes in core (but it probably is in big OSes)?


Arrays use contiguous storage, as far as C is concerned. If the
implementation wants to play games with that, I suppose it can, provided
the "as-if" rule is followed.

> If the above is correct (not necessarily the same), then is memmove
> guaranteed to make up for the differences?


Yes.

> Say I have a char[40] array
> in a program in any hosted C compiler in the world, and I memove the 40
> bytes in the array to some other buffer in my program. Is it
> guaranteed to be contiguous (at C's level) and in the same order?


Yes, provided that both the source and destination are legitimate.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
 
Reply With Quote
 
Gordon Burditt
Guest
Posts: n/a
 
      07-22-2006
>The addresses seens in C's "layer" aren't necessarily the same as the
>actual physical addresses in computer core (in fact, this is almost
>always true for big OSes because of memory management).


If the machine has virtual addresses and C is operating at the
user-program level where programs use virtual addresses, then C
operates on virtual addresses. A good virtual-memory system does
not require you to know, or even PERMIT you to know, physical
addresses (and they can change at any time).

>So does this also mean that a certain number of contiguous bytes of
>memory in C's layer (say, an array of chars or ints) is not necessarily
>adjacent/contiguous bytes in core (but it probably is in big OSes)?


There is no guarantee that all of an array even exists in physical
memory simultaneously, so the issue of its being contiguous doesn't
even apply. Also, it can change at any time. There might be only
one page of physical memory maximum at any one time for this program.
(performance will suck horribly, but that's a quality-of-implementation
issue).

>If the above is correct (not necessarily the same), then is memmove
>guaranteed to make up for the differences? Say I have a char[40] array
>in a program in any hosted C compiler in the world, and I memove the 40
>bytes in the array to some other buffer in my program. Is it
>guaranteed to be contiguous (at C's level) and in the same order?


C (including the C library) operates on virtual addresses. A
well-designed virtual memory system does not permit you to find out
if the array is physically contiguous (although if it fits in a
single page and you know the virtual memory page size, you can make
a good guess.

Gordon L. Burditt
 
Reply With Quote
 
Tom St Denis
Guest
Posts: n/a
 
      07-22-2006

Gordon Burditt wrote:
> >The addresses seens in C's "layer" aren't necessarily the same as the
> >actual physical addresses in computer core (in fact, this is almost
> >always true for big OSes because of memory management).

>
> If the machine has virtual addresses and C is operating at the
> user-program level where programs use virtual addresses, then C
> operates on virtual addresses. A good virtual-memory system does
> not require you to know, or even PERMIT you to know, physical
> addresses (and they can change at any time).


<snip>

I agree with the bulk of what you're saying. Though I disagree with
the notion that knowing physical addresses is taboo. You can't use
them even if you did know them. That's the point of paging and
segmentation.

Tom

 
Reply With Quote
 
Gordon Burditt
Guest
Posts: n/a
 
      07-22-2006
>> >The addresses seens in C's "layer" aren't necessarily the same as the
>> >actual physical addresses in computer core (in fact, this is almost
>> >always true for big OSes because of memory management).

>>
>> If the machine has virtual addresses and C is operating at the
>> user-program level where programs use virtual addresses, then C
>> operates on virtual addresses. A good virtual-memory system does
>> not require you to know, or even PERMIT you to know, physical
>> addresses (and they can change at any time).

>
><snip>
>
>I agree with the bulk of what you're saying. Though I disagree with
>the notion that knowing physical addresses is taboo.


>You can't use
>them even if you did know them.


If you know them, you can (mis)use them, and this generates bug
reports and tech support calls for a problem that likely doesn't
happen 99% of the time and is very difficult to consistently
reproduce. That's what makes it taboo to get physical addresses.

>That's the point of paging and
>segmentation.


Gordon L. Burditt
 
Reply With Quote
 
Tom St Denis
Guest
Posts: n/a
 
      07-22-2006
Gordon Burditt wrote:
> If you know them, you can (mis)use them, and this generates bug


How do you use physical addresses?

You can move data there, you can't issue DMA or other commands, etc.

Hint: if you wanted to attack or snoop would you need to know the
address of your victim process? You could easily snoop the entire
physical space. So even if you didn't tell me the physical address of
your process memory pages it wouldn't matter.

So either you're insecure anyways, or it doesn't matter.

Tom

 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      07-22-2006


Kobu wrote On 07/22/06 14:57,:
> Hi,
>
> The addresses seens in C's "layer" aren't necessarily the same as the
> actual physical addresses in computer core (in fact, this is almost
> always true for big OSes because of memory management).


True.

> So does this also mean that a certain number of contiguous bytes of
> memory in C's layer (say, an array of chars or ints) is not necessarily
> adjacent/contiguous bytes in core (but it probably is in big OSes)?


Yes, I think. (My only doubt is about what, exactly,
you mean by "contiguous bytes in core." Whatever your
definition of contiguity, it is unlikely to be preserved
when one takes into account a memory management unit, the
presence of various levels of physical and virtual cache,
and the interesting fact that few if any machines nowadays
contain any core memory at all.)

> If the above is correct (not necessarily the same), then is memmove
> guaranteed to make up for the differences? Say I have a char[40] array
> in a program in any hosted C compiler in the world, and I memove the 40
> bytes in the array to some other buffer in my program. Is it
> guaranteed to be contiguous (at C's level) and in the same order?


C operates at the level of the abstract machine as
described in the Standard, and its notions of adjacency,
of contiguity, and even of "address" pertain to that level.
If a machine's implementation embodies additional, deeper
levels, the C language is oblivious to them. It is the job
of the implementation to "make it work," somehow.

Thought question: If the first four characters of your
array reside in DIMM0, the next sixteen in DIMM1, and the
remaining twenty on the swap disk, is the array contiguous?

--
http://www.velocityreviews.com/forums/(E-Mail Removed)

 
Reply With Quote
 
Gordon Burditt
Guest
Posts: n/a
 
      07-22-2006
>> If you know them, you can (mis)use them, and this generates bug
>
>How do you use physical addresses?


You can use physical addresses as a poor substitute for the output
of rand(), except the output of rand() is repeatable with a given
seed, and physical addresses aren't.

You can use physical addresses (assuming the existence of a
virtual-to-physical-address translator function) to check if a large
array is physically contiguous, and call abort() if so. The few
occasions this triggers will be a problematic source of bug reports.

>You can move data there,


I know of no function that can move data to a physical address (or
read data from a physical address) without requiring privileges on
a virtual-memory system. Even if it's YOUR process! And I don't
know of any standardized method of doing this regardless of privileges.

>you can't issue DMA or other commands, etc.
>
>Hint: if you wanted to attack or snoop would you need to know the
>address of your victim process? You could easily snoop the entire
>physical space. So even if you didn't tell me the physical address of
>your process memory pages it wouldn't matter.


You're assuming the existence of a read-by-physical-address function.
I don't know of any such function that does not require privileges
to use on any OS with virtual memory.

>So either you're insecure anyways, or it doesn't matter.


If you permit an unprivileged read-data-by-physical-address, you're
insecure. If you permit an unprivileged
virtual-address-to-physical-address translator function (with *NO*
ability to access by physical address), there is nothing useful you
can use the info for (it is of extremely limited use for snooping),
but anything the info is used for is going to cause trouble.

Gordon L. Burditt
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      07-22-2006
"Tom St Denis" <(E-Mail Removed)> writes:
> Gordon Burditt wrote:
>> If you know them, you can (mis)use them, and this generates bug

>
> How do you use physical addresses?


If a system provided a way to obtain a physical address, presumably it
would provide a way to use it. I have no idea what that might look
like.

Or a buggy program could attempt to use a physical address as if it
were a virtual address.

Gordon: Stop snipping attributions.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Abstraction Layers And Their Importance Silverstrand Front Page News 0 01-31-2006 04:48 AM
When I turn on my PC, it works, works, works. Problem! Fogar Computer Information 1 01-17-2006 12:57 AM
HDL Abstraction of Dynamic Logic Alex VHDL 2 09-18-2005 04:00 PM
SqlConnections, abstraction etc Ben ASP .Net 4 06-24-2004 05:46 PM
After rebooting my PC works, works, works! Antivirus problem? Adriano Computer Information 1 12-15-2003 05:30 AM



Advertisments