Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1810834pxb; Mon, 22 Feb 2021 11:27:57 -0800 (PST) X-Google-Smtp-Source: ABdhPJx1cdVED8P626J8AcgnexzHmRq95YCAKAoIz6RINhm71Zy9MlfqGUEzPEe2tAdZw1IygKN5 X-Received: by 2002:a17:906:3856:: with SMTP id w22mr22095230ejc.77.1614022076941; Mon, 22 Feb 2021 11:27:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614022076; cv=none; d=google.com; s=arc-20160816; b=folrkRV+fZf24dEq9hHuTm6NmxieGcg3MmpSjDn1o/XL4EVOR0/ooWWyjvCWZfuxzp bdiu8bieRTLXcxaA6dIDYYAXs8hgY0iNJ30St5JNnpL3EvGnbRnk8TIA+ie5fsrplUpq ga0RrtZsKrGTnQunSuNvUPeqp/Rmcx6+aPetGAh2ijBUfcgcuCnCnebTAIsdQ8lw1dCY i7WrwBqQ9zZLneRNBXMJM71oHR8MUjcd6iY1lO+30I9Qy+tQ0zLQDx6Znl+iGgKSrFmP ktRZVUnsDEF9iB5ugeicvQqq/ltDcG94P4WZYaF1riz+4GhTWL/tiGRhjHwUyGpviL3p BvMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=mL0bjhfITdu5839ghM56EtmuJ0mV3o1IEyaUJSuFMFs=; b=aFbiFCr85Sl5usCv2GwDLc1ikjdcp8/JcsXLS+2G8BrcxGFccte5DiCpuM9f42zSZL KB44rp2Fi33XIoaMQ+szyoL4V4IoYSLfpyAy7nNg5kJ0D84QNCcZ0mj0vvDh4P5+3efI xheHKicFgTeO+vx5zewtz1uRup1whJiJZd7JBO+XKXPji2Ed96x9Te5Wo+uP1DAttT3H 7fUYkSh6knXAxOgnaruv/6oiEU33vOredbC2bgfKjpGovK98SdCH9gsOkhgtJnXowNgg rKWVhArSqotrncpgqnlIPmHdonlSmLPQ4PV8Cpma/dp4A7SJdPvoh3oGVYsbe1vDUCY5 Poig== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=0VKXgI+d; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k13si12488331ejg.567.2021.02.22.11.27.32; Mon, 22 Feb 2021 11:27:56 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=0VKXgI+d; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230175AbhBVTXy (ORCPT + 99 others); Mon, 22 Feb 2021 14:23:54 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36812 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233238AbhBVTSp (ORCPT ); Mon, 22 Feb 2021 14:18:45 -0500 Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D92FAC06178C for ; Mon, 22 Feb 2021 11:17:52 -0800 (PST) Received: by mail-ej1-x62d.google.com with SMTP id e13so27895128ejl.8 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=ap5cDAxKGMFBFQjgBUA1gTFxvgrjSOTUg6od7deSoZw2zfCdGejbNIEcoMM/JI0FxK tA0gf17WdPI6vKdYH2je9tMBi6RzZjOTd3QAWhkb2uQ0E98YKpNbFI6JUjBa7UlocJU2 vemAo1hxF1eS5e8i2f4j0jR4VLvTievVXTZZyYI1OwEVizlCESqh4y3WBy/u3Xe8MNB6 d+5AopdrWELW8a1tE2JXHuEBZkFrs7RGVo5bmzTPA933TE0oBa+gMwo2NlyTDO5y6bvj vgwzpN7HTXBz2L5KEQF1jzo5ma1duxGunu1CQKy3cEeqjxB+DIaoSCbK8Gguscph5WgL 3sJg== X-Gm-Message-State: AOAM532iZ61cbIpXNpyt6ojJttyH8Q5J/gjPTfenCauMhvyOqGBrQg4p QwKm0ImRJeXjfAdtqma12uRdgohPaNCrU/ncUhohGw== 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" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.