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 43B56C433ED for ; Wed, 19 May 2021 01:50:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 29B8B61369 for ; Wed, 19 May 2021 01:50:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234198AbhESBvR (ORCPT ); Tue, 18 May 2021 21:51:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38948 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234117AbhESBvP (ORCPT ); Tue, 18 May 2021 21:51:15 -0400 Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 20870C06175F for ; Tue, 18 May 2021 18:49:56 -0700 (PDT) Received: by mail-ed1-x52c.google.com with SMTP id t3so13435125edc.7 for ; Tue, 18 May 2021 18:49:56 -0700 (PDT) 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=oy9iy31YW42GgULMnDfqqrgoX8PmHZpkik30uv+f1aA=; b=tvQ2E7Kd2+Hf+RN1JCJdnQu6RymaGP0zziznDt8ISnI+jG1I9F5rTtPCJWa6PikhKh XFhKmAAqHeMsUAOgy6hUDl59IPnHpchWu1cnHTyyjxMolBXIohuKR723SkE7OCNxzAbK oygZjSu1ZC0vRf3URWfxhzVNd3YMtTfsohBEjCi0q+/uREUxDQtHtMXYqH6q8d9eUBIB 218/C9Rmj+pEf1HRmaUjm/IPbnYkBLCQnR3DkYGpm/9v4+VmsDb6lUfsBZ8rq8wjdtNW PEFTJvZlWna6c3qGn3K9JEbsQ5ZbIkKlwDebT3ZVImG1L8u/VdgWTl83Y5Z5wVd6ZNag 17jA== 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=oy9iy31YW42GgULMnDfqqrgoX8PmHZpkik30uv+f1aA=; b=QaBqs2hX3Cr+ju2SF+ETOuXFAJShd2M0It1+06Peqj2iYeX9f+Xtog43cSK9ZdYhoA Mo5Y0s9Cj1heFA7rduM3s1FBe2OCE2Bl/kH+GSQ+pzlqHlzYFDVx4SYMaiIQ30IolnV1 3P8ID8OoR7PFcMSEZ1/UuSJoQi/T+FOlY2zWW1lNhyUceoBpoZJmbgKH0pA1o5hUpXtJ Vx2qzgeuVrxPGioQK3YERKw6viluCO7io7kyttVq1qbCwKsz12MfHvy16dYwvNvhTQCt xcwRcVbxWQerSlTjCoKq54tmVs/EpdU960BFCGOKGaFxD/bLpkl6/Qju6U018YEIiAPZ ruog== X-Gm-Message-State: AOAM530LWWWbGMsZPPx9N3rDpeR29WPTlmGXm1vumvK8e5DiKovS+TzC LitjJ2HB3rrqQuf7Qx1doVKNlcUvfthXPe9Z3DH9yQ== X-Google-Smtp-Source: ABdhPJzCebUO43WPo6zd3pAT6bxEi4LXjBLrk7zln8XX7z9KqzudweIVCjqD+YotU9S81wu4CFwPj9RiJ4aku6RH+xo= X-Received: by 2002:a50:ff13:: with SMTP id a19mr10495865edu.300.1621388993652; Tue, 18 May 2021 18:49:53 -0700 (PDT) MIME-Version: 1.0 References: <20210513184734.29317-1-rppt@kernel.org> <20210513184734.29317-7-rppt@kernel.org> <20210518102424.GD82842@C02TD0UTHF1T.local> In-Reply-To: From: Dan Williams Date: Tue, 18 May 2021 18:49:42 -0700 Message-ID: Subject: Re: [PATCH v19 6/8] PM: hibernate: disable when there are active secretmem users To: James Bottomley Cc: Mark Rutland , Mike Rapoport , Andrew Morton , Alexander Viro , Andy Lutomirski , Arnd Bergmann , Borislav Petkov , Catalin Marinas , Christopher Lameter , Dave Hansen , David Hildenbrand , Elena Reshetova , "H. Peter Anvin" , Hagen Paul Pfeifer , Ingo Molnar , Kees Cook , "Kirill A. Shutemov" , Matthew Wilcox , Matthew Garrett , Michal Hocko , Mike Rapoport , Michael Kerrisk , Palmer Dabbelt , Palmer Dabbelt , Paul Walmsley , Peter Zijlstra , "Rafael J. Wysocki" , Rick Edgecombe , Roman Gushchin , Shakeel Butt , Shuah Khan , Thomas Gleixner , Tycho Andersen , Will Deacon , Yury Norov , 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 Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 18, 2021 at 6:33 PM James Bottomley wrote: > > On Tue, 2021-05-18 at 11:24 +0100, Mark Rutland wrote: > > On Thu, May 13, 2021 at 09:47:32PM +0300, Mike Rapoport wrote: > > > From: Mike Rapoport > > > > > > 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. > > > > > > Prevent hibernation whenever there are active secret memory users. > > > > Have we thought about how this is going to work in practice, e.g. on > > mobile systems? It seems to me that there are a variety of common > > applications which might want to use this which people don't expect > > to inhibit hibernate (e.g. authentication agents, web browsers). > > If mobile systems require hibernate, then the choice is to disable this > functionality or implement a secure hibernation store. I also thought > most mobile hibernation was basically equivalent to S3, in which case > there's no actual writing of ram into storage, in which case there's no > security barrier and likely the inhibition needs to be made a bit more > specific to the suspend to disk case? > > > Are we happy to say that any userspace application can incidentally > > inhibit hibernate? > > Well, yes, for the laptop use case because we don't want suspend to > disk to be able to compromise the secret area. You can disable this > for mobile if you like, or work out how to implement hibernate securely > if you're really suspending to disk. Forgive me if this was already asked and answered. Why not document that secretmem is ephemeral in the case of hibernate and push the problem to userspace to disable hibernation? In other words hibernation causes applications to need to reload their secretmem, it will be destroyed on the way down and SIGBUS afterwards. That at least gives a system the flexibility to either sacrifice hibernate for secretmem (with a userspace controlled policy), or sacrifice secretmem using processes for hibernate. 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=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 D9AE3C433ED for ; Wed, 19 May 2021 01:50:21 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 60D7D6135F for ; Wed, 19 May 2021 01:50:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 60D7D6135F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Zl0bx7PqIUUVp+G7aHwiWCSdKkJ8x4fEVnwA97maZ1s=; b=njwWax1bK61nEpLYesgVwx4UZ /5br92/0Kz38XZvsZENwF4FLYfISSfMDjaS0PWmSjYIjaojDUJoENbqiv1c+xAWEKZMQBkc8YCJ4A JJbYco/Lxe1zKk4iCRvH/wBhMZWbH/et06Qx7nEjKfhY68bbt7O3AD1KtVl99pD2ASNJFQS8HCC5t 8vO76TGYGjHfdb9r1noqEaA3s+JaP6g9Mj06op/4OM5/jW47t3yY5hzDd/mKjZAaohFHsbLo+YOHl xARzTmqsX3cze8ad9lbDPEj5ZYfDuzVYc1wR1zlHco3pKeOv/kwC0bFaOcBVPw5ilMrSmvIKpm8Y7 Ab5fI+NvA==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1ljBLY-002OzQ-Ei; Wed, 19 May 2021 01:50:04 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1ljBLU-002OyR-GD for linux-riscv@desiato.infradead.org; Wed, 19 May 2021 01:50:02 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Type:Cc:To:Subject:Message-ID :Date:From:In-Reply-To:References:MIME-Version:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=oy9iy31YW42GgULMnDfqqrgoX8PmHZpkik30uv+f1aA=; b=suvoKTvClCPrcqBIGQ2K9NiYW2 /YUnq92wStuDzW5+hNBamyB76UkRKI4wWt5FuVute8g0qnwFWa3E7EXaiF4hsqXuIlbmgPgZVYZwE Kd6BorMekGqhvAiiZHUfyVaUPHvavTx6J0MxfUJ2l2l7NVweKFiYp2qSabCJLZNDy2pBOOo/cxW3b fvIjUghysPw/U3VTmrhS8k9/Oj/pa6L3AxCR9kQV0hfQp1JFZYG2ggTG/Bdbrv5ds2WjLKlINZaXi SvOpMcJiJeZ1zPudmdTpjTs4ZIjPQrHStUJj1hB3jGz2UQ23IhsbRGmeTkq7Q1ye5A4OMfYc9Zqlb uWbSJ/Pg==; Received: from mail-ed1-x529.google.com ([2a00:1450:4864:20::529]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1ljBLQ-00F4Ip-Tl for linux-riscv@lists.infradead.org; Wed, 19 May 2021 01:49:58 +0000 Received: by mail-ed1-x529.google.com with SMTP id a25so13414171edr.12 for ; Tue, 18 May 2021 18:49:54 -0700 (PDT) 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=oy9iy31YW42GgULMnDfqqrgoX8PmHZpkik30uv+f1aA=; b=tvQ2E7Kd2+Hf+RN1JCJdnQu6RymaGP0zziznDt8ISnI+jG1I9F5rTtPCJWa6PikhKh XFhKmAAqHeMsUAOgy6hUDl59IPnHpchWu1cnHTyyjxMolBXIohuKR723SkE7OCNxzAbK oygZjSu1ZC0vRf3URWfxhzVNd3YMtTfsohBEjCi0q+/uREUxDQtHtMXYqH6q8d9eUBIB 218/C9Rmj+pEf1HRmaUjm/IPbnYkBLCQnR3DkYGpm/9v4+VmsDb6lUfsBZ8rq8wjdtNW PEFTJvZlWna6c3qGn3K9JEbsQ5ZbIkKlwDebT3ZVImG1L8u/VdgWTl83Y5Z5wVd6ZNag 17jA== 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=oy9iy31YW42GgULMnDfqqrgoX8PmHZpkik30uv+f1aA=; b=PTHc0ME82+UlEX/PvmWrR4bX/T9hRBDfIuxzhumRTiWx+mxaXNGmaraXQDwu6tDvwV Lrvl4yWhGvKVyRzjRTiIgAAeCxPpppy58mRDSz6uKjy5YK1qdc6BUhcPxy9P+DIqPAtr jU/1I/7rMu7957PQtJTHottnWkWdOtrD5ObQgo4oRzBM4xqNAj+FVuzPLsPKJQqRxcmh q1QHqJNbzzmlE1QLrmlV5Z4Hjdtka6aOc7NXyKTY5ukXGEP3wwUFv6QBngbYPK67hExg JYIrwClPN3oaAlX+G6WKFq4InfzxImepLBnZFRa+qtBkZ7U03GZ5IqDQuUGoD7PP3V4d lMvg== X-Gm-Message-State: AOAM532hEJi2FXJDLYlXTfd+4V3oKuou9taACxjBgvlTwfbHeMA33H6N xoS8Sssi4kRiwp98roaTBj+UeV6kmLy7UNBEp0I9fA== X-Google-Smtp-Source: ABdhPJzCebUO43WPo6zd3pAT6bxEi4LXjBLrk7zln8XX7z9KqzudweIVCjqD+YotU9S81wu4CFwPj9RiJ4aku6RH+xo= X-Received: by 2002:a50:ff13:: with SMTP id a19mr10495865edu.300.1621388993652; Tue, 18 May 2021 18:49:53 -0700 (PDT) MIME-Version: 1.0 References: <20210513184734.29317-1-rppt@kernel.org> <20210513184734.29317-7-rppt@kernel.org> <20210518102424.GD82842@C02TD0UTHF1T.local> In-Reply-To: From: Dan Williams Date: Tue, 18 May 2021 18:49:42 -0700 Message-ID: Subject: Re: [PATCH v19 6/8] PM: hibernate: disable when there are active secretmem users To: James Bottomley Cc: Mark Rutland , Mike Rapoport , Andrew Morton , Alexander Viro , Andy Lutomirski , Arnd Bergmann , Borislav Petkov , Catalin Marinas , Christopher Lameter , Dave Hansen , David Hildenbrand , Elena Reshetova , "H. Peter Anvin" , Hagen Paul Pfeifer , Ingo Molnar , Kees Cook , "Kirill A. Shutemov" , Matthew Wilcox , Matthew Garrett , Michal Hocko , Mike Rapoport , Michael Kerrisk , Palmer Dabbelt , Palmer Dabbelt , Paul Walmsley , Peter Zijlstra , "Rafael J. Wysocki" , Rick Edgecombe , Roman Gushchin , Shakeel Butt , Shuah Khan , Thomas Gleixner , Tycho Andersen , Will Deacon , Yury Norov , 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210518_184956_968771_28E7A104 X-CRM114-Status: GOOD ( 27.58 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org On Tue, May 18, 2021 at 6:33 PM James Bottomley wrote: > > On Tue, 2021-05-18 at 11:24 +0100, Mark Rutland wrote: > > On Thu, May 13, 2021 at 09:47:32PM +0300, Mike Rapoport wrote: > > > From: Mike Rapoport > > > > > > 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. > > > > > > Prevent hibernation whenever there are active secret memory users. > > > > Have we thought about how this is going to work in practice, e.g. on > > mobile systems? It seems to me that there are a variety of common > > applications which might want to use this which people don't expect > > to inhibit hibernate (e.g. authentication agents, web browsers). > > If mobile systems require hibernate, then the choice is to disable this > functionality or implement a secure hibernation store. I also thought > most mobile hibernation was basically equivalent to S3, in which case > there's no actual writing of ram into storage, in which case there's no > security barrier and likely the inhibition needs to be made a bit more > specific to the suspend to disk case? > > > Are we happy to say that any userspace application can incidentally > > inhibit hibernate? > > Well, yes, for the laptop use case because we don't want suspend to > disk to be able to compromise the secret area. You can disable this > for mobile if you like, or work out how to implement hibernate securely > if you're really suspending to disk. Forgive me if this was already asked and answered. Why not document that secretmem is ephemeral in the case of hibernate and push the problem to userspace to disable hibernation? In other words hibernation causes applications to need to reload their secretmem, it will be destroyed on the way down and SIGBUS afterwards. That at least gives a system the flexibility to either sacrifice hibernate for secretmem (with a userspace controlled policy), or sacrifice secretmem using processes for hibernate. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv 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 3524BC433ED for ; Wed, 19 May 2021 01:50:57 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D5D306135F for ; Wed, 19 May 2021 01:50:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D5D306135F 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 67A0C8E0069; Tue, 18 May 2021 21:50:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 653568E002F; Tue, 18 May 2021 21:50:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4F1A38E0069; Tue, 18 May 2021 21:50:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0220.hostedemail.com [216.40.44.220]) by kanga.kvack.org (Postfix) with ESMTP id 20C0E8E002F for ; Tue, 18 May 2021 21:50:56 -0400 (EDT) Received: from smtpin37.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id BD84E180AD838 for ; Wed, 19 May 2021 01:50:55 +0000 (UTC) X-FDA: 78156302070.37.16D668C Received: from mail-ed1-f54.google.com (mail-ed1-f54.google.com [209.85.208.54]) by imf15.hostedemail.com (Postfix) with ESMTP id 542CAA0001BB for ; Wed, 19 May 2021 01:49:54 +0000 (UTC) Received: by mail-ed1-f54.google.com with SMTP id v5so13404244edc.8 for ; Tue, 18 May 2021 18:49:54 -0700 (PDT) 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=oy9iy31YW42GgULMnDfqqrgoX8PmHZpkik30uv+f1aA=; b=tvQ2E7Kd2+Hf+RN1JCJdnQu6RymaGP0zziznDt8ISnI+jG1I9F5rTtPCJWa6PikhKh XFhKmAAqHeMsUAOgy6hUDl59IPnHpchWu1cnHTyyjxMolBXIohuKR723SkE7OCNxzAbK oygZjSu1ZC0vRf3URWfxhzVNd3YMtTfsohBEjCi0q+/uREUxDQtHtMXYqH6q8d9eUBIB 218/C9Rmj+pEf1HRmaUjm/IPbnYkBLCQnR3DkYGpm/9v4+VmsDb6lUfsBZ8rq8wjdtNW PEFTJvZlWna6c3qGn3K9JEbsQ5ZbIkKlwDebT3ZVImG1L8u/VdgWTl83Y5Z5wVd6ZNag 17jA== 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=oy9iy31YW42GgULMnDfqqrgoX8PmHZpkik30uv+f1aA=; b=OGBMvgprnfRQJfFTPoKXztRJJJMcIM72NyxNrj2qz54i/pJspWhAbMabPsYrfdj+53 d6I4L0/5Ko1+8Hc2etW63CeqdJ/D+k1dXja1lmp5ljDFtKIlIaI2SWa/6WV9rF4Q45Lq syGzXyQuvxM2npuEllSbX96pqAHSzA2nWjLCPkaPK+wEACcG4guyh2pffj61Au1PlwB6 55cY7ZS5+lO3ETHU7V+sSLG+1SMw7y6nRIVZ6k8+ltjk3mguLyauvbxcjwgLbTdkq9s6 mX2Q5cJQQBupEv5IsXTVe0zrDtkT1vuW3Ck0ZHp3qmEfp6m8Z+5/CyB6z7fGnEts0ilR 0cIw== X-Gm-Message-State: AOAM532j9jO6Pr1GUZJZ9vg0ekaaIhl8TF2ne6UePCOpMJfE27Txek+U OuTOWvJCkLKe6QPuI+67bzJ5Y+3FQz6AJieSvGK2xQ== X-Google-Smtp-Source: ABdhPJzCebUO43WPo6zd3pAT6bxEi4LXjBLrk7zln8XX7z9KqzudweIVCjqD+YotU9S81wu4CFwPj9RiJ4aku6RH+xo= X-Received: by 2002:a50:ff13:: with SMTP id a19mr10495865edu.300.1621388993652; Tue, 18 May 2021 18:49:53 -0700 (PDT) MIME-Version: 1.0 References: <20210513184734.29317-1-rppt@kernel.org> <20210513184734.29317-7-rppt@kernel.org> <20210518102424.GD82842@C02TD0UTHF1T.local> In-Reply-To: From: Dan Williams Date: Tue, 18 May 2021 18:49:42 -0700 Message-ID: Subject: Re: [PATCH v19 6/8] PM: hibernate: disable when there are active secretmem users To: James Bottomley Cc: Mark Rutland , Mike Rapoport , Andrew Morton , Alexander Viro , Andy Lutomirski , Arnd Bergmann , Borislav Petkov , Catalin Marinas , Christopher Lameter , Dave Hansen , David Hildenbrand , Elena Reshetova , "H. Peter Anvin" , Hagen Paul Pfeifer , Ingo Molnar , Kees Cook , "Kirill A. Shutemov" , Matthew Wilcox , Matthew Garrett , Michal Hocko , Mike Rapoport , Michael Kerrisk , Palmer Dabbelt , Palmer Dabbelt , Paul Walmsley , Peter Zijlstra , "Rafael J. Wysocki" , Rick Edgecombe , Roman Gushchin , Shakeel Butt , Shuah Khan , Thomas Gleixner , Tycho Andersen , Will Deacon , Yury Norov , 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 Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=intel-com.20150623.gappssmtp.com header.s=20150623 header.b=tvQ2E7Kd; spf=none (imf15.hostedemail.com: domain of dan.j.williams@intel.com has no SPF policy when checking 209.85.208.54) smtp.mailfrom=dan.j.williams@intel.com; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=intel.com (policy=none) X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 542CAA0001BB X-Stat-Signature: m5igi4ar99zffzs4ytgqf4fg81yagzwa X-HE-Tag: 1621388994-152692 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 Tue, May 18, 2021 at 6:33 PM James Bottomley wrote: > > On Tue, 2021-05-18 at 11:24 +0100, Mark Rutland wrote: > > On Thu, May 13, 2021 at 09:47:32PM +0300, Mike Rapoport wrote: > > > From: Mike Rapoport > > > > > > 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. > > > > > > Prevent hibernation whenever there are active secret memory users. > > > > Have we thought about how this is going to work in practice, e.g. on > > mobile systems? It seems to me that there are a variety of common > > applications which might want to use this which people don't expect > > to inhibit hibernate (e.g. authentication agents, web browsers). > > If mobile systems require hibernate, then the choice is to disable this > functionality or implement a secure hibernation store. I also thought > most mobile hibernation was basically equivalent to S3, in which case > there's no actual writing of ram into storage, in which case there's no > security barrier and likely the inhibition needs to be made a bit more > specific to the suspend to disk case? > > > Are we happy to say that any userspace application can incidentally > > inhibit hibernate? > > Well, yes, for the laptop use case because we don't want suspend to > disk to be able to compromise the secret area. You can disable this > for mobile if you like, or work out how to implement hibernate securely > if you're really suspending to disk. Forgive me if this was already asked and answered. Why not document that secretmem is ephemeral in the case of hibernate and push the problem to userspace to disable hibernation? In other words hibernation causes applications to need to reload their secretmem, it will be destroyed on the way down and SIGBUS afterwards. That at least gives a system the flexibility to either sacrifice hibernate for secretmem (with a userspace controlled policy), or sacrifice secretmem using processes for hibernate. 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.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 B4575C433B4 for ; Wed, 19 May 2021 01:50:01 +0000 (UTC) Received: from ml01.01.org (ml01.01.org [198.145.21.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1282961361 for ; Wed, 19 May 2021 01:49:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1282961361 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-nvdimm-bounces@lists.01.org Received: from ml01.vlan13.01.org (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id D7AB6100F2276; Tue, 18 May 2021 18:49:58 -0700 (PDT) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2a00:1450:4864:20::52d; helo=mail-ed1-x52d.google.com; envelope-from=dan.j.williams@intel.com; receiver= Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 761AC100EF25B for ; Tue, 18 May 2021 18:49:56 -0700 (PDT) Received: by mail-ed1-x52d.google.com with SMTP id h16so13434724edr.6 for ; Tue, 18 May 2021 18:49:56 -0700 (PDT) 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=oy9iy31YW42GgULMnDfqqrgoX8PmHZpkik30uv+f1aA=; b=tvQ2E7Kd2+Hf+RN1JCJdnQu6RymaGP0zziznDt8ISnI+jG1I9F5rTtPCJWa6PikhKh XFhKmAAqHeMsUAOgy6hUDl59IPnHpchWu1cnHTyyjxMolBXIohuKR723SkE7OCNxzAbK oygZjSu1ZC0vRf3URWfxhzVNd3YMtTfsohBEjCi0q+/uREUxDQtHtMXYqH6q8d9eUBIB 218/C9Rmj+pEf1HRmaUjm/IPbnYkBLCQnR3DkYGpm/9v4+VmsDb6lUfsBZ8rq8wjdtNW PEFTJvZlWna6c3qGn3K9JEbsQ5ZbIkKlwDebT3ZVImG1L8u/VdgWTl83Y5Z5wVd6ZNag 17jA== 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=oy9iy31YW42GgULMnDfqqrgoX8PmHZpkik30uv+f1aA=; b=QWRsurxIUsECw+b1vbxCLnHWiEC8D1NLb1oDyEw6ygko1rHg+6nCdr0yBT2ARsBcFZ LjMy+5ZnzmxvCtYwmFnCZF4a5U6GF9Q++KbdN5gg1v3T6/oG9hv+QampmIpErivJx1Hp BkXnep0saQeEiDpg7DWY6uhZgk39wW/6SH1nIT/WZGLyNOHB/R8Jm3v0IjbUDC64LoA1 ux35T/hGhwleP+bQYAeVuW/ObS6+sMnF4GjNJShjMRhqoJOBXXKguu2cWUJaBPMbCky+ yLMTQWZC2qCstsHzYeOmgXOBFIEt0X5ah98rOB33f+Fi5T40KGJBniJfbGNgshRtMBVs FptQ== X-Gm-Message-State: AOAM530t/sniRT1HQYfBjo2BnL+4c7vKq3a5VkZLQqUInhQuTb5DJkcr uyts36aIM+iiU3d6c3eljiwYxto6zLshzVP6AQacHA== X-Google-Smtp-Source: ABdhPJzCebUO43WPo6zd3pAT6bxEi4LXjBLrk7zln8XX7z9KqzudweIVCjqD+YotU9S81wu4CFwPj9RiJ4aku6RH+xo= X-Received: by 2002:a50:ff13:: with SMTP id a19mr10495865edu.300.1621388993652; Tue, 18 May 2021 18:49:53 -0700 (PDT) MIME-Version: 1.0 References: <20210513184734.29317-1-rppt@kernel.org> <20210513184734.29317-7-rppt@kernel.org> <20210518102424.GD82842@C02TD0UTHF1T.local> In-Reply-To: From: Dan Williams Date: Tue, 18 May 2021 18:49:42 -0700 Message-ID: Subject: Re: [PATCH v19 6/8] PM: hibernate: disable when there are active secretmem users To: James Bottomley Message-ID-Hash: PPTELKUQPWSN4F7ECP5OCM32NPWRNXKL X-Message-ID-Hash: PPTELKUQPWSN4F7ECP5OCM32NPWRNXKL X-MailFrom: dan.j.williams@intel.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header CC: Mark Rutland , Mike Rapoport , Andrew Morton , Alexander Viro , Andy Lutomirski , Arnd Bergmann , Borislav Petkov , Catalin Marinas , Christopher Lameter , Dave Hansen , David Hildenbrand , Elena Reshetova , "H. Peter Anvin" , Hagen Paul Pfeifer , Ingo Molnar , Kees Cook , "Kirill A. Shutemov" , Matthew Wilcox , Matthew Garrett , Michal Hocko , Mike Rapoport , Michael Kerrisk , Palmer Dabbelt , Palmer Dabbelt , Paul Walmsley , Peter Zijlstra , "Rafa el J. Wysocki" , Rick Edgecombe , Roman Gushchin , Shakeel Butt , Shuah Khan , Thomas Gleixner , Tycho Andersen , Will Deacon , Yury Norov , 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 X-Mailman-Version: 3.1.1 Precedence: list List-Id: "Linux-nvdimm developer list." Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Tue, May 18, 2021 at 6:33 PM James Bottomley wrote: > > On Tue, 2021-05-18 at 11:24 +0100, Mark Rutland wrote: > > On Thu, May 13, 2021 at 09:47:32PM +0300, Mike Rapoport wrote: > > > From: Mike Rapoport > > > > > > 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. > > > > > > Prevent hibernation whenever there are active secret memory users. > > > > Have we thought about how this is going to work in practice, e.g. on > > mobile systems? It seems to me that there are a variety of common > > applications which might want to use this which people don't expect > > to inhibit hibernate (e.g. authentication agents, web browsers). > > If mobile systems require hibernate, then the choice is to disable this > functionality or implement a secure hibernation store. I also thought > most mobile hibernation was basically equivalent to S3, in which case > there's no actual writing of ram into storage, in which case there's no > security barrier and likely the inhibition needs to be made a bit more > specific to the suspend to disk case? > > > Are we happy to say that any userspace application can incidentally > > inhibit hibernate? > > Well, yes, for the laptop use case because we don't want suspend to > disk to be able to compromise the secret area. You can disable this > for mobile if you like, or work out how to implement hibernate securely > if you're really suspending to disk. Forgive me if this was already asked and answered. Why not document that secretmem is ephemeral in the case of hibernate and push the problem to userspace to disable hibernation? In other words hibernation causes applications to need to reload their secretmem, it will be destroyed on the way down and SIGBUS afterwards. That at least gives a system the flexibility to either sacrifice hibernate for secretmem (with a userspace controlled policy), or sacrifice secretmem using processes for hibernate. _______________________________________________ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-leave@lists.01.org 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=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 71406C433B4 for ; Wed, 19 May 2021 01:51:49 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E93AF6044F for ; Wed, 19 May 2021 01:51:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E93AF6044F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=gb01J++Vs00hMLlJgPuOL2nI4dkVdFtZTqVd++DxE5U=; b=miQjC6tJWMoOMEh4RdVyPo9Qb MDiBYCqUr+pHj6umbNy/uo/vcFIpZMgqvAPH+dS41aYQElxb4ZCcidSpqRnIn37o0x8FJZxJWkVs+ pJCfLO8tytPLUJ8ifJsqzveyZO/c3IFeE8YhwjXXK283I5zMZpQxBNqovRxDXTZCh1ZsjmpJ2Ed3t qxT7zBwlzV1Nz8kWylSy/mfd2aLpJgoAju6/tGfI4cHwdaaNmaYfHynd1Ij8dJ3doStS7JJxrt4uW TnH6ujdYSnohwEMh3qB7egoPQcZ5Kylsb45UJloOAbbnqlW2F82OzgDT5OLgBnishtQTZQx9tzN/D woO2dmPYg==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1ljBLb-002Ozp-UC; Wed, 19 May 2021 01:50:08 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1ljBLW-002Oyi-DW for linux-arm-kernel@desiato.infradead.org; Wed, 19 May 2021 01:50:02 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Type:Cc:To:Subject:Message-ID :Date:From:In-Reply-To:References:MIME-Version:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=oy9iy31YW42GgULMnDfqqrgoX8PmHZpkik30uv+f1aA=; b=suvoKTvClCPrcqBIGQ2K9NiYW2 /YUnq92wStuDzW5+hNBamyB76UkRKI4wWt5FuVute8g0qnwFWa3E7EXaiF4hsqXuIlbmgPgZVYZwE Kd6BorMekGqhvAiiZHUfyVaUPHvavTx6J0MxfUJ2l2l7NVweKFiYp2qSabCJLZNDy2pBOOo/cxW3b fvIjUghysPw/U3VTmrhS8k9/Oj/pa6L3AxCR9kQV0hfQp1JFZYG2ggTG/Bdbrv5ds2WjLKlINZaXi SvOpMcJiJeZ1zPudmdTpjTs4ZIjPQrHStUJj1hB3jGz2UQ23IhsbRGmeTkq7Q1ye5A4OMfYc9Zqlb uWbSJ/Pg==; Received: from mail-ed1-x534.google.com ([2a00:1450:4864:20::534]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1ljBLR-00F4In-JJ for linux-arm-kernel@lists.infradead.org; Wed, 19 May 2021 01:50:01 +0000 Received: by mail-ed1-x534.google.com with SMTP id o5so4456672edc.5 for ; Tue, 18 May 2021 18:49:54 -0700 (PDT) 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=oy9iy31YW42GgULMnDfqqrgoX8PmHZpkik30uv+f1aA=; b=tvQ2E7Kd2+Hf+RN1JCJdnQu6RymaGP0zziznDt8ISnI+jG1I9F5rTtPCJWa6PikhKh XFhKmAAqHeMsUAOgy6hUDl59IPnHpchWu1cnHTyyjxMolBXIohuKR723SkE7OCNxzAbK oygZjSu1ZC0vRf3URWfxhzVNd3YMtTfsohBEjCi0q+/uREUxDQtHtMXYqH6q8d9eUBIB 218/C9Rmj+pEf1HRmaUjm/IPbnYkBLCQnR3DkYGpm/9v4+VmsDb6lUfsBZ8rq8wjdtNW PEFTJvZlWna6c3qGn3K9JEbsQ5ZbIkKlwDebT3ZVImG1L8u/VdgWTl83Y5Z5wVd6ZNag 17jA== 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=oy9iy31YW42GgULMnDfqqrgoX8PmHZpkik30uv+f1aA=; b=iZxBTmbezsvOXVVYkNnTx/4z1YedvSN3rKfl5Sp03VXNocOTSmdtWjszSwisCX8o6s 1GJpb+8D08KQ9SFR5ZdGtNXHDwxWIMOL3BcE6JFvnaPppt7B67Id4UK4L4DoE36+7daV 3FlkH+Ogci5JfpDWZv1yMv030wpifq6TIqg0yVketDtMqyXeKgzllkoVtEC3KQhk9ZXq dKrVHxqnr2WTjJIO7OhYe3v5QCIRdZIfNbUCLMf+iYd8z3MjNdEq5Xu04Uzwes18UhL/ nc9jLFh0FnGJ7xU+RfRzlPzdW7cYmymYEfxKfzFOS4hQPDjE69CxlZDXJYvkvAfsQnUw F2jg== X-Gm-Message-State: AOAM531bPwVdZI6eGpwZT7XMXZ/unWlAc++73vaKdlraoofwxzK5C/Ao Gv6J0pZY+7YSLKneh1NodLpuVEYcTBr31xJDlvAmAA== X-Google-Smtp-Source: ABdhPJzCebUO43WPo6zd3pAT6bxEi4LXjBLrk7zln8XX7z9KqzudweIVCjqD+YotU9S81wu4CFwPj9RiJ4aku6RH+xo= X-Received: by 2002:a50:ff13:: with SMTP id a19mr10495865edu.300.1621388993652; Tue, 18 May 2021 18:49:53 -0700 (PDT) MIME-Version: 1.0 References: <20210513184734.29317-1-rppt@kernel.org> <20210513184734.29317-7-rppt@kernel.org> <20210518102424.GD82842@C02TD0UTHF1T.local> In-Reply-To: From: Dan Williams Date: Tue, 18 May 2021 18:49:42 -0700 Message-ID: Subject: Re: [PATCH v19 6/8] PM: hibernate: disable when there are active secretmem users To: James Bottomley Cc: Mark Rutland , Mike Rapoport , Andrew Morton , Alexander Viro , Andy Lutomirski , Arnd Bergmann , Borislav Petkov , Catalin Marinas , Christopher Lameter , Dave Hansen , David Hildenbrand , Elena Reshetova , "H. Peter Anvin" , Hagen Paul Pfeifer , Ingo Molnar , Kees Cook , "Kirill A. Shutemov" , Matthew Wilcox , Matthew Garrett , Michal Hocko , Mike Rapoport , Michael Kerrisk , Palmer Dabbelt , Palmer Dabbelt , Paul Walmsley , Peter Zijlstra , "Rafael J. Wysocki" , Rick Edgecombe , Roman Gushchin , Shakeel Butt , Shuah Khan , Thomas Gleixner , Tycho Andersen , Will Deacon , Yury Norov , 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210518_184957_644955_B76C6F9F X-CRM114-Status: GOOD ( 29.20 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, May 18, 2021 at 6:33 PM James Bottomley wrote: > > On Tue, 2021-05-18 at 11:24 +0100, Mark Rutland wrote: > > On Thu, May 13, 2021 at 09:47:32PM +0300, Mike Rapoport wrote: > > > From: Mike Rapoport > > > > > > 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. > > > > > > Prevent hibernation whenever there are active secret memory users. > > > > Have we thought about how this is going to work in practice, e.g. on > > mobile systems? It seems to me that there are a variety of common > > applications which might want to use this which people don't expect > > to inhibit hibernate (e.g. authentication agents, web browsers). > > If mobile systems require hibernate, then the choice is to disable this > functionality or implement a secure hibernation store. I also thought > most mobile hibernation was basically equivalent to S3, in which case > there's no actual writing of ram into storage, in which case there's no > security barrier and likely the inhibition needs to be made a bit more > specific to the suspend to disk case? > > > Are we happy to say that any userspace application can incidentally > > inhibit hibernate? > > Well, yes, for the laptop use case because we don't want suspend to > disk to be able to compromise the secret area. You can disable this > for mobile if you like, or work out how to implement hibernate securely > if you're really suspending to disk. Forgive me if this was already asked and answered. Why not document that secretmem is ephemeral in the case of hibernate and push the problem to userspace to disable hibernation? In other words hibernation causes applications to need to reload their secretmem, it will be destroyed on the way down and SIGBUS afterwards. That at least gives a system the flexibility to either sacrifice hibernate for secretmem (with a userspace controlled policy), or sacrifice secretmem using processes for hibernate. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel