Re: [PATCH] mm/ksm: document side-channel security considerations

[xu.xin16]

> Subject: [PATCH] mm/ksm: document side-channel security considerations
> Date: Wed, 1 Jul 2026 14:34:30 +0200	[thread overview]
> Message-ID: <20260701123430.20699-1-lukas.gerlach@xxxxxxxx> (raw)
> In-Reply-To: <f75d286c-4d9e-4b64-8a9e-03e1afcb509f@xxxxxxxxxx>
> 
> KSM is known to enable side channels, but the admin guide does not
> currently spell out the security implications of enabling page merging.
> Because KSM merges pages by content across all processes with mergeable
> memory, it forms a side channel that can be used to infer the contents
> of that memory across security domains, regardless of the user,
> container, or virtual machine the pages belong to.
> 
> Add a "Security considerations" section making this explicit, so that
> operators can make an informed decision: KSM should only be enabled for
> mutually trusting workloads, and any memory marked mergeable should be
> assumed readable by every other process using KSM.
> 
> Co-developed-by: Jo Van Bulck <jo.vanbulck@xxxxxxxxxxxxxx>
> Signed-off-by: Jo Van Bulck <jo.vanbulck@xxxxxxxxxxxxxx>
> Signed-off-by: Lukas Gerlach <lukas.gerlach@xxxxxxxx>
> Cc: Tristan Hornetz <tristan.hornetz@xxxxxxxx>
> Cc: Michael Schwarz <michael.schwarz@xxxxxxxx>
> Cc: Shukai Ni <shukai.ni@xxxxxxxxxxx>
> ---
> Hi David,
> 
> Thanks for the quick response.
> 
> I generally agree. The issue I see is that the current documentation
> understates the risk. The RHEL documentation ("could be potentially
> used to leak information across guests") does not read like enabling
> KSM is an arbitrary read across VMs, which the side channel we
> disclosed (in contrast to previous works) is. So the documentation
> should really state that KSM is only an option for mutually trusted
> workloads. A clean model for this would be to assume that memory
> marked as mergeable is readable by everyone else using KSM.
> 
> Patch below to clarify this in the admin guide. We would, in the
> future, publish a paper on this to further raise awareness of the
> risks involved with KSM.

It seems you have discovered a new information leakage attack method,
and we look forward to reading your paper. Meanwhile, we are currently
researching a domain-isolated KSM-merge and mechanism to defend against
similar attacks.

The following statement is essentially factual and deserve being documented.

Reviewed-by: Xu Xin <xu.xin16@xxxxxxxxxx>

> 
> Greetings,
> Lukas
> 
>  Documentation/admin-guide/mm/ksm.rst | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
> 
> diff --git a/Documentation/admin-guide/mm/ksm.rst b/Documentation/admin-guide/mm/ksm.rst
> index ad8e7a41f3b5..cbd5f2fdcfcb 100644
> --- a/Documentation/admin-guide/mm/ksm.rst
> +++ b/Documentation/admin-guide/mm/ksm.rst
> @@ -27,6 +27,23 @@ KSM's merged pages were originally locked into kernel memory, but can now
>  be swapped out just like other user pages (but sharing is broken when they
>  are swapped back in: ksmd must rediscover their identity and merge again).
> 
> +Security considerations
> +=======================
> +
> +Because KSM merges pages based on their content, across all processes
> +with mergeable memory regardless of which user, container, or virtual
> +machine they belong to, it exposes a side channel that can be used to
> +infer the contents of mergeable memory across security domains.  Users
> +should assume that any memory marked mergeable is readable by every
> +other process using KSM.
> +
> +KSM should therefore only be enabled for mutually trusted workloads, or
> +where the merged data is not sensitive; in particular, merging pages
> +across mutually untrusted virtual machines or tenants is not secure.
> +KSM is disabled by default (``run`` is 0).  Applications and VMMs that
> +use ``MADV_MERGEABLE`` should limit it to regions that do not hold
> +secrets.
> +
>  Controlling KSM with madvise
>  ============================

The above statement is essentially factual and deserve being documented.