From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0AAB440848 for ; Mon, 8 Jul 2024 10:04:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1720433091; cv=none; b=E7U4WzbGeMTHfSaRciBumMUHYbVOUpTR/+D+bc+zrqzvpM5bOQbWsMb035+7xG6W+XXQf+M7ol+fYtB3QRKVEQNKho0ICagaKgwKIZxx2+VAYy0KzWDAOHYnbq8UXAHIOnIdtf3datbKDeE7D7pQtrsbCFKj3/Ttd2uXk25iyzY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1720433091; c=relaxed/simple; bh=USy5tAusbYhsNK4T3DhzfrXWJZNN3yFfYPLsqMtD+AY=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=LfY0dHZicT71dLE0WINi26m0asNg5oWnZSi3Cpglsdd1R630+IyI2tOIjcBI4le3UAewJWtrR0HTdxmwS9BE+4wAzQuvEzY+gwvTY01mA9zlofLKvmpdeZ3XPAqKD0z/XqXJOsOPwinoXypw9qso9dPWfL4vO0K7L/5SPA1w+x0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=HjMQoKB/; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="HjMQoKB/" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A5229C4AF0C for ; Mon, 8 Jul 2024 10:04:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1720433090; bh=USy5tAusbYhsNK4T3DhzfrXWJZNN3yFfYPLsqMtD+AY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=HjMQoKB/Tz2oaWPvKxRodrl1bgihRp5pQHQoz3ddUDeg968b/8wOlJmO+Ir2YLfRz 1/AXGdUzDNwK2J5d6Zq+LDqz4IiWJhJfBbk8LhJUlRcVlPat/qiajn59/yrTWvbVYk O828Kp1hh0AKM4Za9t9E3otA9iKjMMPbOwu2ai1LHIG53DnJqPdnuor5HxfInaJKsb oUDac6oYF4CwZqYITibpyHC3+vamLNehSWrQPT6zhqePwcM2QhPJIVOd4LCnEdaFLW yTTZdM+pxpG5upHtOWJheV+b9p7hdYLpDqwkn8/q0L//HG+tkRX991Zkw33uz7XfqC J72cL00m56gcQ== Received: by mail-ed1-f43.google.com with SMTP id 4fb4d7f45d1cf-57cbc2a2496so4219791a12.0 for ; Mon, 08 Jul 2024 03:04:50 -0700 (PDT) X-Gm-Message-State: AOJu0YzVCxXYz8lhRk7m81YAXL6OzXyx+Ko18JlLZyq7/idtSmNQzWG9 zifozcIG8qUkPvr9T03FEpq4GE0OmMzqA35sL7B1xcf9nj3ZHVsqi869jceS00CXdmAtHkFB8mF E9a6ydcOAHATanceh8z4BuQMf/FtAJhPIrkQV X-Google-Smtp-Source: AGHT+IHYhZUMGl3xoMe6nGJCiUDuux4b5qNKC9p3FSNKDNSbMdP8pPQTIUoPx5b2kRBVKsNnXotkfx2Vvb3CGONNVLc= X-Received: by 2002:a05:6402:40cc:b0:57a:27c8:3269 with SMTP id 4fb4d7f45d1cf-58e5a7f0899mr9931152a12.4.1720433089092; Mon, 08 Jul 2024 03:04:49 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-security-module@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20240629084331.3807368-4-kpsingh@kernel.org> In-Reply-To: From: KP Singh Date: Mon, 8 Jul 2024 12:04:36 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v13 3/5] security: Replace indirect LSM hook calls with static calls To: Paul Moore Cc: linux-security-module@vger.kernel.org, bpf@vger.kernel.org, ast@kernel.org, casey@schaufler-ca.com, andrii@kernel.org, keescook@chromium.org, daniel@iogearbox.net, renauld@google.com, revest@chromium.org, song@kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jul 6, 2024 at 6:40=E2=80=AFAM Paul Moore wro= te: > > On Fri, Jul 5, 2024 at 3:34=E2=80=AFPM KP Singh wrot= e: > > On Fri, Jul 5, 2024 at 8:07=E2=80=AFPM Paul Moore = wrote: > > > On Wed, Jul 3, 2024 at 7:08=E2=80=AFPM KP Singh = wrote: [...] > > > > Paul, I am talking about eliminating a class of bugs, but you don't > > seem to get the point and you are fixated on the very instance of this > > bug class. > > I do understand that you are trying to eliminate a class of bugs, the > point I'm trying to make is that I believe we have addressed that > already with the patches I've previously cited. The class I am referring to is useless hooks returning a default value and imposing a denial / enforcement when they are not supposed to. If you think this class of issues is not relevant to the overall LSM, sure. I would still like BPF LSM to not add default callbacks as I have always maintained since day 1: https://lwn.net/ml/linux-kernel/20200224171305.GA21886@chromium.org/ BPF LSM does not want to provide a default decision until a BPF LSM policy program is loaded, > > > > > 2. Performance, no extra function call. > > > > > > Convince me the bug still exists first and then we can discuss the > > > merits of whatever solutions are proposed. > > > > This is independent of the bug! > > Correctness first, maintainability second, performance third. That's > my current priority and I feel the maintainability hit doesn't justify > the performance win at this point in time. Besides, we're already > expecting a big performance boost simply by moving to static_calls. > > > As I said, If you don't want to modify the core LSM layer, it's okay, > > I still want to go with changes local to the BPF LSM, If you really > > don't agree with the changes local to the BPF LSM, we can have it go > > via the BPF tree and seek Linus' help to resolve the conflict. > > As the BPF maintainer you are always free to do whatever you like > within the scope of the LSM you maintain so long as it does not touch > or otherwise impact any of the other LSMs or the LSM framework. If > you do affect the other LSMs, or the LSM framework, you need to get an > ACK from the associated maintainer. That's pretty much how Linux > kernel development works. Okay, then let's not make an LSM API, I will handle it within the BPF LSM. The patch I proposed should not affect any other LSMs and is self contained within BPF LSM: https://lore.kernel.org/bpf/CACYkzJ6jADoGNuPP3-1wkk-kV7NOQh+eFkU5KEDEZgq9qN= NEfg@mail.gmail.com/ > > -- > paul-moore.com