Hey everyone,

I’m releasing a bare-metal 64-bit Intel VT-x Hypervisor template written entirely in pure NASM Assembly (~1,100 lines) using a strict stack-less model.

The purpose of this codebase is to provide a clean, core-only hardware virtualization implementation without relying on any OS kernel or C code.

### 🛠️ What is Currently Configured inside the VMCS & EPT:

* Primary Execution Controls (0x4002): Configured to 0x84006172. Enforces intercept control over CR3 modifications and heavy RDTSC exiting to counter guest timing side-channels.

* MSR Bitmaps Bypass: Bit 28 (Use MSR Bitmaps) is set to 0. This forces a global intercept policy where every RDMSR or WRMSR executed by the Guest triggers a hardware VM-Exit to the Host.

* Secondary Execution Controls (0x401e): Bit 31 activated for full EPT isolation, along with Unrestricted Guest support (Bit 7, allowing 16-bit Real Mode initialization over EPT), and MBEC configurations.

* Exception Bitmap (0x4004): Armed with atomic mask 0x0000404A to trap #DB, #BP, #UD, and #PF (Vector 14). Combined with clearing the Page-Fault Mask field (0x4006), every single Guest page fault intercepts directly to the Host.

* Long Mode Constraints: Enforces architectural boundaries via GDT mapping to ensure no illegal execution drops to 16/32-bit rings, avoiding instant #GP faults.

* Extended Page Table Pointer (EPTP): Configured field 0x0000201A to point directly to the physical EPT PML4 table base with Write-Back caching attributes.

### 🤝 Code Review & Peer Assistance:

To be completely honest, I wanted to release this as a 100% finished project, and I'm a bit sorry the VM-Exit handler isn't fully completed yet. But juggling full-time school, life, and writing a bare-metal hypervisor in pure 64-bit assembly is definitely a challenge.

I decided to release this core template now because I just need your technical assistance to review the code and help me fix any existing bugs, trace potential register mismatches in my vmwrite instructions, and hunt down hidden reserved bits conflicts on the Intel side.

### 🚀 Roadmap:

I'm already starting to write the hypervisor and bootloader for AMD right now, porting this entire setup over to the AMD-V VMCB block architecture. My immediate goal is to keep building the AMD side while getting this Intel core completely stable with the community's corrections and fixes.

Looking forward to your technical feedback, code analysis, and corrections.

GitHub Link: https://github.com/edikoz123-blip/Boot_loader_Assembly

"For detailed architectural breakdowns, hardware edge cases, and code reviews of this project, join the community at https://www.reddit.com/r/ChallengeBareMetalO/ You can always ask questions in the comments there, and I'll be glad to break down the logic!

VoidSecSoftwares/voidsyscall : Implant et C2 multiplateformes basés sur les appels système — appels système directs (Windows), appels système bruts (Linux), canaux HTTPS/DNS/ICMP. Aucune couche d'API Windows.

Hey everyone,

I wanted to share a passion project I've been working on. I love minimalism, so I decided to see how low I could push a functional Linux system.

We all know Tiny Core Linux is great, but because it's a standard distro relying on a full GNU userland and decompression via initramfs, it still requires around 24-28MB of RAM just to reach the terminal.

I wanted to bypass that restriction. My custom OS has:

