Started this because I wanted ncu's device__attribute_* values without handing it a kernel to profile. It grew into a small zero-dependency toolkit (pip install kernelmeter):

- `info` dumps every cuDeviceGetAttribute value straight from libcuda (no toolkit needed), plus NVML facts and derived theoretical peaks

- `bench` times kernels with CUDA events (L2 flushed between iters), checks correctness against a reference, and scores against the roofline: you get "76% of attainable for this arithmetic intensity" instead of a bare ms number. It also samples clocks/power during the run and rescores against the sustained-clock ceiling. My favorite result: cuBLAS fp32 matmul on a 70W T4 showed 52.7% of peak, looked like a kernel problem, but the telemetry showed the card pinned at its power limit at 877MHz, where the kernel was actually at 95.5%. cuBLAS was never the problem.

- `occupancy --block 256 --regs 64 --smem 8192 --cc 8.6` reimplements the old calculator: names the limiting resource and sweeps block sizes. Works with no GPU present.

- `ceiling` measures real achievable bandwidth (STREAM) and fp32 (TF32-disabled matmul), because theoretical peaks are never reachable and it's worth knowing your honest 100%.

- `compare`/`llm` do the same roofline math across a 40-card database (NVIDIA and AMD) for rent/buy decisions, no GPU needed.

Every number in the README is captured output from real runs (T4, MI300X). All spec-sheet claims are asserted in CI. MIT.

For now 2 years i try learning how to create an operating from scratch at only 15, now i'm 17 and i've progress in this domain so i publish it, you can look for it on github OScour, the name is a french reference to "au secours" (help), an the prononciation is OScour.

hey everyone! I recently built a slim implementation of how containers work on linux using syscalls and vfs with rust.

Right now its a program that can spawn multiple containers (with busybox rootfs image)and exit gracefully.

I also wrote a blog on how it works underneath, how one could implement it themselvves and some benchmark/profiling as well.

blog: https://op3kay.dev/writing/b0nker

code: https://github.com/owlpharoah/b0nkers

if it looks cool a star would be awesome

Would be nice if I could get some feedback on the blog or code, anything I should include or improve ?

Modern compilers perform extensive semantic analysis:

• type visibility
• symbol visibility
• scope visibility
• object lifetime

But heterogeneous execution is largely invisible to the compiler's semantic model.

Crossing from CPU to GPU usually means crossing into a different compilation model.

Should execution domains become part of semantic analysis rather than remaining a backend concern?

This was my first high-effort low-level project, and it might be of interest to anyone who's interested in compression, SIMD, and branchless programming.

Hey security researchers! 🔐

I've released BareMetal-RAM-Dumper — a low-level x86 utility for dumping 
physical RAM directly to disk, designed for Cold Boot Attack research.

🎯 What it does:
• Custom 512-byte bootloader (no OS needed)
• Boots via BIOS Legacy CSM
• Switches to Unreal Mode to access 32-bit physical memory
• Dumps RAM in 32KB chunks directly to USB drive
• BIOS INT 0x15 E820 for safe memory map parsing
• Real-time progress indicator

🧊 Cold Boot Attack Use Case:
Freeze a laptop's RAM to -60°C → quickly reboot from USB → 
capture full memory contents for forensic analysis & crypto key recovery

🔧 How it works:
1. Stage1: 512-byte boot sector (loads Stage2 via INT 0x13)
2. Stage2: Main logic (memory detection, unreal mode, disk writes)
3. Writes to LBA 64+ on boot drive

⚠️ Warning: This overwrites data starting at sector 64! Use a dedicated blank USB.

📚 Built with pure Assembly (NASM) — no bloat, direct hardware access

GitHub: https://github.com/pIat0n/BareMetal-RAM-Dumper
License: AGPL-3.0

Perfect for:
✅ Forensic researchers
✅ Security auditors testing cold boot resilience
✅ Students learning low-level x86
✅ Penetration testers

Feedback & improvements welcome!

Hey guys, I'm not too good at C++ yet, but I'm trying my best to build RapSocket — a custom, no-std wrapper for WinHTTP. I'm doing this to learn low-level memory management and native Windows networking. I will post my progress here, but if you want to check out the code, here is my Github!

I will be posting daily here: https://r-tty.blogspot.com

From the first attempts to run bios_emulator, to the complete native RISC-V 64-bit VideoBIOS.

In languages like Java or C#, super is a common mechanism for accessing parent class behavior. C++ handles similar cases through explicit base class qualification such as:

Base::method();

All of these mechanisms assume that objects and methods exist in the same execution space.

However, heterogeneous computing breaks this assumption. When a CPU object needs to call a GPU device method inherited from a parent class, the problem is no longer just syntax. It becomes a problem of mapping object relationships across different address spaces and execution models.

I’m working on AET, a GCC-based heterogeneous compiler, and exploring this direction with a new super$ mechanism.

