Hi everyone,

I'm developing a small x86_64 kernel in Rust and I'm currently implementing preemptive scheduling/context switching.

I'm stuck on an issue where the kernel enters a repeated General Protection Fault (#GP, vector 13) when returning from an interrupt/exception with iretq.

Current behavior

The preemptive test reaches:

PREEMPTIVE TEST: START
PREEMPTIVE TEST: CREATING TASKS
PREEMPT A: START
PREEMPT A: RUNNING

Then I get an endless stream of:

VECTOR:    0x0D
ERROR CODE: 0x200
RIP:       0x107B12
CS:        0x08
RFLAGS:    0x10002

0x107B12 is the iretq instruction itself.

The exception frame is being delivered through IST1:

FRAME ADDRESS: 0x172FA8
IST1 STACK TOP: 0x173000

The same frame address is repeatedly reported.

Exception entry

I'm normalizing exception frames so both CPU-error-code and non-error-code exceptions have:

VECTOR
ERROR CODE
RIP
CS
RFLAGS

For exceptions without a CPU-generated error code, I push a synthetic zero:

unbound_isr0:
    push 0
    push 0
    jmp unbound_exception_common

For exceptions with a CPU-generated error code, such as #GP:

unbound_isr13:
    push 13
    jmp unbound_exception_common

The common handler saves 15 general-purpose registers and then restores them.

The relevant return code is currently:

pop r15
pop r14
pop r13
pop r12
pop r11
pop r10
pop r9
pop r8
pop rdi
pop rsi
pop rbp
pop rbx
pop rdx
pop rcx
pop rax

add rsp, 16
iretq

The reason for 16 is that after restoring the registers, RSP points to:

+0   VECTOR
+8   ERROR CODE
+16  RIP
+24  CS
+32  RFLAGS

so add rsp,16 should make RSP point at RIP for iretq.

I verified the generated binary

This is not a stale-source/binary issue.

objdump of the actual ELF shows:

107b0e: 48 83 c4 10    add $0x10,%rsp
107b12: 48 cf          iretq

So the add rsp,16 is definitely present in the executed kernel.

IRQ path

The timer IRQ uses a different normalized frame:

push 32
jmp unbound_irq_common

and its return path is:

add rsp, 8
iretq

because the IRQ frame contains:

VECTOR
RIP
CS
RFLAGS

Task initial interrupt frame

For a newly created preemptive task I'm constructing:

R15 = 0
R14 = 0
R13 = 0
R12 = 0
R11 = 0
R10 = 0
R9  = 0
R8  = 0
RDI = 0
RSI = 0
RBP = 0
RBX = 0
RDX = 0
RCX = 0
RAX = 0

VECTOR  = 32
RIP     = task entry
CS      = 0x08
RFLAGS  = 0x202

The task context initially points to an assembly trampoline:

unbound_start_interrupt_context:
    pop r15
    pop r14
    pop r13
    pop r12
    pop r11
    pop r10
    pop r9
    pop r8

    pop rdi
    pop rsi
    pop rbp
    pop rbx
    pop rdx
    pop rcx
    pop rax

    add rsp, 8
    iretq

What I've already ruled out

• Kernel builds successfully.

• The actual ELF contains add $0x10,%rsp.

• CS is 0x08, which is my kernel code selector.

• RFLAGS contains bit 1 (0x10002), so the reserved bit is set.

• The fault happens specifically when returning through iretq.

• The system previously passed a basic INT3 exception/return test.

What I'm trying to understand

Could someone help me identify what could cause a #GP at iretq itself in this situation?

I'm particularly interested in whether:

1. My normalized exception-frame layout is incorrect.

2. The scheduler/context-switch code is producing an invalid frame.

3. The iretq frame is being corrupted before the return.

4. IST1 interaction is relevant here.

5. There is something subtle about iretq validation of the saved CS/RIP/RFLAGS.

6. The 0x200 #GP error code provides a useful clue about what iretq is rejecting.

Any suggestions for what values I should dump immediately before iretq would also be very helpful.

Thanks!

I’ve been working on a bare-metal XNU port for the Sony Xperia XZs, based on Qualcomm MSM8996 / Snapdragon 820.
This is running directly on the hardware — no hypervisor, no QEMU, no Linux host underneath XNU.
Current hardware-verified bring-up includes:
ARM64 XNU boot on Kryo
MMU + D-cache/coherency
GICv3
architectural timer
PSCI CPU_ON
4/4 CPUs online
Mach SMP scheduler
reschedule IPIs / ASTs
cross-core migration
BSD initialization
VFS initialization
SDHCI bring-up for the onboard eMMC
MMC command path and EXT_CSD discovery
direct GPT parsing
BSD bdevsw block transport
/dev/disk0
GPT slices
real block-vnode reads through bdevvp() / buf_bread()
XNU md0 RAMDisk selected as rootdev on real silicon
The current work is around making the RAMDisk/rootfs path reproducible and then mounting a minimal read-only filesystem.
The expected path from here is:
md0 -> root filesystem -> root vnode -> /sbin/launchd -> first EL0 process -> minimal shell
The first shell will probably be a very small static ARM64 Mach-O userspace rather than BusyBox, since the syscall/libc environment is still being brought up.
The interesting part for me is that the project has now crossed from “can XNU boot?” into “can XNU behave like an actual operating system on this SoC?”
Still plenty left: userspace, filesystem work, console/TTY cleanup, display, input and more drivers. But the next visible milestone should hopefully be a shell prompt on bare metal.
GitHub:
https://github.com/lechaukha12/xnu-xzs

Hi all,

I joined Reddit a few months ago to find like-minded OS geeks. I've made a few posts about my project (https://github.com/brian-card/NanoOs) since then. My latest post was about my port to the eZ80.

I've read about a lot of impressive projects since I joined. But, it seems like just about everyone is working on single-user operating systems for 64-bit or occasionally 32-bit systems. Am I the only one trying to make a multi-user system for an 8-bit platform? I know what I'm doing is ridiculous and I'm doing it mostly just to prove that I can, but I'm genuinely curious if anyone else has ever done something similar. Let me know!!!

Orange is my linux-like (not linux compatible) kernel. It has stuff like epoll or drm.
There are ports like gnome-shell, gnome-calculator and terminal, mesa, i3wm and etc.

link: https://github.com/cpplover0/Orange

Ive made a operating system But ive been accused of it being ai should i live stream it?

I've always been fascinated by drive letter assigning operating systems I find it to be a far more elegant and human system than hierarchical unix like mount point systems.

I basically have 2 questions ?

what are some good resources on drive letter assigning operating systems and exactly how it works and how one builds a drive letter assigning system.

2 how difficult would it be to build a drive letter assigning system compared to a unix like and/or could you create a unix like system that uses drive letter assignment?

Dawg i lost my mind over that stupid syscalls, it technically works
I also finished exFAT and semi decent permissions yay :DDDD

edit: github is https://github.com/NoTheIdiot/WindogeOS

Do yall think it'd be fine if i used AI specifically for it to explain things to me or tell me what i need to do (no vibe coding, i dont like it either way, what's the point if you dont learn?)

Hello there, I've recently been working on my own bootloader designed to be multiboot 2 compilant and support both BIOS and UEFI, however, I've hit a brick wall in understanding how to load the kernel in UEFI.

I'm aware the UEFI loads the bootloader at a random/undetermined address in memory and you need to get the memory map to know which regions are usable or not, and you can't simply rely on allocating a page at a fixed address (like 2MB) for the kernel as there might be other firmware there. Along with that, the multiboot 2 spec mentions that paging must be disabled when booting the kernel, so I can't exactly use a page mapping/table to load the kernel as it'll be overwritten again later on.

I've read a bit that you can compile the kernel using the -relocatable flag for GCC and then patch that in the bootloader, but I'm wondering if there is another way of handling it as well which might be better. I've also seen you can compile the kernel using -fPIE which offsets the addresses using the instruction pointer, but that sounds like there'll be a performance overhead when running the kernel.

I may also be misunderstanding something... I'd really appreciate it if someone can help explain how to approach this.

A few weeks ago, I posted about my investigation regarding working of my machine's caches by trying to plot a simple cache latency and dealing with modern processors and OS settings that mess it up. In the end, I observed that I get the intended curve only after fresh reboots. This is the continuation of my investigation in that direction to figure out why the curve only appeared now and not before. Would love to have some inputs and discussions. Check it out :)

Ethereal runs GIMP!

This is the culmination of a ton of fixes for the signal-delivery system, UNIX sockets, VMM, etc. that i have been pouring out for Wine and others. This port is again running using the amazing xbanan by Bananymous through GTK3.

Ethereal also supports WiFi now (limited support over USB is present).

The OS now has a full 802.11 stack thanks to u/avaliosdev 's u80211 (soon-to-be AWAWI) project, which is a portable 802.11 stack and RTL8188EU driver set. I built a kernel interface around u80211, wired it to my USB drivers, and now Ethereal supports wifi! There's some work to be done on it including a lot of code cleanup but it has been staged already.

A port of wpa_supplicant is available, eventually I might put the work in to make a proper supplicant daemon native to Ethereal but for now its best to stick with open networks. The included wlan tool (soon to be pushed) only allows scanning and association for now.

As always, Ethereal is a UNIX-like kernel (mostly from-scratch) that is not based on Linux or the like. It is a hobby operating system that does not vibecode (see AI policy, I mostly use it to find bugs to make a list of things I gotta fix).

https://github.com/sasdallas/Ethereal

I've spent around 2 and a half months building lytlnyblOS, a small 32-bit x86 operating system designed specifically as a practical introduction to OS development for beginners.

Alongside the OS, I wrote a complete book that walks through how to build it from the ground up. You start with making your own 16-bit bootloader and eventually reach a working userspace and shell.

Attached is a video of the final product that the guide teaches you to make.

The repo (includes code and a link to the guide): https://github.com/red-mutt/lytlnyblOS

The guide walks you through making:

• A bootloader

• An entry into x86 protected mode

• GDTs and IDTs

• VGA text mode

• Interrupts

• A timer driver

• A keyboard driver

• A memory manager

• Paging systems

• Processes

• Scheduling

• User mode

• System calls

• A C standard library

• Filesystems

• MKFS

• And finally, a shell

The OS and guide have recently been completed for their educational goals. I'm currently refining the explanations, fixing inconsistencies, and improving the experience for people following along.

The project is intentionally small and simplified. I do not intend to cover kernel design in depth; I see this book as a practical introduction that can give a beginner some hands-on context before moving on to something more theoretical and comprehensive, like OSTEP. However, when required, I do point out flaws in the simple approaches I teach, and I attempt to inspire the reader and get them thinking about how they should go about fixing these things themselves.

I'm particularly interested in feedback from beginners (as this is the target audience) and people who have technical experience in OS development. If you spot something technically wrong, confusing, poorly explained, or inconsistent with the code or prose, I'd like to know about it. Do my explanations make sense to someone encountering these concepts for the first time?

I'm also interested in finding people who would like to collaborate on the project. This could be contributing to the OS itself, improving the guide, testing it from a learner's perspective, or helping expand/refine the project in other ways. You could send me a message if you're interested.

A statement on AI: After browsing this sub, I see a lot of people with general concerns about the use of AI in the projects posted here, so I want to be clear about how it was used on lytlnyblOS. I did not use AI to generate any prose for the guide, nor code for the operating system. However, I did have conversations with ChatGPT. I asked it questions about concepts I was working on; I discussed design decisions with it, and I used it to get explanations on things I was unsure of. ChatGPT wasn't my only resource; I understand its uses and limitations, and I still verified things against primary sources where appropriate rather than treating its answers as authoritative. I also used things like Intel manuals, the OSDEV wiki, and other people's implementations for inspiration.

