1

I have few below questions related to C program memory and how it is compared to Java memory management:

  1. In Java, when JVM process starts, then some memory (defined by Xms and Xmx) is allocated. How do we know that how much memory is allocated in case of C program, and can we control this program memory?
  2. In Java, heap memory need not to be contiguous. How it is in case of C?
  3. In lecture 3 of Monday, David sir showed how a program can access memory (argv[50], argv[500]) we should not be touching. My understanding is that this memory is nothing but the memory allocated by OS to the C program, and not the complete OS RAM? Right?
    If it is right then how a bad guy can access the passwords which may be in my program's memory, because to access those areas he would need the argv array, but then how we would have it because I am running the program?

Please let me know your inputs.

4
  1. In Java, when JVM process starts, then some memory (defined by Xms and Xmx) is allocated. How do we know that how much memory is allocated in case of C program, and can we control this program memory?

programs written in Java have memory automatically managed for them. the case is different in C. that is, you can simulate that manually by taking minimum and maximum heap sizes as command-line arguments and allocating the minimum heap size (using a function from the malloc family) as the program starts running and extend that during execution using realloc.

since you allocate memory manually, you can keep track of the amount of memory that was allocated and not allow your allocated memory to exceed the maximum heap size.

  1. In Java, heap memory need not to be contiguous. How it is in case of C?

it's not guaranteed that separate memory allocations will allocate contiguous blocks. memory allocated on/freed from the heap is done dynamically as the program is running.

memory that gets freed is available to use again. so you may allocate a chunk from address 100 to 103, another chunk from 104 to 107, and a third chunk from 108 to 111.

if the middle chunk is freed, it becomes available to use and it might get allocated next time you allocate 4 bytes instead of 112 to 115.

  1. My understanding is that this memory is nothing but the memory allocated by OS to the C program, and not the complete OS RAM? Right?

well, this memory may not be allocated for your program. unlike Java where you get an exception for trying to access an out-of-bounds array index, the behavior of such operation in C is undefined. you never know what you're gonna get. for example, you may get the value that lives in this location at the moment, your program may crash immediately, etc.

If it is right then how a bad guy can access the passwords which may be in my program's memory, because to access those areas he would need the argv array, but then how we would have it because I am running the program?

apparently you're referring to the problem of buffer overflow and you don't get the risk very well. here is the general idea with a fairly simple example:

let's say you allocated a piece of memory (a buffer) on the stack to take some input from the user and store it on that memory.

if you're not careful (i.e., ensuring the buffer is big enough to hold the data before you store it), the user may pass data until the buffer is filled and overflowed. meanwhile, whatever the user passes may keep getting stored in the contiguous blocks.

the are multiple chances for exploitation as a result of overflowing a buffer. for example, the hacker could be overwriting the value of some variable that would make the program behave in a way that would benefit the hacker.

the hacker could overwrite the return address of a function so that when the function returns, the presumably malicious code in the return address he/she specified will execute.

| improve this answer | |
  • Thank you for your inputs. Below are few follow up question. #2: So, let say while running the program, we specify to allocate memory 100 MB of memory. When the OS will allocate this memory then it need not to necessarily be from 000000 to C80000, but could be any memory location between 00000000 to FFFFFFFF? #3.a: I mean that only some part of memory is given to the C program, and only that much can be accessed by code using argv[n], and not the complete RAM available with OS, right? – hagrawal Jul 8 '15 at 14:06
  • #3.b: No, I mean even without buffer overflow, some bad guy can access memory which should not be accessible. This is what was said in 3rd lecture of Monday. I couldn't understand how? You said "whatever the user passes may keep getting stored in the contiguous blocks." you mean contiguous blocks of memory allocated to C program or outside C program memory. If it is C program memory then whether overflow or not, if what you described it true, then C program memory id vulnerable to pokes. No? – hagrawal Jul 8 '15 at 14:09
  • @hagrawal yes, if you're allocating a block of memory on the heap, it could be, as a whole, anywhere in the available memory for the heap. so if you're allocating 8 bytes as one block, it could be anywhere on the heap. but if you're allocating two 4-byte blocks, they may not be contiguous. that's what I mean by "it's not guaranteed that separate memory allocations will allocate contiguous blocks". – Kareem Jul 8 '15 at 16:24
  • @hagrawal the OS sometimes can detect that your program is trying to access memory that doesn't belong to it in which case you'll probably see a segmentation fault and the program will crash. and yes, I mean contiguous blocks to the overflowed buffer. so technically, when buffers are involved, it's your responsibility as the programmer to ensure the buffer is not overflowed. otherwise, I think it's the OS's responsibility to prevent your program from accessing memory locations that doesn't belong to it. – Kareem Jul 8 '15 at 16:36
  • Thank you for your inputs. – hagrawal Jul 8 '15 at 17:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .