From: Kees Cook <keescook@chromium.org>
To: Paul Moore <paul@paul-moore.com>
Cc: KP Singh <kpsingh@kernel.org>,
linux-security-module@vger.kernel.org, bpf@vger.kernel.org,
casey@schaufler-ca.com, song@kernel.org, daniel@iogearbox.net,
ast@kernel.org, renauld@google.com, pabeni@redhat.com
Subject: Re: [PATCH v8 5/5] security: Add CONFIG_SECURITY_HOOK_LIKELY
Date: Fri, 8 Dec 2023 14:05:27 -0800 [thread overview]
Message-ID: <202312081352.6587C77@keescook> (raw)
In-Reply-To: <CAHC9VhQ2VxM=WWL_jpoELu=dHuiF3Pk=bxNrpfctc7Q0K2DUfA@mail.gmail.com>
On Fri, Dec 08, 2023 at 04:43:57PM -0500, Paul Moore wrote:
> On Fri, Dec 8, 2023 at 4:13 PM Kees Cook <keescook@chromium.org> wrote:
> > On Fri, Dec 08, 2023 at 03:51:47PM -0500, Paul Moore wrote:
> > > Hopefully by repeating the important bits of the conversation you now
> > > understand that there is nothing you can do at this moment to speed my
> > > review of this patchset, but there are things you, and KP, can do in
> > > the future if additional respins are needed. However, if you are
> > > still confused, it may be best to go do something else for a bit and
> > > then revisit this email because there is nothing more that I can say
> > > on this topic at this point in time.
> >
> > I moved to the list because off-list discussions (that I got involuntarily
> > CCed into and never replied to at all) tend to be unhelpful as no one else
> > can share in any context they may provide. And I'm not trying to rush
> > you; I'm trying to make review easier.
>
> From my perspective whatever good intentions you had at the start were
> completely lost when you asked "What's the right direction forward?"
> after I had already explained things multiple times *today*. That's
> the sort of thing that drives really bothers me.
Okay, I understand now. Sorry for frustrating you! By "way forward",
I meant I didn't understand how to address what looked like conflicting
feedback. I think my confusion was over separating the goal ("this
feature should be automatically enabled when it is known to be useful")
from an interpretation of earlier feedback as "I don't want a CONFIG [that
leaves this up to the user]", when what you really wanted understood was
"I don't want a CONFIG *ever*, regardless of whether it picks the correct
setting automatically".
>
> > While looking at the v8 again I
> > saw an obvious problem with it, so I commented on it so that it's clear
> > to you that it'll need work when you do get around to the review.
>
> That's fair. The Kconfig patch shouldn't have even been part of the
> v8 patchset as far as I'm concerned, both because I explained I didn't
> want to merge something like that (and was ignored) and because it
> doesn't appear to do anything. From where I sit this was, and
> remains, equally parts comical and frustrating.
Agreed. :) Anyway, when you do review it, I think you can just ignore
patch 5, and if a v9 isn't needed, a brand new patch for that logic can
be created later.
--
Kees Cook
next prev parent reply other threads:[~2023-12-08 22:05 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-10 22:20 [PATCH v8 0/5] Reduce overhead of LSMs with static calls KP Singh
2023-11-10 22:20 ` [PATCH v8 1/5] kernel: Add helper macros for loop unrolling KP Singh
2023-11-10 22:20 ` [PATCH v8 2/5] security: Count the LSMs enabled at compile time KP Singh
2023-11-10 22:20 ` [PATCH v8 3/5] security: Replace indirect LSM hook calls with static calls KP Singh
2023-11-10 22:20 ` [PATCH v8 4/5] bpf: Only enable BPF LSM hooks when an LSM program is attached KP Singh
2023-11-10 22:20 ` [PATCH v8 5/5] security: Add CONFIG_SECURITY_HOOK_LIKELY KP Singh
2023-12-08 17:36 ` Kees Cook
2023-12-08 17:46 ` Paul Moore
2023-12-08 17:55 ` Paul Moore
2023-12-08 18:22 ` Kees Cook
2023-12-08 20:51 ` Paul Moore
2023-12-08 21:13 ` Kees Cook
2023-12-08 21:43 ` Paul Moore
2023-12-08 22:05 ` Kees Cook [this message]
2023-12-08 22:40 ` KP Singh
2023-12-08 22:59 ` Paul Moore
2023-12-08 23:06 ` KP Singh
2023-12-08 23:27 ` Paul Moore
2023-12-08 22:56 ` Tetsuo Handa
2023-11-11 0:07 ` [PATCH v8 0/5] Reduce overhead of LSMs with static calls Andrii Nakryiko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202312081352.6587C77@keescook \
--to=keescook@chromium.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=casey@schaufler-ca.com \
--cc=daniel@iogearbox.net \
--cc=kpsingh@kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=paul@paul-moore.com \
--cc=renauld@google.com \
--cc=song@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).