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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 85A1DC3F2D5 for ; Mon, 2 Mar 2020 04:51:13 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3D7CC24699 for ; Mon, 2 Mar 2020 04:51:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="bo6FxVVk" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3D7CC24699 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C87006B0005; Sun, 1 Mar 2020 23:51:12 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C38CA6B0006; Sun, 1 Mar 2020 23:51:12 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B002D6B0007; Sun, 1 Mar 2020 23:51:12 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0206.hostedemail.com [216.40.44.206]) by kanga.kvack.org (Postfix) with ESMTP id 9473F6B0005 for ; Sun, 1 Mar 2020 23:51:12 -0500 (EST) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 3530D180AD802 for ; Mon, 2 Mar 2020 04:51:12 +0000 (UTC) X-FDA: 76549197984.01.team44_61c51996c9018 X-HE-Tag: team44_61c51996c9018 X-Filterd-Recvd-Size: 8049 Received: from mail-il1-f193.google.com (mail-il1-f193.google.com [209.85.166.193]) by imf31.hostedemail.com (Postfix) with ESMTP for ; Mon, 2 Mar 2020 04:51:11 +0000 (UTC) Received: by mail-il1-f193.google.com with SMTP id p8so8167784iln.12 for ; Sun, 01 Mar 2020 20:51:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=alTTveLKTo1elfmHPHzMWxdGHAT1S7u6JKso3Pkl1Tg=; b=bo6FxVVkuiQi2qqGiBTcsY5WIEzeaUkzfWe1ycgrelgG6CrmG4P0xHFu8Dzz3vWHHm sihKM0osjGRfph4Pou1nw/mMJdkE+s54Za0DjZpapvJXDrJ0F/KPGzEU/T7S7i0LeOGU TWujb6cRE13rIbohViCRvfIwZj/9iDjVJovveFUX5hN99TINU3L4ToaFyFhKUVV1ha+/ ZYyaYtzul2ywZ4ourfUAGyYIkp9uDlHlUJJfVTfnmttJLpBhYxLNcEeFNImssOZyIMtk Za9QLLO8oS72jPpcK263FwYula9/47t9vGTQbx+W1RckMg55kevzGZbaG767uD+R7Lz8 g/bA== 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=alTTveLKTo1elfmHPHzMWxdGHAT1S7u6JKso3Pkl1Tg=; b=s3G5XjL/QlYmRizlKsiiqFsrNsaXuCIcnr40xqyfDQmw3wy3hpBMYYpCWfaP3T5Tcs cT/hWy75pIFchm84PsRSU8fO893hDoCwG9WB9E+vLannbNxbI7rZAv1L1ITbKKup+Drg eJVOnshsZ1KbFCwx8Dum1yJ8eVCbekkrasX2FPvZyj0QiK0LPnXuyoXE2yJt/LIlEJD/ p9h7bTEzlycW8c2BVcsYHx5cVPrICphQ6dZOcoCPt1npDWvQ4utAvxgQJUbWdy5dyNwQ WqtiDVaKyM3zbKAf1lbMi9TmXBelweCvx8oOhbbCtOCBCb7FKmlgvNK10zRLZO9bhrWL uD/A== X-Gm-Message-State: APjAAAW9oylm6n3Q0FE+3nKSye5F7UQlG0iRsUAJh8vl6FGfkZmLnO27 8wZ9o49qwRTBTdt3OSJV1S6M9QDSPG5Di/45HPg= X-Google-Smtp-Source: APXvYqxtkZqTWghmGlHaI6suboZ+vFHyCwxVH29YA9XEB9zgnrHkTQ9/Aw28bLyE37Wz+pvOuUAzjnYI2+hTkjM80l0= X-Received: by 2002:a92:489a:: with SMTP id j26mr15961954ilg.226.1583124671019; Sun, 01 Mar 2020 20:51:11 -0800 (PST) MIME-Version: 1.0 References: <20200229170825.GX8045@magnolia> <20200229180716.GA31323@dumbo> <20200229183820.GA8037@magnolia> <20200229200200.GA10970@dumbo> In-Reply-To: From: Marian Klein Date: Mon, 2 Mar 2020 04:51:00 +0000 Message-ID: Subject: Re: [PATCH] hibernate: unlock swap bdev for writing when uswsusp is active To: "Rafael J. Wysocki" Cc: Domenico Andreoli , "Darrick J. Wong" , Linux PM , Linux Memory Management List , linux-fsdevel@vger.kernel.org, Christoph Hellwig , Andrew Morton , "Rafael J. Wysocki" , Len Brown , Pavel Machek Content-Type: text/plain; charset="UTF-8" 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: Hi Darrick If security is a concern, maybe it should in kernel config ( CONFIG_ENABLE_HIBERNATION = Y/N ) For the security hardened server systems with no hibernation need you simply configure it to N. Also the concern the other process can hijack s2disk is unlikely. You have to realized all processors except for one are down (See dmesg bellow.) by the time the snapshot image is being written. So you can disable scheduler time sharing on this only one processor when you get snapshot request and no other process can jump in. I think you can allow (unlock) writing ONLY to device specified in kernel parameter resume=/dev/ and only when CONFIG_ENABLE_HIBERNATION = Y and there is only one CPU active (CPU0) and time sharing scheduler is down and user group from another kernel parameter snapshot_gid invoked snapshot. For me secure enough. If any rogue program pretended to be legitimate user space hibernation program it would have to go via actual hibernation cycle (powering off computer) and that would be obvious to user if that was not triggered by him or configured by him to trigger automatically. It is no way a program secretly could write to resume/swap device. For normal users often the security is less of concern as they know who works with their laptop , etc. [ 1243.100159] Disabling non-boot CPUs ... [ 1243.101448] smpboot: CPU 1 is now offline [ 1243.103291] smpboot: CPU 2 is now offline [ 1243.104851] smpboot: CPU 3 is now offline [ 1243.106522] smpboot: CPU 4 is now offline [ 1243.108200] smpboot: CPU 5 is now offline [ 1243.109928] smpboot: CPU 6 is now offline [ 1243.111501] smpboot: CPU 7 is now offline [ 1243.113364] PM: Creating hibernation image: [ 1243.597752] PM: Need to copy 161991 pages [ 1243.597756] PM: Normal pages needed: 161991 + 1024, available pages: 3967507 [ 1244.202907] PM: Hibernation image created (161991 pages copied) On Sun, 1 Mar 2020 at 21:35, Rafael J. Wysocki wrote: > > On Sat, Feb 29, 2020 at 9:02 PM Domenico Andreoli > wrote: > > > > On Sat, Feb 29, 2020 at 10:38:20AM -0800, Darrick J. Wong wrote: > > > On Sat, Feb 29, 2020 at 07:07:16PM +0100, Domenico Andreoli wrote: > > > > On Sat, Feb 29, 2020 at 09:08:25AM -0800, Darrick J. Wong wrote: > > > > > From: Darrick J. Wong > > > > > > > > > > It turns out that there /is/ one use case for programs being able to > > > > > write to swap devices, and that is the userspace hibernation code. The > > > > > uswsusp ioctls allow userspace to lease parts of swap devices, so turn > > > > > S_SWAPFILE off when invoking suspend. > > > > > > > > > > Fixes: 1638045c3677 ("mm: set S_SWAPFILE on blockdev swap devices") > > > > > Reported-by: Domenico Andreoli > > > > > Reported-by: Marian Klein > > > > > > > > I also tested it yesterday but was not satisfied, unfortunately I did > > > > not come with my comment in time. > > > > > > > > Yes, I confirm that the uswsusp works again but also checked that > > > > swap_relockall() is not triggered at all and therefore after the first > > > > hibernation cycle the S_SWAPFILE bit remains cleared and the whole > > > > swap_relockall() is useless. > > > > > > > > I'm not sure this patch should be merged in the current form. > > > > > > NNGGHHGGHGH /me is rapidly losing his sanity and will soon just revert > > > the whole security feature because I'm getting fed up with people > > > yelling at me *while I'm on vacation* trying to *restore* my sanity. I > > > really don't want to be QAing userspace-directed hibernation right now. > > > > Maybe we could proceed with the first patch to amend the regression and > > postpone the improved fix to a later patch? Don't loose sanity for this. > > I would concur here. > > > > ...right, the patch is broken because we have to relock the swapfiles in > > > whatever code executes after we jump back to the restored kernel, not in > > > the one that's doing the restoring. Does this help? > > > > I made a few unsuccessful attempts in kernel/power/hibernate.c and > > eventually I'm switching to qemu to speed up the test cycle. > > > > > OTOH, maybe we should just leave the swapfiles unlocked after resume. > > > Userspace has clearly demonstrated the one usecase for writing to the > > > swapfile, which means anyone could have jumped in while uswsusp was > > > running and written whatever crap they wanted to the parts of the swap > > > file that weren't leased for the hibernate image. > > > > Essentially, if the hibernation is supported the swapfile is not totally > > safe. > > But that's only the case with the userspace variant, isn't it? > > > Maybe user-space hibernation should be a separate option. > > That actually is not a bad idea at all in my view. > > Thanks!