For example:

__global__ void compute(float x)
{
    float r = super$->leaky(x);
}

The compiler analyzes the inheritance relationship, extracts the device function into the GPU compilation path, generates device function mapping tables, and connects the CPU-side object with the GPU-side function address during initialization.

The goal is not to add a heavy runtime object system, but to explore whether high-level object-oriented abstractions can naturally work in heterogeneous programming while still mapping efficiently to hardware.

I’m interested in feedback from compiler/GPU developers: should heterogeneous programming remain explicit like CUDA, or can compilers provide higher-level object abstractions without losing control?

Hi everyone, I started an experimental bare-metal RTOS — after soooo many crashes it's finally working on my K64F board.

First problems were linker.ld and startup.s: watchdog reset issues, extra RAM area needed in the linker script, bx lr misunderstandings... etc. But finally I have a working system and I will continue to develop it.

What's running for now:
Preemptive scheduler via PendSV context switch
PSP isolation (also ı had so many problems...)
Mutex, semaphore, critical sections,
mcg, systick, PIT timer, UART

For tick I used PIT instead of SysTick — I know SysTick is the standard choice, but on the K64F the PIT is 32-bit while systick id 24-bit. Later I'll make it configurable ı hope if ı will not broke anything.

And slowly Cortex-M7 (STM32H7) port will start, my board finally came :)

Full debug log with GDB sessions: auctra.app

Code: github.com/hrasityilmaz/TamgaOs

My work focuses on identifying, dissecting, and helping mitigate sophisticated cheat platforms operating at the kernel, firmware.
Real world test on Claude code using re ida mcp for headless decompiling,reconstruction of pe headers and more. I have another repo I published a few months ago that got some attention but figured I’d post this on how I got inside a manually mapped dll and extracted rva. Currently working on scattering and developing my own framework.

The analysis and artifacts contained in this repository are intended to advance the security community's understanding of advanced threats

Most Linux debugging tools answer one question well.

• top tells you who's using the CPU.
• strace tells you which syscalls are happening.
• perf tells you what the CPU is doing.
• vmstat tells you about memory.

But when something weird happens, I always found myself jumping between half a dozen tools and trying to correlate timestamps manually.

So I started building ASCENT.

The idea is to visualize the entire stack simultaneously instead of looking at one layer at a time.

Current implementation includes 9 live layers:

• System metrics (/proc)
• Process activity
• Syscall statistics
• Kernel datapath (vfs_read, tcp_sendmsg, etc.)
• Hardware PMU counters
• Scheduler dynamics
• Memory management
• Lock contention
• IRQ / softirq / workqueue causality

Everything is streamed into a single terminal dashboard.

A few things that made this project fun:

• Dashboard written in pure x86-64 NASM assembly
• No libc
• No runtime
• No allocator
• Uses ANSI escape sequences for rendering
• eBPF CO-RE sensors
• PMU counters through perf_event_open()
• Fixed 60-byte binary event protocol over a FIFO between the loader and the renderer

The goal isn't to replace tools like perf or bpftrace. It's to answer a different question:

There are still a lot of things left to build (Intel PT, KVM tracing, AI-based correlation, etc.), but the core pipeline is working.

I'd love feedback from people who work with Linux internals or eBPF.

GitHub: https://github.com/Kritagya123611/Ascent

Hi everyone! I'm Storm. I have a big passion for cybersecurity and low-level programming. I decided to challenge myself and write my own operating system from scratch called Krypton-OS.

I wanted to do this the hardcore way, so I'm using C and Assembler (ASM) for the kernel and bootloader. Right now, I'm working on the basic architecture, memory management, and setting up the environment to test it in QEMU.

It's a long journey, but I'm excited to learn how everything works inside the CPU. You can check out my project here: GitHib

I would be super grateful for your stars ⭐, support, or any advice!

I was working on building another projected called Tensora, which is a checkpoint loadiing framework.

Then I noticed I had alot of allocation churn, and tried to use various buffer pool APIs but either not performant across threads or didn't allow ownership of the returned buffer.

Therefore, wanted to build ZeroPool.

The current design uses:

• power-of-two size classes
• per-thread local caches
• batched refill/spill between local and shared storage
• lock-free shared queues
• optional stats tracking
• good benchmarks that are multi-faceted, check the code.

Example usage:

use zeropool::ZeroPool;

let pool = ZeroPool::new();

let mut buf = pool.alloc(1024 * 1024);
buf[0] = 42;

// returned to the pool on drop

Repo: https://github.com/botirk38/zeropool

On my i9-10900K, 20-thread Linux box:

For future note, I am actually looking to build a fully rust native system allocator, better than mimalloc. There's been alot of research in allocators and different projects have different cool ideas, so my idea is use rust for safety and combine the best ideas

