Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp4342353pxv; Tue, 27 Jul 2021 05:12:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJymGcmHTFbJI2T4S0jpcwiu/f4Z4uQe9EG6FoPke8LOBQXYXvHv2CtV3RtBFXTHPd3GQdLE X-Received: by 2002:a17:906:2b58:: with SMTP id b24mr20566938ejg.141.1627387943903; Tue, 27 Jul 2021 05:12:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627387943; cv=none; d=google.com; s=arc-20160816; b=E15a94D6DnI3d9ukxoR3LQpBYUH28otK6kTOKceVW9GLzGoNXRsQ/H98lJ96ZWL2+5 2hcw56jB/aW+kzQf/vCQG7/9ma53T9+ds4kfJNWR31nJ0QFE0gX+aYLi/3CEESLlI3MR JU1935VxRWuN0+sHm5UrvOFL+pXtTCRnVCOFXyAcWeMxbOXn1l7ZOwsqvkjJKswx+dOp ZQInhQVb4ys7lx6V+g7pN28WeaAqUTPPa02m6PgFVvwbgDvEupje2mWG/96tuKOMhAav +OATsbWXyPm4neXGdQSEo4ptygmdtDwFoO1ik4FC1V+cPfzRgEYGtMHEoyKK0w3rmbAa sTuQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=edghJkzL8zxafHvv56lInWepK4OjVXzJNWJcrw0kBxw=; b=JHFUlYaW6SJBwAsfd2WZf7l1Sd/x4d5hS2CVFwWF77RxUW3Fgbyi+rNhPjVSN26Ffq 2na3ybamshdgzd3Oas6mTRWR26dXPKiEP30uSyNrliAqbLJe0+yoctFMpPiStKCggwJ+ kerbGCa96IJDJW3cCzUtoK0CzqA9CECNTkJcbfcISQ6WgajPp0bXgcLdeVy6BgSu5Umy H0WC/niHlmg76YH+FleaFGdFoo1lcpolDbRm24tZuhiSGjIqSt6EDf8tIjpotXHddRE8 H4HjrqyDZbDpl+BUJEy0b+Ly/eRhQ/4XtIOMsi/lVG67RhrXpbEx/m5SHL39JjimBO83 D4Ew== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n23si2386833ejj.608.2021.07.27.05.12.00; Tue, 27 Jul 2021 05:12:23 -0700 (PDT) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236497AbhG0MKL (ORCPT + 99 others); Tue, 27 Jul 2021 08:10:11 -0400 Received: from jabberwock.ucw.cz ([46.255.230.98]:59568 "EHLO jabberwock.ucw.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231868AbhG0MKL (ORCPT ); Tue, 27 Jul 2021 08:10:11 -0400 Received: by jabberwock.ucw.cz (Postfix, from userid 1017) id BD1AF1C0B76; Tue, 27 Jul 2021 14:10:09 +0200 (CEST) Date: Tue, 27 Jul 2021 14:10:09 +0200 From: Pavel Machek To: Evan Green Cc: Michal Hocko , Andrew Morton , David Hildenbrand , Alex Shi , Alistair Popple , Jens Axboe , Johannes Weiner , Joonsoo Kim , "Matthew Wilcox (Oracle)" , Miaohe Lin , Minchan Kim , Vlastimil Babka , LKML , linux-mm@kvack.org, linux-api@vger.kernel.org Subject: Re: [PATCH v2] mm: Enable suspend-only swap spaces Message-ID: <20210727121009.GC32265@duo.ucw.cz> References: <20210709105012.v2.1.I09866d90c6de14f21223a03e9e6a31f8a02ecbaf@changeid> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IpbVkmxF4tDyP/Kb" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --IpbVkmxF4tDyP/Kb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! > > > If I have > > > different security designs for swap space and hibernate, then even a > > > chance of some swap leaking into this region is a problem. > > > > Could you expand some more about the this part please? >=20 > Offline attacks (ie manipulating storage from underneath the machine) > are a major concern when enabling both swap and hibernate. But the > approach of adding integrity to mitigate offline attacks may differ > between swap and hibernate in the interest of performance. Swap for > instance essentially needs a per-page dictionary of hashes for > integrity, since pages can be added and removed arbitrarily. Hibernate > however just needs a single hash across the entire image to provide > integrity. If you have swap leaking onto a region where you don't have > integrity enabled (because say you handled integrity at the image > level for hibernate, and at the block layer for swap), your swap > integrity story is compromised. If you want to encrypt/sign the hibernation, you likely should use uswsusp, and that means you can store hibernation image where (and how) you want it, without modifying kernel. See kernel/power/user.c . > I don't think this digs the design hole deeper. Yes, the ship on this > design has long ago sailed. But if we ever did try to dig ourselves > out of the swap/hibernate hole by providing new APIs to handle them > separately, this flag would serve as a good cutover to divert out of > the swap code and into the new shiny hibernate-only code. The APIs are > never going to be totally disentangled, so a clean cutover opportunity > is the best one can hope for. Is uswsusp the place that should provide clean cutover? Anyway, I acked the patch before, but it looks like it was mistake. I withdraw the ack. Best regards, Pavel --=20 http://www.livejournal.com/~pavelmachek --IpbVkmxF4tDyP/Kb Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQRPfPO7r0eAhk010v0w5/Bqldv68gUCYP/3oQAKCRAw5/Bqldv6 8uTJAKCXT792Z09f+xBOfKt2W3D1q0/7swCfTgTOXUu8wbDT/wEminQRGN7O1vk= =h3cE -----END PGP SIGNATURE----- --IpbVkmxF4tDyP/Kb--