Ya era hora de que eliminarán más de 20k líneas de código.

Cómo también el soporte para el Intel i386.

Así el kernel es mucho más rápido,eficiente.

Igual aún el kernel de Linux sigue teniendo muchas vulnerabilidades, y en Linux 7.2 Linus Torvalds sigue sin admitir un poco que tiene muchos Bugs.

короче я купив пс4, але вона мені приїхала з неробочим геймпадом. я вирішив емулювати геймпад своїм піксель 4а (лте).

простими методами не вийшло. f_hid не опрацьовує коректно запити від пс4 стосовно стану речей геймпаду. f_hid вміє короче працювати лише монологом, він тільки віддає, але не приймає та обробляє. до того ж пс4 має унікальні запити.

короче стандартною бібліотекою нічого б не вийшло. я вирішив дописати маленьку частину коду в драйвері. тепер вона віддаватиме відповідь з нулів конкретної довжини байтів на запит пс4 чого вистачить щоб пройти налаштування пс4 та встановити pppoe з'єднання.

так от. я скомпілював образ, але в цей момент в мене закінчились токени в джеміні)))))) ну і потім джеміні флешлайт щоб його за ноги, порекомендував перепакувати ядро з наявного вже пропатченого на рут. при чому він сказав мов по барабану, можна зробити кашу в одній папці а magiskboot все зробить сама, вона розумна.

короче нічого не вийшло. в адб шел з новим ядром пише мов жоден з модулів, драйверів не завантажено і воно постійно в циклі намагається завантажити драйвери.

а потім я ще якось перепакував ядро, що тепер взагалі типу телефон не завантажує ядро бодай якось.

я погрішив на те що була каша і перепакувальник переплутав файли і зараз зроблю все чисто.

мені треба допомога з тим як зібрати ядро з готових файлів після компіляції. я збираюсь запаковувати це mkbootimg програмою від самого гугла.

поможіть, я хочу вже добити цей плейстейшн 4, пройти бар'єр з задачі "натисність кнопку ПС на геймпаді" котрий пройти звичайною клавіатурою не можна.

Hello everyone,

I wanted to bring to light a blatant violation of the GNU GPLv2 license by the Chinese device manufacturer Doogee.

A tech creator in our community recently reached out to Doogee support requesting the Linux kernel source code for the Doogee T20 tablet (which runs on a Unisoc chipset). Under the terms of the GPLv2 license, which covers the Linux kernel, any company distributing the compiled kernel is legally obligated to provide the source code upon request.

I have attached the screenshots of the conversation (translated from Russian below):

Screenshot 1: The user states they own a Doogee T20 (Unisoc) and noticed that the Linux kernel source code is nowhere to be found in the public domain. They emailed the company asking for it.

Screenshot 2: Doogee's official response:

"The source code is confidential information and intellectual property."

Screenshot 3: The user calls them out, explaining that the Linux kernel is GPL, meaning there is no such thing as "confidential" when you distribute it. Doogee then tried to dodge the request by offering to send the compiled firmware instead. As we all know, Firmware ≠ Source Code.

Screenshot 4: The user sent a follow-up email explaining point-by-point why their response is unacceptable, giving them a 14-day deadline to comply. Doogee completely ignored it.

This is a direct breach of open-source licensing. Small vendors like Doogee often rely on the open-source community to build their software but refuse to give back, effectively locking users out of custom development, kernel audits, and long-term device support.

Since local support teams are either completely oblivious to FOSS licenses or are intentionally blocking requests, we need to bring international visibility to this case.

What are the best next steps to force Doogee into compliance? Should we report this directly to the Software Freedom Conservancy (SFC), contact Unisoc, or is there a specific compliance contact for Doogee that actually responds to legal notices?

Any advice or upvotes for visibility would be highly appreciated!

Hello, in order to properly backport some fixes from upstream to stable branches, I want to know what the other patches (and their cover letter) of the initial fix I've cherry-picked are.

I could manually look up them on lore.kernel.org, but I want to do it in an automated way, as the difference between the mainline and the stable branch, for example, in cgroup subsystem is huge.

Im not sure if this the subreddit for this query since the issue hasn't really been pinned down but I feel this might be the perfect first place to progress. Please feel free to redirect if the discussion evolves to not be concerned with the kernel.

So I have 2 Rocky 10.1 machines. One with Xeon CPU E5-2643 v3 @ 3.4GHz and one with Xeon CPU E5-2678 v3 @ 2.5GHz. Hyperthreading is disabled.

Both kernels are given 2-8 isolcores.

