<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Seccomp on Le Site de François</title><link>https://lesitedefrancois.be/en/tags/seccomp/</link><description>Recent content in Seccomp on Le Site de François</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>© 2026 François</copyright><atom:link href="https://lesitedefrancois.be/en/tags/seccomp/index.xml" rel="self" type="application/rss+xml"/><item><title>KVM/QEMU</title><link>https://lesitedefrancois.be/en/security/kvm-qemu/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/security/kvm-qemu/</guid><description>&lt;p&gt;&lt;strong&gt;KVM&lt;/strong&gt; (Kernel-based Virtual Machine) and &lt;strong&gt;QEMU&lt;/strong&gt; (Quick Emulator) solve different halves of the same problem and are almost always used together. &lt;strong&gt;KVM&lt;/strong&gt; is a Linux kernel module that turns the kernel into a hypervisor: with &lt;strong&gt;Intel VT-x&lt;/strong&gt; or &lt;strong&gt;AMD-V&lt;/strong&gt;, guest CPUs run on real hardware at near-native speed and guest memory is managed through extended page tables. KVM has no device model of its own — no disk, network, or firmware emulation. &lt;strong&gt;QEMU&lt;/strong&gt; supplies that in userspace (virtio, USB, VGA, ACPI) and controls KVM by issuing &lt;strong&gt;ioctl&lt;/strong&gt; calls on &lt;strong&gt;&lt;code&gt;/dev/kvm&lt;/code&gt;&lt;/strong&gt; — creating VMs, mapping memory, running vCPUs via &lt;code&gt;KVM_RUN&lt;/code&gt; — while &lt;strong&gt;QMP&lt;/strong&gt; exposes external management over a Unix socket. &lt;strong&gt;libvirt&lt;/strong&gt;, originally from Red Hat, sits above both: it translates &lt;strong&gt;domain XML&lt;/strong&gt; into QEMU command lines and lifecycle operations. The stack is the default on Linux: &lt;strong&gt;RHEL&lt;/strong&gt; ships &lt;code&gt;qemu-kvm&lt;/code&gt;, &lt;strong&gt;OpenShift Virtualization&lt;/strong&gt; runs &lt;strong&gt;KubeVirt&lt;/strong&gt; (&lt;code&gt;virt-launcher&lt;/code&gt; → libvirt → QEMU), and &lt;strong&gt;OpenShift Sandboxed Containers&lt;/strong&gt; uses &lt;strong&gt;Kata Containers&lt;/strong&gt; with the same hypervisor to isolate pods in micro-VMs.&lt;/p&gt;</description></item><item><title>Syscall (System Call)</title><link>https://lesitedefrancois.be/en/security/syscall/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/security/syscall/</guid><description>&lt;p&gt;A &lt;strong&gt;system call (syscall)&lt;/strong&gt; is the formal interface through which a user-space process asks the kernel to perform a privileged operation on its behalf — opening a file, allocating memory, creating a process, establishing a network connection, sending a signal, or any other action that requires kernel mediation. User-space code runs at CPU privilege level 3 (ring 3) and cannot directly access hardware, manipulate kernel data structures, or perform I/O; the kernel runs at ring 0 with unrestricted access. A syscall is the crossing point: the process places its request in a defined register convention and issues a &lt;code&gt;syscall&lt;/code&gt; instruction (on x86-64) that atomically switches the CPU to ring 0 and transfers control to the kernel&amp;rsquo;s syscall dispatch table. The kernel validates the request, performs the operation if permitted by standard Unix permissions and any active &lt;strong&gt;LSM&lt;/strong&gt; hooks, and returns the result. From a security perspective, the syscall boundary is the complete list of what a process can ask the kernel to do — and therefore the complete list of operations that security controls like &lt;strong&gt;seccomp&lt;/strong&gt; and &lt;strong&gt;BPF LSM&lt;/strong&gt; can police.&lt;/p&gt;</description></item></channel></rss>