Operating systems: kernel, userland, processes, syscalls

What an operating system is for

A computer is a pile of hardware: a processor, some memory, a disk, a network card, a screen. Left to itself it does nothing useful. The operating system is the program that sits between that hardware and every other program, managing the hardware on their behalf and arbitrating between programs that would otherwise fight over it.

It exists for two reasons, and the second is the one that matters here. The first is sharing. A laptop runs dozens of programs at once, and only has one set of hardware to go around, so something has to decide which program gets the processor this millisecond and which has to wait. The second reason is isolation. Programs should not be able to reach into each other. A spreadsheet should not be able to read the memory of a password manager running in the next window, and a crashing music player should not be able to take the whole machine down with it. The operating system enforces walls between programs, and between every program and the hardware. Those walls are the security substance of the operating system, and the rest of this chapter is about how they are built.

Kernel and userland: the privilege boundary

Modern processors have a built-in notion of privilege. The hardware itself supports at least two modes of operation, and it will not let code running in the less privileged mode do certain things at all. On the processors that run laptops and servers these modes are called rings, and although the chip defines four of them, operating systems in practice use two: ring 0, the most privileged, and ring 3, the least.

Code running in ring 0 can do anything. It can read and write any byte of memory, talk to any device, and interfere with any running program. This is where the core of the operating system lives, and that core is called the kernel. The kernel is the part of the system that runs privileged, because its whole job is to manage the hardware and police everything else, and it cannot do that job from behind a wall.

Everything else runs in ring 3, unprivileged. This is userland: the territory where ordinary programs live. The browser is a userland program. So is Word, the desktop ChatGPT app if one is installed, the staff member's music player, and the photo viewer. A userland program cannot touch the hardware directly and cannot read another program's memory. When it wants to do anything beyond shuffling bytes around inside its own allotted space, it has to ask the kernel.

The line between ring 0 and ring 3, between the kernel and userland, is the privilege boundary. It is worth being precise about what kind of line it is, because the precision is the point. It is not a policy, a setting or a convention that software agrees to honour. It is enforced by the processor in silicon. A userland program that tries to execute a privileged instruction does not get a stern warning; the hardware refuses, and hands control back to the kernel to deal with the offending program. You cannot talk a processor out of this the way you can talk a misconfigured firewall out of a rule. The boundary holds because the transistors hold it.

This single line is the most important fact about a device for a defender. A security control that runs in userland has the powers of any other userland program, no more. A control that runs in the kernel can see and touch everything. Where a vendor's software sits relative to this boundary determines, before any feature is configured, the ceiling on what that software can possibly do.

Processes, memory and the clipboard

When the kernel runs a program, it runs it as a process. A process is a program in execution, and the kernel gives each one its own private view of memory, called its address space. The guarantee the kernel makes, and enforces with help from the processor's memory-management hardware, is that one userland process cannot read or write the memory of another. The browser's memory is the browser's alone. The password manager's secrets sit in the password manager's address space, invisible to the spreadsheet next door.

This isolation is why a single web page crashing should not crash the others, and why a curious program cannot simply reach into the browser and read what someone is typing. If reading another process's memory were free, there would be no security on a shared machine at all. The wall between address spaces is the same kind of wall as the privilege boundary: built into the hardware, enforced by the kernel, not negotiable from userland.

Programs do need to exchange data sometimes, and the kernel provides controlled ways for them to do it. The one that matters most for shadow AI is the clipboard. The clipboard is a shared buffer the operating system maintains, that any process can write to and any process can read from. When a staff member selects a paragraph in Outlook and presses copy, Outlook writes that text into the clipboard the operating system manages. When they switch to the browser and press paste, the browser reads it back out. The data has crossed from one process to another, and it did so by passing through a buffer the operating system controls.

That detail is the reason 'block copy and paste into AI tools' is a coherent control rather than a vague aspiration. The clipboard is a real place, managed by the operating system, that a sufficiently privileged piece of software can watch. A control that can observe the clipboard can see the patient data the moment it is copied, before it ever reaches a browser, a network or TLS. Hold that thought; it returns shortly.

Syscalls: the only door through the boundary

A userland process cannot open a file, send a network packet, draw on the screen or read the clipboard on its own, because all of those things mean touching hardware or resources the kernel manages, and userland is walled off from both. So how does the browser ever send your prompt to OpenAI?