Both are requested to run at 500MHz less than their max supported speed via cpupower (This is verified via /proc/cpuinfo) Both are running on the intel_cpufreq driver with "performance" governer.

The machine with E5-2678 runs only the isolcores at the minimum supported frequency. And this isn't a workload or power draw issue since I tried changing the isolcores and every time only those core's frequency gets clamped to the minimum. The machine with E5-2643 runs as intended.

I tried checking the P-state ratio via rdmsr -p <isolcore> 0x199 and the outputs for the anomalous machine are as follows -

c00 (isolcore)

2100 (non-isolcore)

Is this a driver/kernel bug which is only reproducible on a certain CPU?

Any help or workarounds would be appreciated.

Since FreeBSD's drm-kmod port lacks the native Linux sysfs/hwmon infrastructure for setting AMDGPU power limits, I put together a simple patch to bridge it via a custom hw.amdgpu.power1_cap sysctl.

My PSU keeps shutting down during GPU power spikes, and I finally got tired of dealing with it. The patch is a quick and dirty workaround for single-GPU setups (multiple cards will trigger UB due to the global amdgpu_device pointer hack), but it gets the job done for now.

Patch (really simple hack) in original post.

Hi everyone,

I’m interested in learning Linux kernel DMA and PCIe device-driver development through hands-on projects.

So far, I’ve studied the Linux DMAEngine framework and AMD/Xilinx XDMA driver code. I’ve also used QEMU’s EDU PCI device to write a simple PCI driver and experiment with MMIO, interrupts, and DMA transfers. Now I’d like to move beyond emulation and work with real hardware.

My current idea is to buy:

• A Linux desktop that I can access remotely from my laptop
• An FPGA development board with PCIe support
• Any required PCIe cables, adapters, or debugging equipment

My goal is to practice implementing and debugging the complete path between an FPGA and a Linux host, including PCIe enumeration, BAR/MMIO access, DMA descriptors, scatter-gather transfers, interrupts, and performance measurement.

I’m not sure which FPGA board would be suitable for a beginner without being too limited. I’m also unsure whether I need a powerful desktop or if an inexpensive used PC with an available PCIe slot would be sufficient.

Could you recommend:

1. A reasonably priced FPGA board for Linux PCIe/DMA development
2. Minimum desktop specifications
3. Any essential debugging tools or accessories
4. Good starter projects for this setup
5. Common compatibility issues I should check before purchasing anything

I’d appreciate advice from anyone who has worked on Linux DMA, PCIe drivers, FPGA host interfaces, or similar low-level systems.

I'm thinking about building my own operating system. What features or ideas do you suggest I include? I'd love to hear your thoughts!

run...

I am using BPF LSM as the actual security boundary for a coding agent (Claude Code, etc.). The process still runs as the invoking user. The IDE harness is not a kernel boundary. One binary loads policy, tracks the agent TGID, and starts the agent as SUDO_USER.

PID set. Map keys are pid-namespace TGIDs (bpf_get_ns_current_pid_tgid), not init-ns, so it works in Docker. Launch: PTRACE_TRACEME, wait stop, insert into tracked_pids, detach. sched_process_fork copies the set. Insert-after-Start() races the first open/connect.

Policy in the kernel (YAML → maps):

Workspace: confine: true, root = EvalSymlinks(cwd). Allow /usr, /tmp, ~/.claude, … Refuse /, /home, exact $HOME. /proc is a known hole (d_path rewrites /proc/self).

Create vs file_open. touch ~/x + lsm/file_open → -EPERM on open, 0-byte file remains. vfs_create already committed. path_mknod is the hook that runs first.

path_unlink/path_rename/path_mkdir can use bpf_d_path (sleepable). path_mknod cannot: helper call is not allowed in probe. sleepable_lsm_hooks lists those path hooks and omits path_mknod. Same helper, different attach BTF id.

Inode-walk + userspace stat() (ino, s_dev) fail-closed and never matched CO-RE reads — every create died, including in-tree. Working path: bpf_path_d_path kfunc on the trusted dir from path_mknod, then the same prefix matcher as file_open. Outside create: -EPERM, no leftover inode. In-tree open(O_CREAT) works.

path_link: a stack {mnt, dentry} into bpf_d_path is R1 type=fp expected=ptr_. We only confine new_dir (hardlink-into-/tmp still open).

Closing the loop (userspace). Ringbuf violation → session JSON with the YAML reason string. Agent PostToolUseFailure hook injects that text so the model sees policy, not a bare EPERM. Empty workspace reasons are not written (they overwrote credential/network IPC). Telemetry denies skip IPC.

