* Re: [PATCH] mm/ksm: document side-channel security considerations
2026-07-01 12:34 ` [PATCH] mm/ksm: document side-channel security considerations Lukas Gerlach
@ 2026-07-01 14:18 ` xu.xin16
2026-07-01 15:27 ` David Hildenbrand (Arm)
1 sibling, 0 replies; 3+ messages in thread
From: xu.xin16 @ 2026-07-01 14:18 UTC (permalink / raw)
To: lukas.gerlach, akpm, david
Cc: akpm, corbet, linux-mm, linux-doc, linux-kernel, chengming.zhou,
skhan, lukas.gerlach, jo.vanbulck, tristan.hornetz,
michael.schwarz, shukai.ni
> 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.
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [PATCH] mm/ksm: document side-channel security considerations
2026-07-01 12:34 ` [PATCH] mm/ksm: document side-channel security considerations Lukas Gerlach
2026-07-01 14:18 ` xu.xin16
@ 2026-07-01 15:27 ` David Hildenbrand (Arm)
1 sibling, 0 replies; 3+ messages in thread
From: David Hildenbrand (Arm) @ 2026-07-01 15:27 UTC (permalink / raw)
To: Lukas Gerlach, akpm, corbet, linux-mm, linux-doc, linux-kernel
Cc: xu.xin16, chengming.zhou, skhan, Jo Van Bulck, Tristan Hornetz,
Michael Schwarz, Shukai Ni
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
^ permalink raw reply [flat|nested] 3+ messages in thread