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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1188DC433DB for ; Mon, 22 Feb 2021 19:17:55 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id AEE9864D74 for ; Mon, 22 Feb 2021 19:17:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AEE9864D74 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 266926B0070; Mon, 22 Feb 2021 14:17:54 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 23C726B006E; Mon, 22 Feb 2021 14:17:54 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 12C486B0070; Mon, 22 Feb 2021 14:17:54 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0101.hostedemail.com [216.40.44.101]) by kanga.kvack.org (Postfix) with ESMTP id F2BE46B0006 for ; Mon, 22 Feb 2021 14:17:53 -0500 (EST) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id B8A2768A1 for ; Mon, 22 Feb 2021 19:17:53 +0000 (UTC) X-FDA: 77846863626.16.03AF06B Received: from mail-ej1-f51.google.com (mail-ej1-f51.google.com [209.85.218.51]) by imf08.hostedemail.com (Postfix) with ESMTP id D772C80192E4 for ; Mon, 22 Feb 2021 19:17:42 +0000 (UTC) Received: by mail-ej1-f51.google.com with SMTP id t11so31092271ejx.6 for ; Mon, 22 Feb 2021 11:17:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mL0bjhfITdu5839ghM56EtmuJ0mV3o1IEyaUJSuFMFs=; b=0VKXgI+d4N8/TsZjQE/E5fkYxDFeC7KFxegFQ1tUDUQWXj1P6cXOsiH5slGqxqrmbb dBx4HcRD8Hzu5KRTHX5N1ybYz5yC5e7kYtwfTlsuU2esXKkYljaX8VDDRS1DaE/uHUin QAGppPvDyByXQFp+iE9GKGPwF3A2dB1mFytnHdtGJw+XJLGP5r33xK45enAbysyTaEHa 57tTo6DZyOE+uYzDNdPTZAL71cYVMSUiSI5K7sek4p2eMAFj1YmFFfuyLNvbSLKSE5kW D+y3PQVbEo19hoNoanDSrLywkZqhcPGuG5KVCRRj/oMJKHnyCwkRLTAD6EZO4JnoconN aV4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mL0bjhfITdu5839ghM56EtmuJ0mV3o1IEyaUJSuFMFs=; b=YHyB75wt8q7uQWeSH0tY+h7Lmb+KChcsY9oNRLggXGhA43HOP+yOsTUuWJOK9EMQV8 LDd0rnCdU8HvHroC67HUA+bFO1AsNXrJ83KRkGntobmtU6yl0ZjVJAUXju88PKyx93F6 p+E/ttK2eGE6gHH02kdqCCJRnT2tawpOjoTwA1h8v2BLL7Hs13kY5As9NMnsThuyUL+D mBLOv9Q3A0tGA3FvvlnPydN87Y1GgFaHBsdEvjAE6F/06x82J8JlmWB6kgXgE7eRI6V9 muWEoYpiYhtW8vJOwYor7NG1FRF3zKsgcvDkaQ4idgtqg+Ojf+xLCpIag1LwNK4hKfPP mN3g== X-Gm-Message-State: AOAM533GJqiQWnwvqar6ehJZ2gKwcoocv+Mvp/unXqjWINWWsqYvrds8 Ydoi7KVcehIi1VZyZTHf4mLu959olB843BfFvgAGqw== X-Google-Smtp-Source: ABdhPJwkiWshDLTsz8a3A7EzLjYNcKqX6Z1F01E3QE0NjkocZdW4txgaDcjEXqIRRI2IV4obwnL12Zk+rIG7YnuhZ4g= X-Received: by 2002:a17:906:8692:: with SMTP id g18mr22575502ejx.418.1614021471495; Mon, 22 Feb 2021 11:17:51 -0800 (PST) MIME-Version: 1.0 References: <20210208084920.2884-1-rppt@kernel.org> <20210208084920.2884-9-rppt@kernel.org> <20210222073452.GA30403@codon.org.uk> <20210222102359.GE1447004@kernel.org> In-Reply-To: <20210222102359.GE1447004@kernel.org> From: Dan Williams Date: Mon, 22 Feb 2021 11:17:46 -0800 Message-ID: Subject: Re: [PATCH v17 08/10] PM: hibernate: disable when there are active secretmem users To: Mike Rapoport Cc: Matthew Garrett , Andrew Morton , Alexander Viro , Andy Lutomirski , Arnd Bergmann , Borislav Petkov , Catalin Marinas , Christopher Lameter , Dave Hansen , David Hildenbrand , Elena Reshetova , "H. Peter Anvin" , Ingo Molnar , James Bottomley , "Kirill A. Shutemov" , Matthew Wilcox , Mark Rutland , Michal Hocko , Mike Rapoport , Michael Kerrisk , Palmer Dabbelt , Paul Walmsley , Peter Zijlstra , Rick Edgecombe , Roman Gushchin , Shakeel Butt , Shuah Khan , Thomas Gleixner , Tycho Andersen , Will Deacon , Linux API , linux-arch , Linux ARM , linux-fsdevel , Linux MM , Linux Kernel Mailing List , linux-kselftest@vger.kernel.org, linux-nvdimm , linux-riscv@lists.infradead.org, X86 ML , Hagen Paul Pfeifer , Palmer Dabbelt Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: D772C80192E4 X-Stat-Signature: mhz98bwuf5mhnaibaoxs6af9wpona563 Received-SPF: none (intel.com>: No applicable sender policy available) receiver=imf08; identity=mailfrom; envelope-from=""; helo=mail-ej1-f51.google.com; client-ip=209.85.218.51 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1614021462-877019 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 Mon, Feb 22, 2021 at 2:24 AM Mike Rapoport wrote: > > On Mon, Feb 22, 2021 at 07:34:52AM +0000, Matthew Garrett wrote: > > On Mon, Feb 08, 2021 at 10:49:18AM +0200, Mike Rapoport wrote: > > > > > It is unsafe to allow saving of secretmem areas to the hibernation > > > snapshot as they would be visible after the resume and this essentially > > > will defeat the purpose of secret memory mappings. > > > > Sorry for being a bit late to this - from the point of view of running > > processes (and even the kernel once resume is complete), hibernation is > > effectively equivalent to suspend to RAM. Why do they need to be handled > > differently here? > > Hibernation leaves a copy of the data on the disk which we want to prevent. Why not document that users should use data at rest protection mechanisms for their hibernation device? Just because secretmem can't assert its disclosure guarantee does not mean the hibernation device is untrustworthy.