The sidechannel LSM

Benefits for LWN subscribers

The primary benefit from subscribing to LWN is helping to keep us publishing, but, beyond that, subscribers get immediate access to all site content and access to a number of extra site features. Please sign up today!

Side-channel attacks are a reasonably well-known technique to exfiltrate information across security boundaries. Until relatively recently, concerns about these types of attacks were mostly confined to cryptographic operations, where the target was to extract secrets by observing some side channel. But with the advent of Spectre, speculative execution provides a new way to exploit side channels. A new Linux Security Module (LSM) is meant to help determine where a side channel might provide secrets to an attacker, so that a speculative-execution barrier operation can be performed.

In current kernels, a context switch from one process to another often necessitates a flush of the translation lookaside buffer (TLB) contents, which is done in switch_mm_irqs_off(). For x86, after the Spectre v2 mitigations, that function calls indirect_branch_prediction_barrier() when switching away from a process that is not allowed to core dump (i.e. does not have SUID_DUMP_USER set). The barrier (which is known as IBPB) is an expensive operation, so it is only done for "sensitive" processes that have turned off core dumps (e.g. GPG). Core dumps of a process can contain secrets of various sorts, such as keys or passwords.

However, there may be other sensitive processes that do not turn off core dumps but are still susceptible to this side channel, so a patch set from Casey Schaufler would allow LSMs to offer an opinion on whether the IBPB should be done. It adds a new LSM hook (task_safe_sidechannel()) that will return zero if there are no known side-channel worries or -EACCES if the LSM considers the context switch to be potentially sensitive. The patch set provides an LSM to check some security attributes of tasks and also adds checking to the SELinux and Smack LSMs so that they can report whether the security attributes they maintain indicate a potential side-channel concern.

The SELinux and Smack changes add an entry for the new hook. Each looks at the current task and the task to be switched to and renders a verdict on the side-channel safety of the switch. The SELinux hook considers the switch to be safe against side channels if the current task has FILE__READ access to the new task. For Smack, it is similar: "Smack considers its private task data safe if the current task has read access to the passed task."

The bulk of the patch set, though, is the new "sidechannel" LSM. It is enabled with the SECURITY_SIDECHANNEL kernel configuration option, but requires other options in order to actually do any checking. One of them assumes that all task switches are subject to side channels (SECURITY_SIDECHANNEL_ALWAYS), so it simply always returns -EACCES. The other three enable various checks:

• SECURITY_SIDECHANNEL_UIDS: checks if the tasks have different effective UIDs and reports side-channel susceptibility if so; this could have a high performance impact since most context switches are between tasks with different effective UIDs.
• SECURITY_SIDECHANNEL_CAPABILITIES: checks if the tasks have different sets of capabilities, which may mean the new task would be subject to side-channel attacks.
• SECURITY_SIDECHANNEL_NAMESPACES: checks if the tasks live in different user, PID, or control-group namespaces and returns -EACCES if so.

The comments on the patch set have been relatively light. Jann Horn has made several suggestions, most of which Schaufler has adopted; the patch set is now up to v3. One comment that has not been addressed in the patch set is Horn's request that the security checks look at the previous non-kernel task when switching away from the kernel. He went into more detail in a posting on v2 of the patch set:

The test in switch_mm_irqs_off() to decide whether to do the IBPB looks at the task structure; if it is a kernel thread, thus does not have an mm pointer to a process address space, the rest of the checks are shorted out. Schaufler didn't change that, though he did "touch" it by adding the new LSM hook call, so Horn's complaint is really about the existing test. Horn suggested keeping a copy of the metadata for the most recent non-kernel task in order to do that test, but Schaufler has not made that change; his argument was that those who are concerned about that kind of attack should probably simply enable the "always" option.

Schaufler was also concerned with finding a good mechanism to save the task metadata. Horn offered some suggestions, but noted that the obvious way to do so might not be favored in a hot path like context switching: "The obvious solution would be to take a refcounted reference on the old task's objective creds, but you probably want to avoid the resulting cache line bouncing..."

It certainly seems reasonable for the LSMs to get involved in the decision on whether a process might be susceptible to a side-channel attack from another process. The current "dumpable" test is a simple one, but likely ignores many sensitive processes. But context switching is an important function of the kernel and one that should be done as quickly as possible. Adding complexity there may not be particularly welcome, but there have been no complaints so far. Speculative execution is done as a performance optimization but clearly we are having to give some of that improvement back to work around the shortcomings of its implementation in some CPUs.

Note: you can avoid this step in the future by logging into your LWN account.