From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id F0900C433EF for ; Fri, 3 Dec 2021 02:56:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DBB8C6B0072; Thu, 2 Dec 2021 21:56:23 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D42AF6B0074; Thu, 2 Dec 2021 21:56:23 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BBCA16B0075; Thu, 2 Dec 2021 21:56:23 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0089.hostedemail.com [216.40.44.89]) by kanga.kvack.org (Postfix) with ESMTP id A48796B0072 for ; Thu, 2 Dec 2021 21:56:23 -0500 (EST) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 5D11F183BCA18 for ; Fri, 3 Dec 2021 02:56:13 +0000 (UTC) X-FDA: 78874969026.23.AAA872D Received: from mail-yb1-f173.google.com (mail-yb1-f173.google.com [209.85.219.173]) by imf14.hostedemail.com (Postfix) with ESMTP id F39436001987 for ; Fri, 3 Dec 2021 02:56:12 +0000 (UTC) Received: by mail-yb1-f173.google.com with SMTP id f186so5210379ybg.2 for ; Thu, 02 Dec 2021 18:56:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=mcSwEVV3L74Lz8W1o09yWpvzHlz/Zarr/lRvwobBgv4=; b=QA5ip1sD9KRTeBlMRjccMu2+IABtf5sPX1Xhpxh2K72/sosAAtrD9u/IV0H0OtOKpN u7aEH45MfrSWZwKr+ZnUVi4VgvldmBcsiTUgfNqSFV3Ydcjncm9fW+KKg7YpzvAItaur JJf3YzmGhM63u5VOs19lscKauc1m8yETEpFo3EvIuviEOXtotat2OnF2Rsy8Dyj9k5af 9fqjnrDkRQ+3MJVObZYqAv7Ipnui37x3oyOkn7941WY1pe8FyghVgdhMxnupSjLfCu+0 ZTwejZVURODPXC9eCd7+zt0TwLp02Mm3h1DPOuNYBfIbfwzriYCkiWdFQwTzDNePk+22 IaAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=mcSwEVV3L74Lz8W1o09yWpvzHlz/Zarr/lRvwobBgv4=; b=8N0wx6qYstrLhLJ8LqVVyjgxNeeBW1yshGGzCvu3lYaJQY183D3eBBgtPxTILFXLQ4 N9UA5LK7mVcuAAH1UwoWlFH6dDPDyc/1/V3WNhMDjXBB6k3oQBXEzO/RlMN0GdaQ+a5r b+1ZrOybOTpnTHlMmglZXIQ0JZSwBGLGUmJCfOkYcwa8Gl42M1dX6d0VAkrdrKtUc22/ s7n7mEGU6SrguvIcQDj0TJTj9sCIJXG3u6ZkG28nLr+n0JPk/7BMMHFIam3OhP0X/jQt 5xvPN8VOe2knfo43QDrFe3k+A/b/U4H81gOgPzenQirmbJLJ2X2y6jJMJ73npZZtnHw2 VLVA== X-Gm-Message-State: AOAM5326gs6WTmPg5bbNoZn5cRDqVuw1IVQXS3zi5Jwm77N1jVT0t1hE uLMl5gSD19j535y17IFDJxhn9gXUbQw5070WO8M= X-Google-Smtp-Source: ABdhPJyLBuv05Oy+ZYvBEP47D87Mpu7YWaNwh/EB1PjyCee/KHFindJezAJ26cGW5ntY28aM9IDsR4HLYC2N82xaHYQ= X-Received: by 2002:a25:aba3:: with SMTP id v32mr18414629ybi.358.1638500172177; Thu, 02 Dec 2021 18:56:12 -0800 (PST) MIME-Version: 1.0 References: <673c5628-da97-83d3-028f-46219f203caf@redhat.com> In-Reply-To: <673c5628-da97-83d3-028f-46219f203caf@redhat.com> From: fei luo Date: Fri, 3 Dec 2021 10:56:02 +0800 Message-ID: Subject: Re: [RFD] clear virtual machine memory when virtual machine is turned off To: david@redhat.com Cc: akpm@linux-foundation.org, mike.kravetz@oracle.com, arnd@arndb.de, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, xiaofeng.yan2012@gmail.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: k1x1zt8bbqufhxmumcnbtddpqydijwhu Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=QA5ip1sD; spf=pass (imf14.hostedemail.com: domain of morphyluo@gmail.com designates 209.85.219.173 as permitted sender) smtp.mailfrom=morphyluo@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: F39436001987 X-HE-Tag: 1638500172-457044 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: David Hildenbrand =E4=BA=8E2021=E5=B9=B412=E6=9C=882=E6= =97=A5=E5=91=A8=E5=9B=9B 20:47=E5=86=99=E9=81=93=EF=BC=9A > > > > > Although this part of memory will be cleared before being reused by > > > > user-mode programs , But the sensitive data staying in the memory > > > > for a long time will undoubtedly increase the risk of information leaka= ge, > > > > so I wonder whether it is possible to add a flag (like MAP_UNMAPZERO) > > > > to the mmap(2) system call to indicate that the mapped memory needs > > > > to be cleared zero when unmap called or when the program exits. > > > > it's not immediately clear to me why data of user space program #1 > should be more important than data of user space program #2 and why the > program should make that decision. > What I mean here is that by adding a flag to the mmap(2) system call to indicate that this memory will be cleared after munmap() called or the process exits, and no sensitive data will be left in the system memory, so as to avoid information leakage after the process exits.And the task of clearing memory needs to be done in the kernel > > > > Of course, the page clear operation not only occurs when unmap called > > > > or program exits, but also need to consider scenes such as page migrati= on, > > > > swap, balloon etc. > > What about page migration (who clears the old memory location?), > swapping (who clears the swap space, also considering zram?), writeback > (who clears file storage)? Also, as you indicate, MADV_DONTNEED, > MADV_FREE, FALLOC_FL_PUNCH_HOLE would need care ... > > To disable swapping you can use mlock(). To handle file storage ... > don't use files. You'd still have to handle any cases where physical > memory locations might be freed and land in the buddy, and for that we > do have ... > Yes, this feature needs to consider when page migration, the content of the old page needs to be cleared, and the swap space needs to be cleared before swap. Of course, for security reasons, swap can be prohibited. Here I just listed some of the changes involved, not all aspects. This feature is mainly aimed at clearing the memory of the virtual machine after shutdown, so it is more aimed at anonymous mapping and huge page mapping > > > > > > When reusing the page that has been cleared, there is no need to clear = it > > > > again, which also speeds up the memory allocation of user-mode programs= . > > > > > > Is this feature feasible? > > "init_on_free=3D1" for the system as a whole, which might sounds like wha= t > might tackle part of your use case. > This feature is mainly to prevent the used memory information from leaking, not to clear the memory before use. -- Thanks