We detect memory map and reserved RAM areas as well as their length by INT 0x15 and 0xE820. That's abstraction created by BIOS developers. My question is: How BIOS developers themselves detect memory map without function and anything else?

I've been developing BlockOS, an independent x86_64 operating system written primarily in C/C++.

BlockOS is no longer just a basic kernel experiment. The project currently includes:

• x86_64 kernel
• VFS and multiple filesystem implementations
• ELF loader
• PCI/PCIe support
• VirtIO block/network/input drivers
• networking stack
• POSIX compatibility layer
• libc
• process and scheduler infrastructure
• framebuffer and GUI framework
• BX11/X11-related work
• ACPI support
• USB/xHCI development
• examples and driver development infrastructure

I'm looking for OS developers and especially Linux kernel / low-level C/C++ developers who would like to contribute.

Areas I'd particularly like help with:

• memory management / virtual memory
• SMP and multicore support
• ACPI
• PCIe
• USB/xHCI and USB HID
• device drivers
• filesystems/VFS
• networking
• POSIX/libc
• GUI/window management

The goal isn't to make another toy kernel. I want to develop BlockOS into a stable, usable general-purpose operating system that can eventually be used on real hardware.

You don't need to understand the whole codebase to contribute. Individual subsystems can be worked on independently.

GitHub: https://github.com/gurijb2016-afk/Blockos

If you're interested in OS development, kernel development, drivers, or low-level C/C++, feel free to comment or message me.

Contributions, testing, code review and technical discussion are all welcome.

Hey everyone! I've been working on a project called SysTrace, a Linux behavioral monitoring tool built mainly to learn more about Linux internals, system calls, and cybersecurity.

It uses ptrace to trace a process and monitor different types of activity, including:

File operations

Process execution

Network-related syscalls

Memory operations

I also added a simple rule-based detection system and experimented with using collected behavioral data for ML classification.

What would you improve next? I'm especially interested in opinions about the architecture and whether moving from ptrace toward eBPF would be a good next step.

Thanks !

github

S-AOS now beeps every 10s

After S-AOS gui update you can download the official documentation at : https://docs.google.com/document/d/1b7L1OLjRlmhxjdUiZSpdXE8eolonJtpU/edit?usp=sharing&ouid=115392823028978362459&rtpof=true&sd=true

Hey guys, I spent the last few months building lazybios, a C99 library for parsing SMBIOS/DMI tables. It's:

• Cross-platform Linux, Windows(ReactOS included), macOS OpenBSD, FreeBSD, NetBSD, SunOS, Haiku(BeOS), Minix, QNX(Some of these have almost the same backends).
• User-friendly(3 steps to ensure memory safety(At least as far as my tests go))
• Zero external dependencies (just libc)
• about 20k LOC, clean separated API
• Supports all SMBIOS types 0–46 and some OEM fields implemented from dmidecode used as a reference(I haven't copied any code).
• A decoded struct within the Type's struct that shows decoded field so you don't have to read the specification yourself
• Works on x86_64(probably on only x86 aswell), ARM, and probably on RISC-V(haven't heavily tested on it yet).

And a tool called lazydmi, a CLI tool that uses lazybios as the backend.

This is my first serious systems project. Would love feedback on the API design, memory safety and maybe some stars if you guys like it.

And btw, AI was used for the documentation, the github workflows and a part of the /dev/mem parser, that's it

lazybios: https://github.com/LazySeldi/lazybios
lazybios-docs: https://lazyseldi.github.io/lazybios
lazydmi: https://github.com/LazySeldi/lazydmi

hello S-AOS no has full gui support and shows a fully

Functioning RTC ( Real Time Clock )
it took me so long to do it (1.3weeks) Hope You enjoy it download it at :

https://saosdownload.share.zrok.io/
Hope you Enjoy It! and dont forget to add a review so i can know whats wrong

Hi everyone! I'm starting my first OS development project for x86 (32-bit), following the standard OSDev Wiki approach (using a minimal setup with boot.s, kernel.c, and a custom linker.ld script)

Been working pretty deep in the RPC internals lately and built this around the stuff that normally gets buried in the generated structures. It uses Ghidra headless to recover dispatch tables, method counts, opnums, parameter directions, NDR types, endpoints and security state from PE files, then ranks the interfaces using an AHP/Saaty-based model for the RPC surface instead of arbitrary weights. The output also keeps a receipt for the score and flags questionable dispatch-table recovery. No PDBs, no live endpoint mapper, no target execution.

I could not find published numbers for what post-quantum signature verification costs on small targets, so I measured it. Four crates, LMS/HSS verification plus measurement harnesses.

Three Rust-specific things came out of it.

First one. sha2 0.10 SHA-256 compiles to 3808 bytes on Cortex-M4F. sha2 0.11 compiles to 8776. Same algorithm, same target, same flags. Both versions end up linked in my workspace because different dependencies require different ones.

This means comparing whole verifier binaries mostly compares hash crates, not signature schemes. Ed25519 binary is around 64% unrolled SHA-512. So now every scheme is subtracted from baseline built with same hash it uses.

Second one. Adding second call site to small helper made LLVM stop inlining it at opt-level = "z". Reasonable decision. But forcing #\[inline(always)\] saves 408 bytes on Cortex-M0+ and costs 48 bytes on M4F and RISC-V. Different direction on different targets, so I keep the attribute because 16 KB boot ROM cares and 64 KB one does not.

Third one. Static stack analysis from -Z emit-stack-sizes plus call graph from disassembly does not give upper bound. On one binary 55 call sites cannot be resolved: indirect calls, tail calls compiled as branches, linker thunks. Every missing edge only makes answer smaller. Tool said 720 bytes, hardware said 1152.

Crates are no_std and allocation-free. Hash is behind trait, so software sha2 and ESP32 SHA peripheral both work. That trait design changed twice, and [DECISIONS.md](http://DECISIONS.md) has why.

Not audited. lms-verify passes RFC 8554 Appendix F vectors, which is not same thing.

https://github.com/mnaza/pqc-embedded

Pure golang low level toolkit.
Now implemented asm with gas syntax.
Disassembler too.
Now you can install static binary instead of monster like LLVM to build asm project.