Page 1 of 1
Virtual memory space and memory allocation
Posted: Thu Nov 14, 2013 1:40 am
by Antti
I use the x86-32 architecture with paging as an example. What if a user-space application could use the whole virtual address space except the last page (reserved for syscall implementation) without any user-space-visible memory allocating mechanism. Paging would make sure that when a page is written it is allocated. Initially all "unallocated" pages use a zero-filled page so reading would just return zero. Sounds good so far.
What about freeing memory? A user-space application could just fill the memory with zeros. A page with zeros can be replaced with a general filled-with-zeros page. All this would be transparent to user-space applications. The trick is that it is done only if it is really needed. If the system is running out of memory, it starts looking user-space applications and find pages that are allocated but are filled with zeros.
What about running out of memory? A solution would be a user-space exception handler.
Re: Virtual memory space and memory allocation
Posted: Thu Nov 14, 2013 1:52 am
by linguofreak
Antti wrote:I use the x86-32 architecture with paging as an example. What if a user-space application could use the whole virtual address space except the last page (reserved for syscall implementation) without any user-space-visible memory allocating mechanism. Paging would make sure that when a page is written it is allocated. Initially all "unallocated" pages use a zero-filled page so reading would just return zero. Sounds good so far.
Something like this could be done, but leaving unused pages unmapped has advantages when it comes to diagnosing bugs and limiting what damage they can do, which is why operating systems tend to mark unused pages as not present.
Re: Virtual memory space and memory allocation
Posted: Thu Nov 14, 2013 3:16 am
by sortie
For extra fun, put the system call page at 0x0 and make it non-readable/non-executable/non-writable by user-space. This will allow the process to use the entire address space and NULL dereferences would still crash the process. I think I heard some OS X versions does something like this, actually. Mind you that accessing bad pointers is undefined behavior (though such is derefencing NULL also), which means that arguments such as "But then the program won't crash!" is kinda irrevant.
A curious thing, though, is that not all pages are the same because each page has permissions associated with them (readable, writeable, executable, ...) but such automatic allocation that you propose can't select the appropriate permissions. You will still need some mprotect system call interface.
Re: Virtual memory space and memory allocation
Posted: Thu Nov 14, 2013 4:32 am
by Antti
sortie wrote:For extra fun, put the system call page at 0x0...
I was also thinking that and it would be a good choice. However, I was also thinking that the page could be readable. It could contain a header that contains some information. It would catch NULL writes but not reads.
Address space could be something like this:
Code: Select all
[0x00000000 - 0x000007FF] - Program header and other read-only information
[0x00000800 - 0x00000FFF] - Reserved for system calls
[0x00001000 - 0xFFFFFFFF] - Application memory space
Memory space would contain the executable code and read-only data and those pages would be marked as "read-only" (and "non-executable" if supported). Program header would define where those areas are (including the stack setup). All the memory that are run-time allocated would be read/write/non-executable data.
The space reserved for system calls can be read by a user-space program. This must be taken into account. The documentation could define it reserved but not containing any confidential data about other processes etc.
Re: Virtual memory space and memory allocation
Posted: Thu Nov 14, 2013 4:53 am
by Antti
When thinking more, I do not like the readable system calls area. The first or the last page should not be readable.