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