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 E58E0C433EF for ; Thu, 2 Dec 2021 12:48:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4A67B6B0072; Thu, 2 Dec 2021 07:48:04 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 456456B0073; Thu, 2 Dec 2021 07:48:04 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 31D386B0074; Thu, 2 Dec 2021 07:48:04 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0205.hostedemail.com [216.40.44.205]) by kanga.kvack.org (Postfix) with ESMTP id 23D446B0072 for ; Thu, 2 Dec 2021 07:48:04 -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 E492089D5E for ; Thu, 2 Dec 2021 12:47:53 +0000 (UTC) X-FDA: 78872831226.28.0324F5E Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf10.hostedemail.com (Postfix) with ESMTP id 61277600198C for ; Thu, 2 Dec 2021 12:47:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1638449272; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/KE2G0AMF/4qelfuYaRJl7lFx9i78+mXpky9NUQaLvE=; b=brEe10ASWTu+I1lTRIeXqDsskeTH8vgWob2NUijaoopIov0orOEn/rayrwQ7EAtXvZCU0F zt615VD1RQlKVepHt4pXrCLiCXB7mwj2GFJOYlgcOfDaEY61kkFvmrqUQaLj1OHQb7j4Qy MNlvJPLe51NFp4ralM5UX7B2CQRFCdE= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-577-Vxhu62BsPfeNn3jsZFeGDg-1; Thu, 02 Dec 2021 07:47:51 -0500 X-MC-Unique: Vxhu62BsPfeNn3jsZFeGDg-1 Received: by mail-wr1-f72.google.com with SMTP id d18-20020adfe852000000b001985d36817cso5013031wrn.13 for ; Thu, 02 Dec 2021 04:47:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:references:from:organization:subject :in-reply-to:content-transfer-encoding; bh=/KE2G0AMF/4qelfuYaRJl7lFx9i78+mXpky9NUQaLvE=; b=wRpR7tdAGQuz0FTHl6FusDS6cI2RyvTM3xdSG4zv/qumKfnBeafMF1IGNGkZBnHORu 3Rl/aEnx9uoeuWSIJoImFespJRWSa8TSIuT3AYoWgsQoQAVibgKZysfAg5q7PuPOtl8F 7cZDy+DXUI270ruoICIOGODd+Aw3+0NFGeD1Uy04wgOld6aX3SwqkNUfGRwBCxW2CZoS 0N2jJSjMm2J1Yw0K6VfEgeEWu3rok3UtgAL9L/b6joxYTXDS8xKCQeNl/Io8d1iXy3/v qSp7w4oIUU8jDgInK+h98fhKrvVv++0Z28aTYMj4QZegPb2E7liVH9MURdafXX4HymOQ 0o8w== X-Gm-Message-State: AOAM531sPBfzJC6a1TK2heGi0lpPk+xH5tZbiP+hXBN1TUmD9qW6JDkr kIaaCt6wCqMrPxYdtsF/7QIEyTg9EmJ58L94/IPCUzjz3W7krloXS5DucXfiJCOq/7A0QsroOhj oKF9AHPUIAn4= X-Received: by 2002:a5d:4704:: with SMTP id y4mr14069728wrq.85.1638449270629; Thu, 02 Dec 2021 04:47:50 -0800 (PST) X-Google-Smtp-Source: ABdhPJxqhQFbTGgCi88qT+eGiKRbZJMiOQNTZSY0Ec9iA1YtsqGsT5YMm4zCKF/77tnNlZNp56fdSw== X-Received: by 2002:a5d:4704:: with SMTP id y4mr14069698wrq.85.1638449270341; Thu, 02 Dec 2021 04:47:50 -0800 (PST) Received: from ?IPV6:2003:d8:2f44:9200:3344:447e:353c:bf0b? (p200300d82f4492003344447e353cbf0b.dip0.t-ipconnect.de. [2003:d8:2f44:9200:3344:447e:353c:bf0b]) by smtp.gmail.com with ESMTPSA id m21sm2507081wrb.2.2021.12.02.04.47.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 02 Dec 2021 04:47:49 -0800 (PST) Message-ID: <673c5628-da97-83d3-028f-46219f203caf@redhat.com> Date: Thu, 2 Dec 2021 13:47:49 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 To: fei luo , 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 References: From: David Hildenbrand Organization: Red Hat Subject: Re: [RFD] clear virtual machine memory when virtual machine is turned off In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 61277600198C X-Stat-Signature: keebxzgr3rhb5njefgybq7hug88rcfna Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=brEe10AS; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf10.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=david@redhat.com X-HE-Tag: 1638449273-33332 Content-Transfer-Encoding: quoted-printable 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: On 02.12.21 11:19, fei luo wrote: > Hi, >=20 > When running the kvm virtual machine in Linux, because the virtual >=20 > machine=C2=A0may contain sensitive data, the user may not want these >=20 > data to remain in=C2=A0the=C2=A0memory after the virtual machine is tur= ned off. >=20 Hi, yes, just like if the VM is running. >=20 > Although this part of memory will be cleared before being reused by >=20 > user-mode=C2=A0programs , But the sensitive data staying in the memory >=20 > for a long time will=C2=A0undoubtedly increase the risk of information = leakage, >=20 > so I wonder whether it is=C2=A0possible to add a flag (like MAP_UNMAPZE= RO) >=20 > to the mmap(2) system call to=C2=A0indicate that the mapped memory=C2=A0= needs >=20 > to be cleared zero when=C2=A0unmap=C2=A0called or when the program exit= s. >=20 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. >=20 > Of course, the page clear operation not only occurs when unmap called >=20 > or program exits,=C2=A0but also need to consider scenes such as=C2=A0pa= ge migration, >=20 > 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 ... >=20 >=20 > When reusing the page that has been cleared, there is no need to clear = it >=20 > again,=C2=A0which also speeds up the memory allocation of user-mode pro= grams. >=20 >=20 > 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. --=20 Thanks, David / dhildenb