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

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

[Lukas Gerlach]

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@cs.kuleuven.be>
Signed-off-by: Jo Van Bulck <jo.vanbulck@cs.kuleuven.be>
Signed-off-by: Lukas Gerlach <lukas.gerlach@cispa.de>
Cc: Tristan Hornetz <tristan.hornetz@cispa.de>
Cc: Michael Schwarz <michael.schwarz@cispa.de>
Cc: Shukai Ni <shukai.ni@kuleuven.be>
---
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.

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
 ============================

--
2.51.0

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@cispa.de> (raw)
> In-Reply-To: <f75d286c-4d9e-4b64-8a9e-03e1afcb509f@kernel.org>
> 
> 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@cs.kuleuven.be>
> Signed-off-by: Jo Van Bulck <jo.vanbulck@cs.kuleuven.be>
> Signed-off-by: Lukas Gerlach <lukas.gerlach@cispa.de>
> Cc: Tristan Hornetz <tristan.hornetz@cispa.de>
> Cc: Michael Schwarz <michael.schwarz@cispa.de>
> Cc: Shukai Ni <shukai.ni@kuleuven.be>
> ---
> 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@zte.com.cn>

> 
> 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.

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

[David Hildenbrand (Arm)]

On 7/1/26 14:34, Lukas Gerlach wrote:
> 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@cs.kuleuven.be>
> Signed-off-by: Jo Van Bulck <jo.vanbulck@cs.kuleuven.be>
> Signed-off-by: Lukas Gerlach <lukas.gerlach@cispa.de>
> Cc: Tristan Hornetz <tristan.hornetz@cispa.de>
> Cc: Michael Schwarz <michael.schwarz@cispa.de>
> Cc: Shukai Ni <shukai.ni@kuleuven.be>
> ---
> 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.

Right.

> 
> 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.
> 
> 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.

Should we say here "... is effectively readable through side channels by every
... " ?

> +
> +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

Also good to mention here besides MADV_MERGABLE also "PR_SET_MEMORY_MERGE=1"

I remember that KSM can also be used by user space to break the Linux kernel
layout randomization. IIRC, the attack vector was Linux running inside a KSM VM,
and user space inside the VM wanting to break Linux' layout randomization.

Is that sufficiently covered by your text?

-- 
Cheers,

David