Hi, I'm sorry for not getting back to you sooner.
Please take a look at my questions and answers below. You may also find reading the comments of this issue helpful - https://github.com/cloudius-systems/osv/issues/651. On Thu, Aug 7, 2025 at 1:36 PM Alex Wollman <[email protected]> wrote: > Greetings Mr.Kozaczuk, > > *Bottom Line Up Front* > My name is Alex Wollman, a PhD student at Dakota State University, and I > am contacting you to inquire about the memory management and page > allocation code for OSv. If you have time to respond to my questions I > would greatly appreciate it, but if not I also understand you are a very > busy individual. I also understand my first email to you is *unreasonably* > long, > for which I apologize. My personal bias is to provide more information > up-front than a lengthy back-and-forth. I hope this is not too much of an > inconvenience, as I value your opinion. > > *Context* > My name is Alex Wollman and I am a Cyber Operations PhD student at Dakota > State University in Madison, SD. My dissertation topic is focused on the > security of unikernels, and I am currently using OSv as a case study to > implement Address Space Layout Randomization. I have 2 papers published > indicating the need for the research ( > https://ieeexplore.ieee.org/document/10778787 and the preprint for the > 2nd one is here https://arxiv.org/abs/2412.10904.) I've been reading > about unikernels for approximately 2 years now and they are an > extremely fascinating topic in the field of computing. Especially now with > the drive to make smaller and smaller compute environments viable. > > I have seen all the work you've done in the Cloudius-osv repository and > found your email address in the Google Groups for OSv. First, thank you for > all the work you've done on this project! As I read through the code it's > very impressive work. > > If you have time to answer a few questions I have about the memory > management and page allocation code I would truly appreciate it, however I > also understand that you are a very busy individual and may not have time. > > *Implementation* > I have implemented a rudimentary ASLR for the stack in custom x64 > applications by modifying the init_stack function within the threading > codebase (osv/arch/x64/arch-switch.hh line 160 begins the init_stack > function, and I can provide more details upon request.) However my > implementation just chooses a "random" location within the allocated memory > (0x100000 in size) and sets the "stack.top" value appropriately. This will > result in "0x100000 - stack.top" bytes of memory being allocated but always > unused, which is not optimal. > How exactly do you allocate stack memory to make it "random"? I think you will need to differentiate between kernel and application thread stacks. > > Using realloc for the stack has resulted in page_fault errors and malloc > has not seemed appropriate as the memory has already been allocated at the > point I begin my work (at least according to the program flow.) I am > willing to provide more details upon request to provide more context. > Do you have a branch I can look at? > > Attempting to implement heap based ASLR is a completely different story. > In the Linux kernel there is a brk structure to track the starting address > so when the program executes memory can be assigned appropriately. > Obviously unikernels operate totally differently, and this forms the basis > of my questions. > > *Questions* > *How do I identify where the heap is assigned in the code, and is there "a > heap" for applications?* > From what I can tell given the documentation and functionality, there is > no 'brk' structure to track the heap. In fact I have not been able to > identify a specific page or code functionality that identifies a heap at > all (though through developmental testing I know there is one.) My research > has taken me down the MMU code path and when I get to physical memory > discovery and page assignment I'm afraid I've gone too far. Is there any > guidance you can provide to help me navigate page creation and management? > You guessed it right. There is no concept of a "heap" in OSv. Applications executed on OSv run within the same memory space and normally integrate using the standard C library interface (malloc, free, open, etc), not at the system call level. So they do not need to know the heap. Having said that, there is a fairly new way of executing apps - statically linked or executed via Linux dynamic linker ("ld.so") - which DO integrate at the system call level and OSv implements brk. > > *Given there is no *brk *style heap management, would randomizing the > heap starting address require serious alterations to page allocations?* > As I understand it, physical memory is discovered and then memory pages > are created, and the heap is "just" one of those pages. If I wanted to > implement an ASLR solution for the heap (and possibly a better one for the > stack) I think functionality would need to be introduced at this level > (memory page assignment) to identify the heap and enable downstream > functionality. Is this an achievable approach? > Given there is no heap, I am not sure if this question is applicable. > > *Conclusion* > First if you are reading this, thank you very much for your generous > donation of time and effort. I truly appreciate it! > > I check this email consistently so it is the best way to contact me. If > you are concerned I am not a real person (in this day and age, I wouldn't > blame you) I also work at DSU, so you can find me in the directory at > dsu.edu/directory > > I look forward to your response. > > Sincerely, > Alex Wollman > PS. I took the liberty of replying to your email and to the OSv mailing list so maybe others can chime in. -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/osv-dev/CAL9cFfN082wR9gG5sn_uj8XH_VGCWXhMUgPJgrqaL-HjXcD7Vg%40mail.gmail.com.
