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=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 009EAC432BE for ; Tue, 27 Jul 2021 12:10:14 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CCB0761A3C for ; Tue, 27 Jul 2021 12:10:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org CCB0761A3C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ucw.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 509DC6B0036; Tue, 27 Jul 2021 08:10:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4BA4A6B005D; Tue, 27 Jul 2021 08:10:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3A8DD6B006C; Tue, 27 Jul 2021 08:10:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0092.hostedemail.com [216.40.44.92]) by kanga.kvack.org (Postfix) with ESMTP id 219B86B0036 for ; Tue, 27 Jul 2021 08:10:12 -0400 (EDT) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id C9C1A824999B for ; Tue, 27 Jul 2021 12:10:11 +0000 (UTC) X-FDA: 78408249822.24.894A006 Received: from jabberwock.ucw.cz (jabberwock.ucw.cz [46.255.230.98]) by imf05.hostedemail.com (Postfix) with ESMTP id 57DF650405C6 for ; Tue, 27 Jul 2021 12:10:11 +0000 (UTC) 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) X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 57DF650405C6 Authentication-Results: imf05.hostedemail.com; dkim=none; spf=none (imf05.hostedemail.com: domain of pavel@ucw.cz has no SPF policy when checking 46.255.230.98) smtp.mailfrom=pavel@ucw.cz; dmarc=none X-Stat-Signature: gduz3zqr5ih467mofboxusxzozchpib9 X-HE-Tag: 1627387811-301597 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: --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--