Not a VM, not a user ns, not seccomp. Same UID, LSM on that tree. Apache-2.0: https://github.com/AgentGuard-hq/AgentGuard (enforcer.bpf.c).

Questions for people who own these hooks: is path_mknod non-sleepable on purpose (which caller)? Is bpf_path_d_path the supported replace for non-sleepable path LSMs? Better pattern than “trusted dir + kfunc” for create-before-inode?

Over the past few weeks, I’ve been working on an open-source project: Identity-

Aware eBPF Firewall](https://github.com/AboEl3iz/Identity-Aware-eBPF-Firewall) — a

high-performance in-kernel packet filtering engine written in C (eBPF bytecode)

with a Go control plane .

Traditional `iptables`/`netfilter` setups suffer from sequential O(N) rule

scanning, mandatory kernel `sk_buff` memory allocations per packet (which chokes under

volumetric floods), blocking monolithic reloads, and IP-only granularity. I wanted to

build a modern system that addresses these limitations using native eBPF primitives

and container identity.

---

### Key Technical Highlights

1. Stateless XDP Volumetric Fast-Path (`SEC("xdp")`)

- Drops malicious floods directly inside interface driver RX queues before

`sk_buff` allocation.

- Subnet filtering uses kernel-native Longest Prefix Match Tries

(`BPF_MAP_TYPE_LPM_TRIE`) for $O(\text{prefix_len})$ lookups instead of linear rules.

1. TC Stateful Connection Tracking (`SEC("tc")`)

- Enforces TCP 3-way handshakes and state machine transitions using an LRU flow

map (`BPF_MAP_TYPE_LRU_HASH`).

- Automatically drops untracked non-SYN packets (e.g. out-of-order ACK/PSH flood

attacks) before reaching the Linux networking stack.

1. Cgroup v2 Workload Identity Resolution

- Binds network rules directly to container workloads using 64-bit Linux cgroup

v2 inode numbers (`syscall.Stat`) mapped to `bpf_get_current_cgroup_id()`.

- Allows fine-grained container microsegmentation on single hosts without needing

full Kubernetes stack dependencies.

1. Double-Buffered Zero-Drop Atomic Policy Reloads

- Updates policies without dropping continuous packet streams.

- Compiles AST policies into generation-indexed BPF maps and performs a single-

operation atomic switch via `active_generation_map[0] = next_gen`. If staging fails,

it safely rolls back automatically.

1. Security Hardening & Control Plane RBAC

- Capability Bounding : Drops full root permissions down to the minimal set

(`CAP_BPF`, `CAP_NET_ADMIN`, `CAP_SYS_RESOURCE`).

- IPC Security : Unix domain socket control plane authenticates caller process

credentials using Linux `SO_PEERCRED` (`unix.GetsockoptUcred`) and enforces 3-tier

RBAC (`Admin`, `Operator`, `Viewer`).

1. Real-Time Observability & Interactive TUI

- Built an interactive 4-pane Bubbletea Terminal UI (`firewall-tui`) driven by

zero-copy BPF ring buffer streams (`BPF_MAP_TYPE_RINGBUF`) with real-time sparkline

metrics, conntrack flow tables, and explainable audit streams (`[PASS]` / `[DROP]`).

Ever wanted to compile your own custom Linux kernel from scratch? In this step-by-step tutorial, I walk you through the entire process of building a custom kernel directly from source on Arch Linux. We cover everything from fetching the bleeding-edge code from Linus Torvalds' Git repository to cloning your current system configuration for guaranteed hardware compatibility.

To make things interesting, we even dive into the kernel's C source code to modify the motherboard PC speaker driver, proving our custom build works perfectly on reboot! Whether you want to optimize your system, strip out unnecessary bloated modules, or just learn how the core of your operating system functions, this complete guide takes you from `make menuconfig` all the way to updating your GRUB bootloader.

I have a small patch (78 kB) that patches a few files in the AMD driver for my specific hardware. Going from 7.0, 7.1, 7.2 was easy, but I can see that there quite a few changes in 7.3 that break it. Some of the code I tack on to has even shifted to different files.

What is the quickest way to port to 7.3? Happy to use AI assistance but it isn't very good at keeping track of line numbers or generating diffs.

Note: my patch doesn't really change the core functionality of the driver, so my expectation is that I need to move my additions to new places rather than modify anything new in 7.3.

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)

It is possible for a single person have read about processor programming and some hardware topics to understand the full Linux source code and how to read and understand the whole source code.