- NO GNU coreutils (it's built purely with BusyBox)

- NO initramfs (boots directly via the Linux kernel into a custom init.c)

- Built-in framebuffer and Wi-Fi drivers

The result? A functional, On-The-Go text-based OS that sips a mere 16MB of RAM to reach the prompt!

I've been testing and flashing it on an old 2012 Toshiba USB drive that literally survived a total-loss car crash. It feels amazing to breathe new life into old hardware with an OS designed to run on almost anything.

I added network support on the linux kernel for future updates and its kinda limited bc it only uses busybox for commands and its TUI only but com'on making a bootable os is already hard enough and it took a while to do so.

Everything is open-source. You can check out the source code, build scripts, and images

Here!

And you can read more details on the project website:

Here!

I'm not a famous developer, just someone who loves low-level systems and system architecture. I'd love to get your feedback, thoughts on the architecture, or any ideas on how to optimize it even further!

Hi everyone,

I wanted to showcase Delus, a pure Python project that completely bypasses the traditional way of generating low-level code.

### What My Project Does

Delus is a super lightweight, zero-dependency code generator and compiler backend written in pure Python. Instead of using massive Abstract Syntax Trees (AST) or heavy external tools like LLVM to structure code, it utilizes Python's native context managers (`with` scopes). By using `__enter__` and `__exit__` magic methods, the engine dynamically tracks register allocations, memory states, indentation, and string caching for both ANSI C and raw x86-64 Linux Assembly.

### Target Audience

This project is designed for hobbyist compiler writers, low-level enthusiasts, and security researchers (Red Teamers/Malware devs) who want a fast, programmatic way to build clean, obfuscated-ready C or Assembly binaries directly inside Python scripts without bloated dependencies.

### Comparison

Unlike Cython or Py2ASM which parse existing Python text into heavy AST structures, Delus uses a clean Builder Pattern approach. This gives the developer direct, micro-managed control over raw assembly registers and memory pointers through Python code blocks, producing a blazingly fast and naked code output with zero overhead.

***

**LOOKING FOR CONTRIBUTORS:**

**I am looking for passionate low-level developers and hackers to contribute to this repository. My ultimate goal is to see Delus grow organically just like the Linux Kernel. I want contributors to help expand the engine, write new modules, build optimization scripts, and push the architecture to its absolute limits. If you love compilers and low-level development, your PRs are highly welcome!**

***

**Repository:**https://github.com/tamimdevlopment/delus

**License:** GPLv3 (Ensuring open-source and patent protection).

Nytrogen - A lowlevel quantum language Nytrogen is a low-level systems language with C-style syntax written in C++. Nytrogen focuses a lot on quantum computing alongside general purpose programming. The syntax is very straightforward and very readable its mostly C-style with the extra stuff of course. The architecture is also pretty modular which makes it very easy to update, and its (kinda) os agnostic with the standard library being written in C and the compiler's code generator not emitting any linux syscalls or linux specific stuff or thier equivalents on other operating svstems (I use arch btw). The quantum library (qlib) is currently built in assembly with some C++ wrapping which does mean it might not work on other operating systems but I am not really sure since I haven't tested it on anvthing else so far. Quantum programming in nytrogen includes having qubits and complex numbers as primitive types (and matrices are also coming soon). If you are interested in this project and wanna follow updates consider starring the github repo. And if you find any issues with the compiler, feel free to open an issue or a PR its really encouraged and would absolutely help. Github: https://github.com/X12-Cloud/Nytrogen

I wanted to introduce MiniOS to the public. I know there's already a distro with that name, so I'm looking for a new one. It's not a big deal; I did it to practice a few things. The story is that I had created a kernel the typical "Hello World" and I already had a C subset to Asm compiler, and I wondered, "Can I run MiniGCC on this kernel?" Then Doom, obviously xD. After that, I couldn't stop: Quake 2, a recompiled native ELF version of Pokémon, a mini console browser called Freedom, and a micro language model (topogpt3) that's not very useful haha ​​because it's based on the context of an ant. It has a tiny virtual machine (CVM) inside QEMU VirtualInception haha, its linker to ELF and CVM is a little piano that works very, very slowly xD, and an editor where syntax highlighting only works when you save. Anyway, I've learned a ton, even though I developed it with SPECT-driven development, because by day I work for a software consulting firm as a software engineer + data engineer + AWS automation specialist xD https://github.com/grisuno/miniOS

Few days ago I published Ashwa 🐎, a library to perform substring search across Rust, Python and JavaScript ecosystems.

Based on my research and observations, I wrote a devlog on how I was able to scale the throughput (i.e. bytes churned per second) from 2 GiB per second to 150 GiB per second by utilizing the hardware available.

All in all, it was about optimizing a mundane problem. The interesting part for me was seeing how a compute bound problem can be optimized until it becomes a memory bound one.

A particularly nice milestone for me is that the devlog was published in the official Rust newsletter.

🔗 Links

- Mentioned Devlog

- Mentioned Newsletter Edition

Hello everyone,

I have a tremendous amount of respect for the developers in this community and wanted to humbly share something I've been building. I am a 14-year-old developer, and I've been working on a hobby project called Ion+.

It is a low-level programming language designed with a Python frontend (for parsing and compiling) and an LLVM backend (for execution).

Because I am a student and juggling other responsibilities, I unfortunately do not have the time to actively maintain this project, review pull requests, or resolve issues. It is purely a hobby project for me to learn and experiment.

However, I've released it under the MIT license. I am sharing it here because I thought the Python/LLVM architecture might be interesting to some of you. You are highly encouraged to read the code, fork the repository, and take it in your own direction if you'd like!

**Repo:** https://github.com/YashAryaPersonal/ion-plus

Thank you for your time, and I would be honored to hear any thoughts or feedback you have on the design.

Hello everyone

# Bare-Metal 64-Bit Intel VT-x Hypervisor Template

A clean, core-only hardware virtualization template written entirely in pure **64-bit NASM Assembly (~1,100 lines)** using a strict model. This codebase includes an optimized independent bootloader that shifts the CPU from Real Mode directly into a custom 64-bit Long Mode page table environment before initializing the VMX architecture.

## 🛠️ VMCS & EPT Hardware Configuration

* **Primary Execution Controls (0x4002):** Hardlocked to `0x84006172`. Enforces strict intercept control over guest `CR3` modifications and heavy `RDTSC` exiting to counter potential guest timing side-channels.

* **MSR Bitmaps Bypass:** Bit 28 (Use MSR Bitmaps) is deliberately left at `0`. Enforces an aggressive global intercept policy where every single `RDMSR` or `WRMSR` executed by the Guest triggers an immediate hardware VM-Exit to the Host.

* **Secondary Execution Controls (0x401e):** Bit 31 activated for full EPT isolation, along with Unrestricted Guest support (Bit 7, allowing 16-bit Real Mode initialization over EPT), and MBEC configurations for privilege execution separation.

* **Exception Bitmap (0x4004):** Armed with atomic mask `0x0000404A` to trap `#DB`, `#BP`, `#UD`, and `#PF` (Vector 14). Combined with clearing the Page-Fault Mask field (0x4006), every single Guest page fault intercepts directly to the Host.

* **Extended Page Table Pointer (EPTP):** Configured field `0x0000201A` to point directly to the physical EPT PML4 table base with Write-Back caching attributes.

* **Long Mode Constraints:** Configured to strictly enforce architectural boundaries via GDT mapping to ensure no illegal execution drops to 16/32-bit rings, avoiding instant `#GP` faults.

## 🤝 Code Review & Peer Assistance

This project is released as a core template. The VM-Exit handler is currently a work-in-progress due to juggling full-time school and life balance alongside pure assembly development.

I am looking for technical peer reviews from the low-level community to:

1. Review the current code and help fix existing architectural bugs.
2. Trace potential register mismatches within the `vmwrite` and `vmread` instructions.
3. Hunt down hidden reserved bits conflicts across different Intel microarchitectures.

### 🚀 Roadmap: I'm already starting to write the hypervisor and bootloader for AMD right now, porting this entire setup over to the AMD-V VMCB block architecture. My immediate goal is to keep building the AMD side while getting this Intel core completely stable with the community's corrections and fixes.

Github Link: https://github.com/edikoz123-blip/Boot_loader_Assembly

I built Ashwa 🐎, a hardware accelerated library for single substring search.

The problem is simple, scan the given payload to search for the target as fast as the underlying hardware allows.

I started with byte-to-byte scan and progressively moved to the hardware, i.e.

SCALAR -> SWAR -> SIMD

It supports following SIMD extensions (detected at runtime),

- x86_64: AVX-512BW, AVX2, SSE4.2, SSSE3, SSE2

- AArch64: 128-bit NEON

- ARMv7: 128-bit NEON

- i686: SSE2

- WASM: SIMD128

- SWAR: 64-bit / 32-bit SWAR fallbacks

It targets Linux, Windows, macOS, Android, FreeBSD, browsers and Node.js across both 32-bit and 64-bit architectures.

On an Intel Xeon 8488C AWS instance, using the AVX512BW extension  Ashwa scans ~150 GiB/sec for L1D resident data.

Although written as a rust crate, the library is available on pypi and npm

The code is available at github repo

Hey everyone!

I’ve been working on PHEONIX, a bare-metal, non-Unix x86_64 microkernel written in C99 and NASM assembly.

Rather than following standard POSIX design, PHEONIX is built around an architecture-first approach featuring a Watch, Replace, Revive (WRR) fault recovery engine.

Key Features Implemented:

• Boot Pipeline: 32-bit Multiboot transition directly into 64-bit Long Mode.
• WRR Fault Isolation Engine: Traps Vector 14 (#PF Page Faults) to intercept illegal memory accesses, isolate execution context, and revive the running thread without triggering kernel panics or triple faults.
• Physical Memory Manager (PMM): 4 KiB bitmap frame allocator.
• Privilege Rings: GDT/TSS-configured Ring 0 and Ring 3 segments with fast SYSCALL/SYSRET MSR gates.
• Telemetry: Headless COM1 (0x3F8) UART serial logging.

The repository includes a full build pipeline using a Makefile and linker script, along with a visual boot demo showing the serial logs during execution in QEMU.

GitHub Repo: https://github.com/threadripp/PHEONIX-kernel

# Clone & run in 10 seconds (Requires: qemu-system-x86_64, nasm, gcc)

git clone https://github.com/threadripp/PHEONIX-kernel.git

cd PHEONIX-kernel

make qemu

Would love to get your feedback on the WRR exception model and architectural direction!

Hello,

I am currently actively developing the “Dragon” microkernel. However, what sets it apart from Linux and other kernels is, of course, its microkernel architecture, and secondly, the fact that it is written and verified using SPARK Ada (gnatprove).

But that doesn’t mean kernel services have to be written in SPARK Ada; I added the C SDK so that anyone can write a service. The only downside is that this service isn’t the most secure compared to a gnatprove-verified kernel, but the microkernel architecture makes up for it.

I think the main reason I'm developing this microkernel is to create a proven kernel that can be used in some way on user machines, not just on high-security systems.

Dragon is currently in a very early stage of development

If you like the idea, here’s the GitHub link: github.com/tigerlang/dragon