4 ms·

I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386 (486) AT clones. :-)

1letterunixname 3y ago
There's a no-std tutorial on how to write a demo kernel in Rust. https://os.phil-opp.com https://os.phil-opp.com osdev.org, sandpile.org, RBIL, and freevga. The biggest PITA is hardware support. There are many good vintage hardcopy books with recipes for things like reliable port IO and undocumented hardware tricks. - Intel® 64 and IA-32 Architectures Software Developer’s Manual Combined Volumes: 1, 2A, 2B, 2C, 2D, 3A, 3B, 3C, 3D, and 4 - Microsoft MS-DOS Programmer's Reference (also includes real-mode BIOS calls) - PC Interrupts - Undocumented PC - PC Intern - Programmer's Guide To The EGA, VGA, And Super VGA Cards - Graphics Programming Black Book Special Edition Also, it's worth toying with advances in OS dev past the era of monolithic, microkernel, and hybrid. 1. Capability-based like seL4. It has a number of inherent performance and security advantages including capabilities and excellent IPC. 2. POSIX compatibility layer. Even embedded OSes without the concept of threads or processes can implement POSIX. 3. Hypervisor. They're much easier to add with intel's VT-[xd]. Failing that, fall back to emulation. Translational emulation is very performant. 4. Get good at generalizing interrupt handlers, making them fast, avoiding race conditions, and using lock-free patterns. Also: 5. Rewriting or trapping unsupported instructions including x87 and MMX. 6. The failure of pure microkernel was the added complexity and management of sequencing multiple resources in a transactional manner. There are great theoretical security and operational advantages in microkernel architectures but they never caught on widely in a pure form.
- vacuity 3y ago
  > 2. POSIX compatibility layer. Even embedded OSes without the concept of threads or processes can implement POSIX. Do you have resources about this? I can't quite fathom how it would work, but then again I have no expertise. > 3. Hypervisor. They're much easier to add with intel's VT-[xd]. Failing that, fall back to emulation. Translational emulation is very performant. Speaking of which, QubesOS was on HN recently. The essence is having many VMs to minimize cross-app attack surface and privilege escalation. > 6. The failure of pure microkernel was the added complexity and management of sequencing multiple resources in a transactional manner. There are great theoretical security and operational advantages in microkernel architectures but they never caught on widely in a pure form. I recently saw an interesting brief article[0] about how memory-safe languages can supercede the compartmentalization that microkernels provide. I'm reminded of Theseus[1], written in rUsT, which happens to reflect the sentiment. I've actually been putting off rereading the Theseus USENIX paper. Again, I'm not nearly qualified to answer whether the security of this is comparable to the best of that of microkernels, barring formal verification. Still, I think it should be explored more. [0] https://catern.com/microkernels.html (Write modules, not microkernels) [1] https://www.usenix.org/conference/osdi20/presentation/boos
- lionkor 3y ago
  Sorry, but I followed most of this tutorial, just to be greeted with "and luckily enough we dont have to write this because theres a crate for it" every time a new concept is introduced. Interrupts? x86_64 crate does all that. Keyboard handling, etc? Theres a crate for that. Of course theres a crate for all that, but thats not the point of making an OS.

There's a no-std tutorial on how to write a demo kernel in Rust. https://os.phil-opp.com https://os.phil-opp.com osdev.org, sandpile.org, RBIL, and freevga. The biggest PITA is hardware support. There are many good vintage hardcopy books with recipes for things like reliable port IO and undocumented hardware tricks. - Intel® 64 and IA-32 Architectures Software Developer’s Manual Combined Volumes: 1, 2A, 2B, 2C, 2D, 3A, 3B, 3C, 3D, and 4 - Microsoft MS-DOS Programmer's Reference (also includes real-mode BIOS calls) - PC Interrupts - Undocumented PC - PC Intern - Programmer's Guide To The EGA, VGA, And Super VGA Cards - Graphics Programming Black Book Special Edition Also, it's worth toying with advances in OS dev past the era of monolithic, microkernel, and hybrid. 1. Capability-based like seL4. It has a number of inherent performance and security advantages including capabilities and excellent IPC. 2. POSIX compatibility layer. Even embedded OSes without the concept of threads or processes can implement POSIX. 3. Hypervisor. They're much easier to add with intel's VT-[xd]. Failing that, fall back to emulation. Translational emulation is very performant. 4. Get good at generalizing interrupt handlers, making them fast, avoiding race conditions, and using lock-free patterns. Also: 5. Rewriting or trapping unsupported instructions including x87 and MMX. 6. The failure of pure microkernel was the added complexity and management of sequencing multiple resources in a transactional manner. There are great theoretical security and operational advantages in microkernel architectures but they never caught on widely in a pure form.

vacuity 3y ago
> 2. POSIX compatibility layer. Even embedded OSes without the concept of threads or processes can implement POSIX. Do you have resources about this? I can't quite fathom how it would work, but then again I have no expertise. > 3. Hypervisor. They're much easier to add with intel's VT-[xd]. Failing that, fall back to emulation. Translational emulation is very performant. Speaking of which, QubesOS was on HN recently. The essence is having many VMs to minimize cross-app attack surface and privilege escalation. > 6. The failure of pure microkernel was the added complexity and management of sequencing multiple resources in a transactional manner. There are great theoretical security and operational advantages in microkernel architectures but they never caught on widely in a pure form. I recently saw an interesting brief article[0] about how memory-safe languages can supercede the compartmentalization that microkernels provide. I'm reminded of Theseus[1], written in rUsT, which happens to reflect the sentiment. I've actually been putting off rereading the Theseus USENIX paper. Again, I'm not nearly qualified to answer whether the security of this is comparable to the best of that of microkernels, barring formal verification. Still, I think it should be explored more. [0] https://catern.com/microkernels.html (Write modules, not microkernels) [1] https://www.usenix.org/conference/osdi20/presentation/boos
lionkor 3y ago
Sorry, but I followed most of this tutorial, just to be greeted with "and luckily enough we dont have to write this because theres a crate for it" every time a new concept is introduced. Interrupts? x86_64 crate does all that. Keyboard handling, etc? Theres a crate for that. Of course theres a crate for all that, but thats not the point of making an OS.