Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <6285bc01.1c69fb81.c4048.6665@mx.google.com>
Date:   Thu, 19 May 2022 03:39:43 +0000
From:   CGEL <cgel.zte@gmail.com>
To:     Jann Horn <jannh@google.com>
Cc:     akpm@linux-foundation.org, ammarfaizi2@gnuweeb.org,
        oleksandr@natalenko.name, willy@infradead.org, linux-mm@kvack.org,
        corbet@lwn.net, linux-kernel@vger.kernel.org,
        xu xin <xu.xin16@zte.com.cn>,
        Yang Yang <yang.yang29@zte.com.cn>,
        Ran Xiaokai <ran.xiaokai@zte.com.cn>,
        wangyong <wang.yong12@zte.com.cn>,
        Yunkai Zhang <zhang.yunkai@zte.com.cn>,
        Jiang Xuexin <jiang.xuexin@zte.com.cn>,
        Michal Hocko <mhocko@suse.com>,
        Hugh Dickins <hughd@google.com>,
        Linux API <linux-api@vger.kernel.org>,
        Daniel Gruss <daniel.gruss@iaik.tugraz.at>
Subject: Re: [PATCH] mm/ksm: introduce ksm_enabled for each process
References: <20220517092701.1662641-1-xu.xin16@zte.com.cn>
 <CAG48ez0riS60zcA9CC9rUDV=kLS0326Rr23OKv1_RHaTkOOj7A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAG48ez0riS60zcA9CC9rUDV=kLS0326Rr23OKv1_RHaTkOOj7A@mail.gmail.com>
Precedence: bulk

On Wed, May 18, 2022 at 04:31:26PM +0200, Jann Horn wrote:
> On Tue, May 17, 2022 at 11:27 AM <cgel.zte@gmail.com> wrote:
> > For now, if we want to use KSM to merge pages of some apps, we have to
> > explicitly call madvise() in application code, which means installed
> > apps on OS needs to be uninstall and source code needs to be modified.
> > It is very inconvenient because sometimes users or app developers are not
> > willing to modify their app source codes for any reasons.
> 
> As a sidenote: If you're going to enable KSM on your devices, I hope
> you're aware that KSM significantly reduces security -
> when cloud providers were using KSM, there were a bunch of papers that
> abused it for attacks. In particular, KSM inherently creates
> significant information leaks, because an attacker can determine
> whether a memory page with specific content exists in other apps
> through timing side channels. In the worst case, this could lead to an
> attacker being able to steal things like authentication tokens out of
> other apps.
> 
> If you see significant memory savings from enabling KSM, it might be a
> good idea to look into where exactly those savings are coming from,
> and look into whether there is a better way to reduce memory
> utilization that doesn't rely on comparing entire pages against each
> other.
> 
> See https://arxiv.org/pdf/2111.08553.pdf for a recent research paper
> that shows that memory deduplication can even make it possible to
> remotely (!) leak memory contents out of a machine, over the internet.
> 
> (On top of that, KSM can also make it easier to pull off Rowhammer
> attacks in some contexts -
> see https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_razavi.pdf
> .)

Thank you for your reply. The information you provided is very
meaningful. However, the administrator should have the right to decide
whether to use KSM. The kernel should provide a flexible mechanism to
use KSM. How to use KSM safely should be decided by the user's security
policy.