Received: by 2002:ac0:e350:0:0:0:0:0 with SMTP id g16csp2454223imn; Tue, 2 Aug 2022 03:32:11 -0700 (PDT) X-Google-Smtp-Source: AA6agR7rPElp7jhh2z7y07v/Ls8LF3mzQPvRBAnKJu+ZeDuyCNVPk283G6KFyjPOUiIJfx2mqPJ1 X-Received: by 2002:a17:902:f101:b0:16d:c0ae:acd5 with SMTP id e1-20020a170902f10100b0016dc0aeacd5mr20388765plb.70.1659436331695; Tue, 02 Aug 2022 03:32:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1659436331; cv=none; d=google.com; s=arc-20160816; b=zVwT90FbmR2WrvHJfq8yReKmjxNiM6i9JYVDnMSIoB00WZqY/eUjQaWAXBofam4Bx5 rniVmP6FYDZKEhPT7awwtX3HBU4DIalLm6nO7Lw9MlnzM69E2xrZg0i1nKHUYlkqR5sG 0yUpBzXm21yi+tiqxyWcw55V3f9lgkVSM8FXSRDyAZZyRnZRFc44HCZcK0jYYrjXtYxl Q1uxfxDy3JgDCh0lYRlGp+0rbd2+c9x5vVhSkGXaohdL1I3ruJJEvzaF4hpEMEW36bgN 4SrtyVsCQqPPT+Jp4kBzcixL8A0Oxm6L+yAt5lgRXbt8HMm5IZc7Avcw7WHUl3MYkjnD A3Bg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=Rd/MnnpubSXpiz2m3mizA1wFblV70cbg5nXLpi9fPUU=; b=0VpElfh1Yc/X0OVnOwrlgXzwUI6KEirtUSRBE2uSaj3xSrbfXj0OMwQqmHgbu1XJdh gIwLIUMHp/B0Q/VpGTbShZ4VZe/SoAm5/Vf4vKPaFselip40/FH0iK+gm018rHfcpCvE +dzxsSlYxxsmTBN65TYURtS+umlaGyN6H3ZeKVkzrkfEVQh3uT+ABYpXkZP5IgN28GW+ 8MAxk5sqTxf/SidyuoxeBRklxr1qLWQJbRuQaW0iOrGT2l0g9ll02CQsB3EwqJ4bHAah LpGexRMqOxXnBmMjKhYlYK5ujJFkZyBXTaevK3F3LcXf4NOKWPFZqrc733U7+ws8qXSy kV3g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=LrhdbfLN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id d16-20020a621d10000000b005254ad64f73si13495148pfd.102.2022.08.02.03.31.57; Tue, 02 Aug 2022 03:32:11 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=LrhdbfLN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235486AbiHBJtM (ORCPT + 99 others); Tue, 2 Aug 2022 05:49:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35540 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232543AbiHBJtL (ORCPT ); Tue, 2 Aug 2022 05:49:11 -0400 Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::230]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2CF5DF67 for ; Tue, 2 Aug 2022 02:49:10 -0700 (PDT) Received: by mail-oi1-x230.google.com with SMTP id s204so15957877oif.5 for ; Tue, 02 Aug 2022 02:49:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Rd/MnnpubSXpiz2m3mizA1wFblV70cbg5nXLpi9fPUU=; b=LrhdbfLNPTzm+rQRir/KlWFTOP5w7dp2DeTugPU44Q7w9F+j2YfnKpe5cfHrw8ralE bKy5BBnIk/1WWdF3dgQ/lWnyvcFT5+dRorBjdP3noyEpgfJqKe3is9ZiFbMNycb6g6v4 0MRYwfSDsPLWug/dc57YhUVLFQrhQPoRYD1AivLL9QUs4VTOvsIGmHWbj9nPBlkXwueu xbaByWeHnH7xrusROFoxFuJRrdZmKdaGTgZXL5zmSyG2yv642dN+zwJTVYzJLHRddndm CxXNmEiUPl7zFls9hvBpssresB7hZSjkLKunn8joVhzt1eroMR4WxIf8rps0sGG1CyLi 54sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Rd/MnnpubSXpiz2m3mizA1wFblV70cbg5nXLpi9fPUU=; b=yl2NCi0PjNoZlVeYEXpes0ar5iiW9lijWPyrCQbRLzUUIK6L3M1qp+Lnk/ICAGVJnP QicV8e9NiWVxHd7s3DS6LygN2WTb9gl6fe3ititkbJASPQfbLugbF1nK2lwEEaApwiQj IBr286t368nGy37bIXF3fILhplv9j8/hdQEkWAxxV3LwDqh6A8YESjDGn//I2Qh8urCp 28UVB2Q8ws7oXlpsyGtr27LeYxGesyYmvNqSe+fHdJbM9pTzQfPLM77owPXVQfgiLIkn X/ndBpkq3WcI5nVsmNeg7JLfmB5dvitc3C9U9kZSyFE+vumig8ZoWKtJvtwnn09KMtox x5Rw== X-Gm-Message-State: AJIora8ZCjqk5GhD5w1KMWlyTW42zlOZbQltW1ZHcA4Uv2EdIos8cdSh mgEq6a1EVfT9No9KP2+2YvfZITpULJWUC3IA6GWuiQ== X-Received: by 2002:a05:6808:1446:b0:33a:c7e0:e88d with SMTP id x6-20020a056808144600b0033ac7e0e88dmr7690868oiv.123.1659433749236; Tue, 02 Aug 2022 02:49:09 -0700 (PDT) MIME-Version: 1.0 References: <20220801210946.3069083-1-zokeefe@google.com> In-Reply-To: From: "Zach O'Keefe" Date: Tue, 2 Aug 2022 02:48:33 -0700 Message-ID: Subject: Re: [PATCH mm-unstable] mm/madvise: remove CAP_SYS_ADMIN requirement for process_madvise(MADV_COLLAPSE) To: Michal Hocko Cc: linux-mm@kvack.org, Andrew Morton , linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, Axel Rasmussen , James Houghton , Hugh Dickins , Yang Shi , Miaohe Lin , David Hildenbrand , David Rientjes , Matthew Wilcox , Pasha Tatashin , Peter Xu , Rongwei Wang , SeongJae Park , Song Liu , Vlastimil Babka , Zi Yan , Andrea Arcangeli , Arnd Bergmann , Chris Kennelly , Chris Zankel , Helge Deller , Ivan Kokshaysky , "James E.J. Bottomley" , Jens Axboe , "Kirill A. Shutemov" , Matt Turner , Max Filippov , Minchan Kim , Patrick Xia , Pavel Begunkov , Thomas Bogendoerfer Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 2, 2022 at 2:09 AM Michal Hocko wrote: > > Hasn't this been discussed during the MADV_COLLAPSE submission? What has > changed? Does this need more time to settle with the consensus? > > On Mon 01-08-22 14:09:46, Zach O'Keefe wrote: > > process_madvise(MADV_COLLAPSE) currently requires CAP_SYS_ADMIN when not > > acting on the caller's own mm. This is maximally restrictive, and > > perpetuates existing issues with CAP_SYS_ADMIN. Remove this requirement. > > > > When acting on an external process' memory, the biggest concerns for > > process_madvise(MADV_COLLAPSE) are (1) being able to influence process > > performance by moving memory, possibly between nodes, that is mapped > > into the address space of external process(es), (2) defeat of > > address-space-layout randomization, and (3), being able to increase > > process RSS and memcg usage, possibly causing memcg OOM. > > > > process_madvise(2) already enforces CAP_SYS_NICE and PTRACE_MODE_READ (in > > PTRACE_MODE_FSCREDS mode). A process with these credentials can already > > accomplish (1) and (2) via move_pages(MPOL_MF_MOVE_ALL), and (3) via > > process_madvise(MADV_WILLNEED). > > > > process_madvise(MADV_COLLAPSE) may also circumvent sysfs THP settings. > > When acting on one's own memory (which is equivalent to > > madvise(MADV_COLLAPSE)), this is deemed acceptable, since aside from the > > possibility of hoarding available hugepages (which is currently already > > possible) no harm to the system can be done. When acting on an external > > process' memory, circumventing sysfs THP settings should provide no > > additional threat compared to the ones listed. As such, imposing > > additional capabilities (such as CAP_SETUID, as a way to ensure the > > caller could have just altered the sysfs THP settings themselves) > > provides no extra protection. > > > > Fixes: 7ec952341312 ("mm/madvise: add MADV_COLLAPSE to process_madvise()") > > Signed-off-by: Zach O'Keefe > > --- > > mm/madvise.c | 8 +++----- > > 1 file changed, 3 insertions(+), 5 deletions(-) > > > > diff --git a/mm/madvise.c b/mm/madvise.c > > index f9e11b6c9916..af97100a0727 100644 > > --- a/mm/madvise.c > > +++ b/mm/madvise.c > > @@ -1170,16 +1170,14 @@ madvise_behavior_valid(int behavior) > > } > > } > > > > -static bool > > -process_madvise_behavior_valid(int behavior, struct task_struct *task) > > +static bool process_madvise_behavior_valid(int behavior) > > { > > switch (behavior) { > > case MADV_COLD: > > case MADV_PAGEOUT: > > case MADV_WILLNEED: > > - return true; > > case MADV_COLLAPSE: > > - return task == current || capable(CAP_SYS_ADMIN); > > + return true; > > default: > > return false; > > } > > @@ -1457,7 +1455,7 @@ SYSCALL_DEFINE5(process_madvise, int, pidfd, const struct iovec __user *, vec, > > goto free_iov; > > } > > > > - if (!process_madvise_behavior_valid(behavior, task)) { > > + if (!process_madvise_behavior_valid(behavior)) { > > ret = -EINVAL; > > goto release_task; > > } > > -- > > 2.37.1.455.g008518b4e5-goog > > -- > Michal Hocko > SUSE Labs Hey Michal, Thanks for taking the time to take a look at this. "mm/madvise: add MADV_COLLAPSE to process_madvise()" in the v7 series ended with me mentioning a couple options, but ultimately I didn't present a solution, and no consensus was reached[1]. After taking a closer look, this is my proposal for what I believe to be the best path forward. It should be squashed into the original patch. What do you think? Thanks again, Zach [1] https://lore.kernel.org/linux-mm/Ys4aTRqWIbjNs1mI@google.com/