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 A5CABC433EF for ; Thu, 2 Dec 2021 10:42:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 13FC86B0072; Thu, 2 Dec 2021 05:42:06 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0C89D6B0073; Thu, 2 Dec 2021 05:42:06 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ED2646B0074; Thu, 2 Dec 2021 05:42:05 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0054.hostedemail.com [216.40.44.54]) by kanga.kvack.org (Postfix) with ESMTP id D7EF56B0072 for ; Thu, 2 Dec 2021 05:42:05 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id A1D7C86337 for ; Thu, 2 Dec 2021 10:41:55 +0000 (UTC) X-FDA: 78872513790.28.71A76AD Received: from mail-yb1-f179.google.com (mail-yb1-f179.google.com [209.85.219.179]) by imf05.hostedemail.com (Postfix) with ESMTP id 65764508B963 for ; Thu, 2 Dec 2021 10:41:55 +0000 (UTC) Received: by mail-yb1-f179.google.com with SMTP id v64so72072100ybi.5 for ; Thu, 02 Dec 2021 02:41:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=m5JL04vDvVP0L5N5migMb6NSCXdPubj2/VKuNaq+XiI=; b=eBi3Q4kCb6syXTo3iEwFbwriGPp6GE4eLe85/a3zx0SHECuMRF1m6ce/TvbbrZnma5 JVfeRXe/Yvo9iFiSdKVd7wClvXppaYYEQIY5+LK0k9bBIWGCzyYm8P5tAPApmk6iHBv8 c8Px+soczlUiZVsQbHAI7YV/tmcxj5ZWeNonhKpmwi22ICYkpc7mYV13Laestet3Bch8 z+IKgzyOy3OjcHFAAOAkpqv6E+sK/ZIWLKrdCoOgRaUMWqiVF3CIGXlmzStEYJ1QEUwb 84GEuNiUuQOx+kSC4oOtSSmuujvvlBGYuWaO/GBMKEyDFB2/IxxMgE/GC+wnIGe7egQx Gfeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=m5JL04vDvVP0L5N5migMb6NSCXdPubj2/VKuNaq+XiI=; b=T6V8KXu40rQyigC0qcrI9ndgYpDryFqsdIrKzjj5kyIT1TOXfwCMw2DtXLOX7uef00 58GB6rny7l/aNvgvp+EWy+JJXn9xSd0MrPmj2NBOg6ImMQlUeQzP/HaCQjnvHxYMzvwy JO+VvHO4c0OxcNG0ADJQ/MY8uPPosyhORTszAl3fVRyoZ9rrMirqw1EYKftDAyRsJV0j YD/fNXinLdlV1SJ3KWidYmn6KoxjiOW/cKJ2h1No5r0mNTjnGdzV6esfbo9kPL5MSkFR aMvYFKD4l7VMuTBImiTpAYG0uZF8jF9+tpKK0Xy8baTQkF8xjKp02fAsFi0aEciOWABu 1TBw== X-Gm-Message-State: AOAM533StWc3vK2I49WTqQttHaaHeVmLVlgGD8KjZRQOsBj7m8IUyoy4 ZoLAAzX/RzXp89m9GzHw+v/Yt84iTlxcIOd15syr9clfD7UuAA== X-Google-Smtp-Source: ABdhPJzzC3vpDaSSH8LjbvDWfHzCLmqqlhNKYuUrNvmFM70E+LI/IDssiDqwWYnKRhibt+SgvKEE46XrD4VVyWuzFgk= X-Received: by 2002:a25:fc24:: with SMTP id v36mr15056218ybd.588.1638441714603; Thu, 02 Dec 2021 02:41:54 -0800 (PST) MIME-Version: 1.0 From: fei luo Date: Thu, 2 Dec 2021 18:41:43 +0800 Message-ID: Subject: [RFD] Clear virtual machine memory when virtual machine is turned off To: mike.kravetz@oracle.com, akpm@linux-foundation.org, arnd@arndb.de, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 65764508B963 X-Stat-Signature: scnmif3a6yk4rghfftt8qb36d658mae3 Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=eBi3Q4kC; spf=pass (imf05.hostedemail.com: domain of morphyluo@gmail.com designates 209.85.219.179 as permitted sender) smtp.mailfrom=morphyluo@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-HE-Tag: 1638441715-531629 X-Bogosity: Ham, tests=bogofilter, spamicity=0.366042, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi, When running the kvm virtual machine in Linux, because the virtual machine may contain sensitive data, the user may not want this data to remain in the memory after the virtual machine is turned off. 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 leakage, 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 munmap(2) called or when the program exits. Of course, the page clear operation not only occurs when munmap(2) called or program exits, but also needs to consider scenes such as page migration, swap, balloon etc. 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?