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 <alex.woll...@gmail.com> 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 osv-dev+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/osv-dev/CAL9cFfN082wR9gG5sn_uj8XH_VGCWXhMUgPJgrqaL-HjXcD7Vg%40mail.gmail.com.