It asks. The mechanism by which a userland process requests a privileged operation from the kernel is the system call, or syscall. A syscall is the single controlled doorway from userland into the kernel. The process places its request and arguments where the kernel expects them, executes a special instruction that transfers control across the privilege boundary, and the kernel takes over, checks that the request is allowed, does the work, and hands control back. Opening a file is a syscall. Sending bytes to a network socket is a syscall. Reading the clipboard is a syscall. Allocating more memory is a syscall.

Almost everything a program does that has any effect on the world outside its own address space happens through a syscall, which makes the syscall interface a chokepoint. A program's syscalls are a near-complete record of what it touched: every file it read, every network connection it opened, every time it reached for the clipboard. Software positioned to observe syscalls can therefore see what a process is actually doing, not what it claims to be doing. This is the architectural basis of endpoint detection, and Chapter 23 develops it properly. For now the point is narrower: the kernel sees every syscall by definition, because the syscall is a request made to the kernel, so a control that lives in or just below the kernel inherits that visibility, and a control stuck in userland does not.

Where a control has to sit to read a prompt

Now the model earns its keep. Return to the staff member pasting patient data into ChatGPT. We want to read that text before TLS encrypts it. The privilege model tells us there are exactly three places a control can be, and each has a fixed ceiling on what it can see.

The first place is inside the browser's own process. A browser extension runs here, and so does the browser's own built-in policy machinery. Code in this position has the browser's own view of the world: it can see the page, the contents of the form field, the characters as they are typed, because it is part of the process that holds them. It does not need to defeat memory isolation or hook the kernel, because it is already on the inside of the wall that matters. This is what the Microsoft Purview browser extension is, and it is what the inline data loss prevention built into Edge for Business is: software running with the browser's access to the page. (high) It explains a fact from the device-state report that otherwise looks surprising. Microsoft states plainly that Edge for Business inline DLP needs no device onboarding to work. (high) The reason is structural. The control lives in the browser, signed in to a work profile, not in a privileged agent below it, so it does not need anyone to have installed anything on the privileged side of the device. The browser is doing the watching, and the browser is already there.

The second place is below the browser, in or near the kernel. This is where an endpoint agent lives: endpoint detection and response, endpoint DLP, the privileged security software an organisation installs on a managed machine. Running privileged, it can observe syscalls, watch the clipboard, see which files are written and which network sockets open. It can read the pasted prompt, but only by a route that gets to the text before TLS does: by watching the clipboard as the paste happens, by hooking into the browser, or by relying on the in-browser extension to hand the data down to it. The agent's power is real, and it is also why endpoint DLP requires the device to be onboarded. (high) Installing a privileged agent is not something that happens by signing in to a website. It is an administrative act performed on a machine the organisation controls, which is to say it happens on a managed device and nowhere else.

The third place is off the device entirely, on the network, which is the whole of Part One. From out there a control sees encrypted bytes leaving for a Cloudflare address and learns nothing about their content, unless TLS inspection is in play, with all the cost and breakage Chapter 5 set out.

Seen this way, the blind spot of the personal laptop stops being mysterious. The prompt is unreadable on the wire because TLS encrypts it, and it is unreadable at the identity layer because a personal account never reaches the tenant IdP, so the only remaining place to read it is on the device, before encryption. On a personal laptop nobody with the organisation's authority has been allowed to install anything on the privileged side of the boundary. The one option that survives, the in-browser control, works only inside a signed-in work profile, and a staff member on their own machine can simply open a different browser, or the same browser without the work profile, and the control is not there.

This is also the deep structure of the six device states in the report. Underneath the Microsoft product names, the states are a ladder measured in exactly one quantity: how much the organisation has been permitted to place on the privileged side of this device's boundary. At the bottom, browser-only sign-in, the organisation has placed nothing on the device and can rely only on what the browser itself will enforce. At the top, the corporate standard operating environment, the organisation owns the privileged side outright and can run a full agent with kernel-level visibility. Every state in between is a point on that single axis, and Chapter 20 sets the ladder out rung by rung.

One more case follows directly. A desktop ChatGPT application, or a model run locally with a tool such as Ollama or LM Studio, is itself just a userland process. Whether it can be installed at all is a question of application allowlisting, the subject of the next chapter, and allowlisting is a control on the kernel side: it works by the privileged part of the system refusing to launch programs that are not approved. Like every other privileged control, it exists on a managed device and is absent on a personal one.

Last updated 9 August 2026