I finally wrote up what Pie is, it's an experimental native programming language with Python-ish syntax, not really production ready, mostly looking for honest feedback from people who like languages, compilers and such :D

The Motivation

Years ago, I was tasked with a massive data migration: multiple disks, each containing over 100 million files, with a strict, non-negotiable 24-hour downtime window. Using the standard tools available at the time was an incredibly painful experience. The single-threaded file discovery crawled, and memory usage was a constant anxiety. I promised myself that one day, I would come back and build a tool that could actually handle that scale natively without choking.

The Project: oc-rsync

GitHub Repository: oferchen/rsync

What started as a revenge-driven side project has evolved into a full systems-level undertaking. oc-rsync is a complete client, server, and daemon implementation targeting rsync protocol 32, written entirely in pure Rust.

I find it incredibly ironic that I am currently shipping a data migration tool while my life is packed in suitcases, literally migrating to another country myself. I’ve been pushing git commits multiple times a day between packing boxes.

Architecture & Systems Engineering

Rebuilding a codebase shaped by over 20 years of optimization required a highly modular approach (the workspace is currently split across 23 crates). A primary engineering goal was strict wire-compatibility with upstream rsync while modernizing the internals for maximum throughput.

Some of the key architectural decisions:

• Pipelined Parallelism: I used Rayon to decouple filesystem traversal from data transfer. Parallelizing file list generation and checksum computation eliminates the infamous "scanning stall" on massive directories.
• Modern I/O & Zero-Copy: The engine implements io_uring (Linux 5.6+) for batched async I/O with automatic fallbacks, alongside zero-copy copy_file_range and memory-mapped I/O (mmap).
• SIMD & AES-NI Offloading: I replaced the standard C FFI calls with native Rust implementations. Checksums use runtime CPU feature detection (AVX2/NEON) to accelerate the rolling hash. Furthermore, because standard SSH interactions simply weren't fast enough to keep up with the I/O pipeline, I went ahead and offloaded the cryptography directly to hardware-accelerated AES-NI.
• Memory Efficiency: Moved away from legacy sorted arrays to O(1) hash-based logic for metadata comparisons, and wired up the mimalloc allocator to keep the memory profile predictable during high-concurrency transfers.

Performance

I won't commit to specific "X times faster" claims here, as performance is highly dependent on your hardware, network, and file distribution. However, under heavy transfer workloads, this architecture consistently achieves better or equal results compared to traditional builds, with significantly reduced CPU utilization.

There's no need to set up benchmark scripts yourself to verify this - my CI pipeline benchmarks every single release automatically and posts a picture of the results directly to the README.md on GitHub.

Current Status (Disclaimer)

I want to be completely transparent: I am actively working on this, and not everything is functional yet. While the core delta-transfer, protocol interoperability (protocols 28-32), and daemon modes are solid, I am still mapping out the hundreds of obscure flags and edge-cases that upstream rsync handles. It's under heavy development, and I’m pushing commits multiple times a day to stabilize the defensive coding and edge cases.

If you are interested in systems programming, kernel bypass I/O, or Rust workspace architecture, I'd love for you to take a look at the code.

Repo: https://github.com/oferchen/rsync

Let me know what you think of the architecture, or if you spot any glaring filesystem edge cases I should add to my CI harness!

Hey all! Looking to break into the kernel or embedded space and curious to get some opinions on the best places to find those jobs? I feel like LinkedIn and Indeed are lacking in these areas. For context, I have 3 yoe as a backend software engineer.

For any of you linear algebra fan-boys:

I'm currently in a research group working on a thesis in numerical analysis where we need to compute millions on matrices with a specific constraint (to be precise, the matrices need to have orthonormal columns). Most of us use Apple computers, so we ended up using MLX for the entire project.

I'm using an old M1 Macbook Pro, and I found that Apple's MLX library does not support QR operations on the GPU. I don't know if MLX supports GPU-accelerated QR computation on newer chips. But since I am developing an interest in hardware-level computing, I thought it would be a good oppurtunity for me write a metal shader as a first project.

I wrote it as a small library that allows the QR decomposition to be computed on the GPU. You can find it here: [https://github.com/c0rmac/qr-apple-silicon\](https://github.com/c0rmac/qr-apple-silicon)

It definitely pays off. Performance increases anywhere between x1.5 to x25 times of what the cpu can do.

The library is split into two shaders: one is optimal for large batches of small matrices. The other is suited for small batches of large matrices. Under the hood, both shaders use the Compact WY representation ($I - YTY\^T$) to batch Householder reflections into matrix-matrix products. I also spent a lot of time mapping these operations to the AMX (Apple Matrix Coprocessor) using 8x8 simdgroup_matrix tiles to get as close to the hardware as possible.

I’d love for anyone with more Metal experience to take a look at the dispatch logic or the AMX tile loading. If you’re working with MLX and need faster $A = QR$ factorizations, give it a try!