MDE on Linux: Exclusions, fanotify, eBPF, and a Risk-Based Testing Framework

Why Linux exclusions need a different mindset

Exclusions are often treated as a simple policy change: “ignore this path” or “exclude this process.” On Linux, that framing is incomplete. Defender participates in file access paths and gathers behavioural signals at the kernel layer. Exclusions can reduce content inspection, but they do not automatically remove behavioural visibility.

How MDE works on Linux: fanotify, eBPF, wdavdaemon, and CPU behaviour

fanotify: the real-time protection decision point

MDE on Linux uses fanotify, a Linux kernel subsystem that can notify user-space when files are accessed or executed. With real-time protection enabled, this places Defender directly on the critical path for high-frequency file workloads. Exclusions influence how those inspection decisions are applied — they don’t remove Defender from the execution environment.

eBPF: behavioural detections beyond scanning

MDE on Linux also uses eBPF-based instrumentation for behavioural visibility. This layer contributes signals about process behaviour and suspicious syscall patterns that are independent of classic file-content scanning. That’s one reason an “exclusion” does not equal “invisible.”

wdavdaemon architecture: same name, different roles

On Linux you will typically see multiple processes with the same name: wdavdaemon. In steady state, they have different responsibilities:

• A root wdavdaemon managing telemetry and orchestration (health reporting and coordination).
• A root wdavdaemon managing policy and configuration state (control plane).
• A wdavdaemon running as the mdat user that performs on-demand RTP inspection.

Multithreading, scheduling, and CPU limits

The RTP path is multi-threaded and can spawn threads onto and off the scheduler under load. In many environments, Defender exhibits an effective ceiling of approximately 15% CPU per corein total. On a 4-core host, that can appear as ~60% aggregate usage (out of 400%), which is roughly 15% of total system CPU capacity — and it is not evenly distributed across CPUs. This is why latency spikes can occur even when overall utilisation looks “fine.”

Why stress testing comes before exclusions

Idle measurements rarely reveal Defender impact. Real issues show up under stress: file-open storms, short-lived file churn, frequent execution, and contention in I/O paths. We stress test first to establish a repeatable baseline and identify where the bottleneck actually is before any exclusion request is considered.

A note on our stress-testing script

We use a controlled stress-testing script to generate predictable access patterns and compare Defender behaviour before and after configuration changes. We don’t publish the full implementation because tooling without methodology is a fast way to create unsafe exclusions or misleading results. The important part is repeatability, safety, and correct interpretation.

Exclusion validation: before and after

• Before: baseline measurements under representative load and clear identification of contention points.
• After: the same workload, the same load profile, and the same observation points — confirming both performance improvement and that behavioural visibility remains appropriate.

A risk-based framework for Linux exclusions

Once the impact is measurable, exclusions should be evaluated as risk decisions:

• Scope discipline (file → process → narrow directory → broad directory as a last resort)
• Determinism (fixed binaries and predictable paths vs dynamic execution and user-controlled inputs)
• Asset criticality & exposure (internet-facing, privileged, lateral movement potential)
• Compensating controls (including behavioural detections that remain in effect)

The key insight

Stress testing tells you where Defender hurts. Exclusion testing tells you what changes. Risk analysis tells you whether the change is acceptable. Skipping any one of these steps is how exclusions become long-lived security debt.

If you need controlled MDE-on-Linux stress testing, exclusion validation, and a defensible governance model across a fleet, that’s where we can help.