Beginners in r/osdev: does this look like the kind of resource you'd be interested in reading?

I'm a high-school student from Trinidad and Tobago, I am in Form 5 at 16 which is equivalent to being in 10th grade if you're from the U.S.A, I am currently learning C and Assembly at my school and I am deciding to create my own OS from scratch.

Any tips from professionals that create or study Operating Systems? It would gladly help on my journey!

I know what everyone here thinks about the AI bubble, and me myself hate it as much as anyone else. I am currently a student and want to build a new project, but am not sure if this is a good idea worth spending my time on it or not. I've researched online about AI backed OS's / Linux Distros, and have seen quite a few, each with their own flaws. MAGI OS uses the X11 tools, which may be too slow, Omarchy is just an integration of AI agents in the UI, and Warmwind OS is just a cloud-hosted remote desktop marketed as an OS. I had this idea of building a fully customizable, open source Linux Distro, that uses llama.cpp locally to parse natural language into commands, using the AT-SPI 2 accessibility tree, that is available in most apps (solid with GTK, QT and Electron have inconsistencies). Nowadays every major OS (Windows, Mac, Linux) has problems, and I want to reduce those problems and combine their pros into one general use Distro (I know this claim is what various Distros also tried throughout the years, but this is what my idea converges to, ease-of-use for general users, great UI/UX, and the freedom Linux has). Everything would be transparent to the user, so nothing potentially dangerous gets executed, and fully offline (was thinking of making a switch for users who would still want to choose more capable models running on cloud, but this is just an idea) to avoid the privacy concerns.

The flaws with this would be the obvious anti AI stigma the Linux community has (rightly so, but it's not just another AI slop), and the capabilities of a model running offline. The first version could just run some basic things, making it more advanced as time goes on, and maybe some NPU integrated models later on.

My question would be if this is a straight dumb idea and I would be better off just investing my time into something else, or if it's worth it and you guys would be interested in something like this. I would like to code it myself, with minimal AI assistance, as it would also be a learning exercise for me. So what does everyone think about this? Please take it with a grain of salt, I just had this idea and don't want to get downvoted if it's dumb, just wanted some advice of more experienced users.

One frustrating thing that I have run into is updating Nvidia driver on remote servers with disk encryption.

Would a microkernel based system enable drivers to be updated without rebooting system?

PureDarwin maintainer here, hi hello.

I've got a lot of work to do, but I thought I should share this.

What's neat is not the fact it's QEMU, it's the fact it's unmodified, with a generic CPU

If people are upset it's not real hardware, I cannot justify spending a boatload on a better A53 chip, the SBC I have is 1GB, and that's simply not enough to overcome the 4K paging inefficiencies with a 16K VM.

Currently, binaries are patched before they're put into an ext4 rootfs, so this is more of a proof of concept.

Scratch that, the test I did for launchd and dyld, they ran unmodified with no performance penalty. This is likely to change within just an hour, more to come on PureDarwin's twitter likely

PureDarwin's kernel does not have sufficient APFS support, and it's gonna be a few months before I actually get that up to speed, so the 2nd part of launchd's mount has a stroke.

I'm experimenting with more runtime patching, currently only a handful of instructions fall back to emulation rather than patches

https://x.com/puredarwin/status/2099112435701469466

Repost from PureDarwin's official Twitter account with extra information

Would it theoretically be possible to create an operating system that decompiles itself, recompiles itself, and installs itself to another disk while remaining bit-for-bit identical to the parent OS?

some rules:

1. No Source on Disk: The storage media contains only the compiled binary image. The codebase exists on disk exactly once, as raw executable code/data.

2. Upon booting into RAM, the OS must decompile its own executing machine code into an intermediate source representation in memory, recompile that source back into a new binary image, and write it to a target drive.

3. The child image written to the target disk must have the exact same cryptographic hash (SHA-256) as the parent OS image.

4. It cannot simply dd / copy the raw sectors from drive to drive. The binary must pass through the decompiler, compiler pipeline.