arignir / chaos-2

A hand-made SMP-aware kernel

ChaOS is an SMP-aware kernel that we are doing as a part of our studies at Epitech.

Build Dependencies

• make
• gcc or clang (latest version, ideally)
• grub-mkrescue and libisoburn (usually packed with other binaries as grub)
• mtools
• dialog
• qemu (cpu emulator) optional

If you are using apt-get as your package manager (Debian, Ubuntu etc.), you can use this command to install all dependencies:

apt-get install qemu grub-pc-bin xorriso mtools

If you are using pacman as your package manager (ArchLinux, Manjaro etc.), you can use this command:

pacman -S dialog qemu grub libisoburn mtools

If you are using portage as your package manager (Gentoo), you can use this command instead:

emerge --ask sys-boot/libisoburn sys-fs/dosfstools sys-fs/mtools

If you are using an other package manager, well... Good luck! :p

Building an iso

First, tune as you wish the kernel's configuration with

make config

Then, build the kernel:

make kernel

To build a complete iso with grub installed (suitable for USB flash drives or virtual machines), run

make iso

Running with QEMU

If you want to run ChaOS through QEMU even if it's boring & useless right now, run

make run

Roadmap

• Kernel options
• Kernel architecture
• Kernel placed in high-addresses
• Boot
  • Multiboot
  • Paging setup
  • GDT setup
  • IDT setup
  • TSS setup
  • SMP setup
• Basic drivers
  • VGA
  • PS/2 Keyboard
• Memory
  • Physical Memory Management
  • Virtual Memory Management (mmap(), munmap() etc.)
  • Virtual segments of memory
  • Kernel heap (kalloc(), kfree(), krealloc())
• ELF Program execution (exec())
• Syscall interface and userspace (ring 3)
• Multi process / threads
  • Scheduling
  • User Threads
  • Kernel threads
  • Processes (mix of clone(), exec() and exit())
• Initrd loading, reading and writing
• Device abstraction
• Filesystem
  • Directory listing (opendir(), readdir(), closedir())
  • Creating and removing files/directories (mkfile(), mkdir(), remove())
  • File basic IO operations (open(), read(), write(), close())
  • File advanced IO operations (pipe(), dup())
  • File informations (stat())
• User space programs (init, tty, shell, basic binaries such as echo, ls, rm, mkdir etc.)
• Virtual filesystems (/proc, /dev)

🚀 Wanna participate?

Fork me!

chaos-2's Issues

Panic when an exception occurs in ring 0.

When an exception occurs in ring 0, the kernel should panic.

The main reason behind that is that we don't know in which state the kernel was before the exception, and therefore we don't know what to do, which locks to unlock, which buffers are corrupted and which ones are not, etc.

An exception handler can check if the previous code was running in ring 0 by looking at the value of iframe->cs. If it's equals to KERNEL_CODE_SELECTOR, then the code was in ring 0. Otherwise, it was probably in ring 3.

Create the syscalls corresponding to the kernel/fs.c functions.

Most functions in kernel/fs.c should have their syscall equivalent, calling them.

Add advanced IO syscalls

These syscalls are:

• pipe()
• dup()

Implementation is unspecified yet.
This issue can be used as an open debate on how these syscalls may work.

Add a serial port driver

Currently, kernel's printf() outputs on the screen using the vga buffer. But the vga buffer is limited to 80*25 chars and the current implementation doesn't handle scrolling yet. So any long output cannot be seen completely.

A possible solution is to make printf() output to the serial ports instead. Debug will only be visible to ChaOS developers using virtual machines or connecting their computer to a debugging system, and user-friendly messages can always be printed on screen using the tty (currently not implemented) or directly with vga_puts().

Add basic IO syscalls

These syscalls are:

• open()
• read()
• write()
• close()

Implementation is unspecified yet.
This issue can be used as an open debate on how these syscalls may work.

Lock primitives should have a 'is_locked()' function.

Lock primitives (spinlock, mutex, semaphore, rwlock) should all have their is_locked() function.

This could be used in debugging assertions to make sure some golden rules are respected all along the kernel (lots of functions are assuming that some datas are already locked etc.).

Biggest beneficiaries are the vaspace_* functions. They assumes current thread and current virtual address space are both locked as writers. If they aren't, undefined behavior may occur.

Add syscall security

Buffers (and any information) given by the user in syscalls should be verified.

This means:

• The buffer must exist
• And it must point to userspace memory

A program is not allowed to segfault when running in ring 0 (the kernel should panic), so ensuring these buffers are valid is a necessity.

Kill the userspace thread when an exception occurs in ring 3.

When an exception occurs in ring 0, the kernel should kill the current thread.

Implement a 'FAT' filesystem driver.

The FAT filesystem is a common and easy-to-implement filesystem. Having one is mandatory.

Add a PS/2 Keyboard driver

A PS/2 driver would be neat.

The driver should be as complete as possible, handle errors/unimplemented features properly and store the keys in an internal buffer that can be given to the tty later.

add mem_bdev boundchecking

Add the stat() syscall.

add user-provided pointer checks

This mostly concerns syscalls.

Add userspace programs

The most important one are:

• A basic shell
• Basic binaries (echo, ls, rm, mkdir etc.)
• Eventually a game (chess! :D)

`sys_wait()` and allow access to thread tid in `clone()`

Necessary for a shell

Add virtual filesystems

Virtual filesystems are the peak of a finished kernel !

Adding /proc and /dev would be neat.

Finish the 'dumbfs' implementation.

The dumb filesystem has been started, but is not finished yet.

I think it would be better to finish it before starting the FAT filesystem.

Add argv and argc to ̀sys_exec()`

Necessary for a shell.

Add vseg flags

Virtual segments (struct vseg) need flags to identify if they are readonly, executable, userspace etc.

These flags should be used by vseg_grow() and forwarded to mmap() and munmap() so new pages of growing segments have the flags they deserve.

In the same way, vaspace_new_vseg() should set these flags.

A possible implementation would be to add a field of type mmap_flags_t flags within the structure vseg.