Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp1078410rwb; Wed, 16 Nov 2022 11:42:37 -0800 (PST) X-Google-Smtp-Source: AA0mqf6edVKKBwYXgEyp5xubdmHo+vof7Ze6D9r+M6eKV0MowtozetCEao7hVCgjhDg54YO0HODM X-Received: by 2002:a05:6402:4003:b0:467:897d:eb09 with SMTP id d3-20020a056402400300b00467897deb09mr17414140eda.60.1668627757628; Wed, 16 Nov 2022 11:42:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668627757; cv=none; d=google.com; s=arc-20160816; b=g6w+3Y0sHSiEzbbLeIuI8JQDXv5p2+o/ajqKz2ohC1SJ3D/TSRB95SO9ai7vfoBM+e RR+ndwS3xd3Wf/3C55u87in8PjnnHru6ZYtQvLe/P/Pfd3xGzitaiYYubDqlrhxnaAGp W4nXWbVkQcrt6ehRgosRuavPG1klAVWkMxzVhlDY09vM5ZMdkmACM7A2nDN6FvM0QnCD ZLfazEy6BZeGc/3GK6Cud9GEb8BG/N3stvr49vVF38Fm+E0SAvyM3R078ddIOLGqFdxR ThI1BP0q2+446Skwxzp8Sd/0kzpKZGi7k8NxM5qZh5GVvf6rm1Yr+ZCdbQovSMmLZvJT CPvg== 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=kB+EGp4efz1Gli9X+UrH3zS99DGscETUAzFGWwtq1Xg=; b=ad4CWdrz4jPKmdrIgYTppQV/9i+x2Id7XnYRq+NK1jBsuPNsZ/q0tsHH93Mt+j05lx 5DFsqkJi/M/E+Nn9M0wUl1mVPujMZC+HstCv+n31SPk9/M818CUC10y77LxTlTxVZ3gY 7t0k0L+ykTaqJ5APrgNRl1Da0hEtJo31HWlPQhnQd7J0ntkUi3odjAlnz/621e0cV1A9 +XHWGz0X7U7GAMc24hzGegdiyPDFWH4z5E1UKBjKrIFj0aZvofi18650R6cyJ9nUOZNx ucdjLiJjWNrMCcYUxP/lfxt5Tfwr5q4xxW7um8DOO6bl88na6Zj7bg36cWczOy98Uvgy BZeQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@paul-moore-com.20210112.gappssmtp.com header.s=20210112 header.b="fbEd/BFr"; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id qf36-20020a1709077f2400b007813b1924ccsi15750511ejc.934.2022.11.16.11.42.15; Wed, 16 Nov 2022 11:42:37 -0800 (PST) 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=@paul-moore-com.20210112.gappssmtp.com header.s=20210112 header.b="fbEd/BFr"; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234383AbiKPT2O (ORCPT + 90 others); Wed, 16 Nov 2022 14:28:14 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43392 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234236AbiKPT2A (ORCPT ); Wed, 16 Nov 2022 14:28:00 -0500 Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D2ACD60E85 for ; Wed, 16 Nov 2022 11:27:59 -0800 (PST) Received: by mail-pj1-x1030.google.com with SMTP id m6-20020a17090a5a4600b00212f8dffec9so3454249pji.0 for ; Wed, 16 Nov 2022 11:27:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=kB+EGp4efz1Gli9X+UrH3zS99DGscETUAzFGWwtq1Xg=; b=fbEd/BFryc3b2Z/VNsNlHKcMsDEwZ6c+zGxvCyRUnkUoKHAzbvY4rTAYx/LVUwvG4F x3DLpWz6iSvj5BIm1MWHR6xxsZ0aAo0TEVyC4+vuoEB4/d/fra6qLpkilcMZapx3bVk1 +RDI4nBFjdgRJIZih4d8WK9S3UaiIsyw6YSMkLpFnwupxg1juYksMhTSwHp0nQo8QHrt v7G7ynPW7WVSXQPwfm0N+09KVY4ROsRn5xioCl+k4m9eYbR+utWhQG6TKSDqvlcMTtC8 Vbt7zLlb16dwS70elh1cJBvfsPSHaGtzNR49ajGyNG6zOzEhsTEtwra+tL7a842Grh15 nw/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=kB+EGp4efz1Gli9X+UrH3zS99DGscETUAzFGWwtq1Xg=; b=GG9C69Uz7Omk1D7KW8YbJLqsWCCSdLVHjcwBNe1hSkSfZHc/CsaU0eGAAxr1xTQlOB THnB5KaIHNX01bnFXuHK33eMJe5Bnz7JRdes8s3tIs0okIvMgQ2BntEfOw1xcBPbizI9 /Y1odamvLpDJQl8anDU/3aB+JWcrqVNg4XoC2SiEcYtYmHqyO3qjkKBzzcLnG9Y37vuv vC2yxWjUdBsHykmLP7lFRF0rnzX/cDtwVr3sHufh4Gz9hD2dAi+aUCCCODAbcS8hRLmR Q1aJhScAKnp65d13ktMYH6rw3Fm6S2beTWOeQ5KF2lA426K6wDuMlLbWcExGLih7mbHY J26g== X-Gm-Message-State: ANoB5pkG3VIo4K+PBTUu9GSvg0b8wjVnXmRHFCBYAizLOny0YNwGpJ2E iDvNwv7tdXtO9V6smwm5BW/IwSInK2FveaSt9oj+ X-Received: by 2002:a17:90a:4596:b0:1fd:5b5d:f09d with SMTP id v22-20020a17090a459600b001fd5b5df09dmr5302996pjg.69.1668626879321; Wed, 16 Nov 2022 11:27:59 -0800 (PST) MIME-Version: 1.0 References: <20221115175652.3836811-1-roberto.sassu@huaweicloud.com> <20221115175652.3836811-2-roberto.sassu@huaweicloud.com> <18e375adfe53f8ce5fb38a6a146ad06eaec71a5e.camel@huaweicloud.com> In-Reply-To: From: Paul Moore Date: Wed, 16 Nov 2022 14:27:47 -0500 Message-ID: Subject: Re: [RFC][PATCH 1/4] lsm: Clarify documentation of vm_enough_memory hook To: KP Singh Cc: Roberto Sassu , ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org, martin.lau@linux.dev, song@kernel.org, yhs@fb.com, john.fastabend@gmail.com, sdf@google.com, haoluo@google.com, jolsa@kernel.org, revest@chromium.org, jackmanb@chromium.org, jmorris@namei.org, serge@hallyn.com, bpf@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, Roberto Sassu Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE autolearn=unavailable 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 Wed, Nov 16, 2022 at 2:18 PM KP Singh wrote: > On Wed, Nov 16, 2022 at 9:06 AM Roberto Sassu > wrote: > > > > On Tue, 2022-11-15 at 21:11 -0500, Paul Moore wrote: > > > On Tue, Nov 15, 2022 at 12:57 PM Roberto Sassu > > > wrote: > > > > From: Roberto Sassu > > > > > > > > include/linux/lsm_hooks.h reports the result of the LSM infrastructure to > > > > the callers, not what LSMs should return to the LSM infrastructure. > > > > > > > > Clarify that and add that returning 1 from the LSMs means calling > > > > __vm_enough_memory() with cap_sys_admin set, 0 without. > > > > > > > > Signed-off-by: Roberto Sassu > > > > Reviewed-by: KP Singh > > > > --- > > > > include/linux/lsm_hooks.h | 4 +++- > > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h > > > > index 4ec80b96c22e..f40b82ca91e7 100644 > > > > --- a/include/linux/lsm_hooks.h > > > > +++ b/include/linux/lsm_hooks.h > > > > @@ -1411,7 +1411,9 @@ > > > > * Check permissions for allocating a new virtual mapping. > > > > * @mm contains the mm struct it is being added to. > > > > * @pages contains the number of pages. > > > > - * Return 0 if permission is granted. > > > > + * Return 0 if permission is granted by LSMs to the caller. LSMs should > > > > + * return 1 if __vm_enough_memory() should be called with > > > > + * cap_sys_admin set, 0 if not. > > > > > > I think this is a nice addition, but according to the code, any value > > > greater than zero will trigger the caller-should-have-CAP_SYS_ADMIN > > > behavior, not just 1. I suggest updating the comment. > > > > Ok, yes. Thanks. > > Also, this is an unrelated patch and you can probably send it > independently, especially > since the other changes will now land mostly via BPF. Yes, the doc/comment changes really have nothing to do with the other stuff we are discussing in this patchset. -- paul-moore.com