hw/virtio/virtio.c).
@nuta I was thinking I can take up one more task in parallel with KASAN, now that my exams are over and I have some time (and curiosity xD). Are we considering a slab allocation scheme in malloc?
A slab allocator sounds good idea :)
Hi @nuta, our 6 weeks are about to get over. We have our project presentation scheduled this Sunday evening. where we have to explain what we did and show our work (Fingers crossed haha :D). But that is just for our University and we'd love to continue working on the features we're implementing. Meantime, we'd be really grateful if you can share what you feel about our work, which we can use as a testimony in the concluding part of our presentation.
It's the first time we worked on an open-source at this scale and you've been a true guide to us in our journey! Thanks a ton :heart:
@PrayagS Good point. Currently, I'm working on the virtio-gpu driver and plan to improve the virtio library in couple of days. In the improvement, I'll try addressing the issue you described. FWIW, you can investigate why your virtio driver doesn't work by inserting some printf functions into QEMU (
hw/virtio/virtio.c).
I've pushed improvements on virtio library to allow constructing a descriptor chain. Can you try it out?
@yashrajkakkad Sure. Can you share your git branch for KASAN?
@yashrajkakkad I tried your code and it failed with general protection fault.
[kernel] WARN: Exception #13
[kernel] RIP = 0000000001005cc5 CS = 000000000000002b RFL = 0000000000000246
[kernel] SS = 0000000000000023 RSP = 000000000300ad70 RBP = 000000000300adb0
[kernel] RAX = 0a110ced0a110ced RBX = 0000000000000004 RCX = 0000000000000001
[kernel] RDX = 0000000004124120 RSI = 00000000000000aa RDI = f8f8f8f8f8f8f910
[kernel] R8 = 0000000000000003 R9 = 0000000000000000 R10 = 000000000300abd0
[kernel] R11 = 0000000000000246 R12 = f8f8f8f8f8f8f910 R13 = 0000000000000010
[kernel] R14 = 0000000000000020 R15 = f8f8f8f8f8f8f8f8 ERR = 0000000000000000
[vm] WARN: test: exception occurred, killing the task...
[kernel] destroying test...
QEMU 4.2.1 monitor - type 'help' for more information
(qemu) xp /i 0x1005cc5
0x01005cc5: 00 00 addb %al, (%rax)I think this is caused by accessing a non-canonical address in RAX by ADD instruction.
I'm not sure but I guess some part of the memory (e.g. return address in the stack) is accidentally overwritten because RIP = 0x1005cc5 seems to be incorrect:
$ objdump -d build/vm.debug.elf|egrep '1005cc[0-9a-z]'
1005930: 0f 85 8d 03 00 00 jne 1005cc3 <vaddr2paddr+0x3e3>
1005cc3: 48 bf c0 19 00 03 00 movabs $0x30019c0,%rdi
1005cca: 00 00 00 <-- instruction at 1005cc5 does not exist
1005ccd: 48 89 de mov %rbx,%rsiSadly, fixing your bug might take a time...
__shadow is too small and shadow_free accidentally destroyed other memory area. Thus it reproduces even if KASAN is disabled. Try the following patch: diff --git a/libs/resea/malloc.c b/libs/resea/malloc.c
index e8040b25..5f78190c 100644
--- a/libs/resea/malloc.c
+++ b/libs/resea/malloc.c
@@ -345,6 +345,14 @@ void shadow_free(struct malloc_chunk *chunk)
reladdr = ptr_cur - (paddr_t)__heap;
reladdr >>= 3;
DBG("%u", reladdr);
+
+ size_t len = chunk->capacity + MALLOC_REDZONE_LEN;
+ if ((vaddr_t) &__shadow[reladdr] + len >= (vaddr_t) __shadow_end) {
+ WARN_DBG("__shadow is too small: addr=%p, len=%d, reladdr=%p",
+ &__shadow[reladdr], len, reladdr);
+ return;
+ }
+
for(size_t i = 0; i < (chunk->capacity + MALLOC_REDZONE_LEN); i++)
{
__shadow[reladdr++] = SHADOW_FREED;Hi, @Manav-Kumar. We have already implemented basic features like the microkernel, FAT file system, TCP/IP, and some device drivers. We're working on some improvements and new features:
- A GUI server based on Wayland protocol (still in the very early stage)
- Rust support improvements: nuta/resea#49
Since I'm working on another OS project in Rust in very recent weeks, the progress is slow. That said, if you'd like to contribute to Resea, I can support you :)
Aside from those projects, we welcome your ideas and would like you to work on a project whatever you want. For example, integrating Linux Kernel Library would be an interesting topic.
Does resea supports multitasking features in current version. Can we plan to improve it in any way if it does.
Yes it supports. In a nutshell, Resea kernel implements a multi-tasking concept called task (so-called process). Each task has its own virtual memory space and can communicate with other tasks over message passing IPC. Threads are not supported intentionally because all applications in Resea are implemented in a single-threaded, event-driven way to make it easier to debug (we can still implement sort of threads in the userland by mapping same memory pages through vm_map syscalls btw).
Memory Management, vm, paging, interruptions, scheduling.. this might already be implemented in basic kernel features, are there any scopes of improvement.
We only have rudimental implementation so I think there's room for further improvements. Among the mentioned areas, user-level scheduling (nuta/resea#16) might be interesting to work on. A MINIX wiki page is informative on this topic.
task_schedule syscall) but the feature is unused at all.
- copy-on-write: Not implemented. Mapping zero-filled pages (e.g
.bsssection) using CoW might improve the startup time of a userland application. - zero filled on demand: I don't know what this feature does. BTW, preparing zero-filled pages in advance during an idle state would be good for performance.
- demand paging: Implemented. In fact, every page is mapped by the pager task on the first access.
always be executed immediately after a predefined interrupt occurs
We need to figure out how long does it would take until an interrupt is delivered in the worst case. Regarding the quantum, Resea already has a priority-based scheduler and it keeps running the task with the highest priority.
Can you tell something about the Linux ABI emulation? I assume it can only run a limited number of Linux binaries since there are few device drivers written for Resea.
IIRC, it can run only some very basic commands on Busybox's shell.
