From: KP Singh <kpsingh@kernel.org>
To: Xu Kuohai <xukuohai@huaweicloud.com>
Cc: bpf@vger.kernel.org, linux-security-module@vger.kernel.org,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Martin KaFai Lau <martin.lau@linux.dev>,
Eduard Zingerman <eddyz87@gmail.com>, Song Liu <song@kernel.org>,
Yonghong Song <yonghong.song@linux.dev>,
John Fastabend <john.fastabend@gmail.com>,
Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>,
Jiri Olsa <jolsa@kernel.org>,
Florent Revest <revest@chromium.org>,
Brendan Jackman <jackmanb@chromium.org>,
Paul Moore <paul@paul-moore.com>,
James Morris <jmorris@namei.org>,
"Serge E . Hallyn" <serge@hallyn.com>,
Khadija Kamran <kamrankhadijadj@gmail.com>,
Casey Schaufler <casey@schaufler-ca.com>,
Ondrej Mosnacek <omosnace@redhat.com>,
Kees Cook <keescook@chromium.org>,
John Johansen <john.johansen@canonical.com>,
Lukas Bulwahn <lukas.bulwahn@gmail.com>,
Roberto Sassu <roberto.sassu@huawei.com>,
Shung-Hsi Yu <shung-hsi.yu@suse.com>
Subject: Re: [PATCH bpf-next v2 2/7] bpf, lsm: Add return value range description for lsm hook
Date: Tue, 9 Apr 2024 00:15:41 +0200 [thread overview]
Message-ID: <CACYkzJ5wExNrQYKckVrnbFbFXP8S6oWqG8GU8iaMJTMNbFTDSg@mail.gmail.com> (raw)
In-Reply-To: <7FAC6C1E-B0C2-4743-AFF0-0DCC2B331D0A@kernel.org>
On Mon, Apr 8, 2024 at 7:09 PM KP Singh <kpsingh@kernel.org> wrote:
>
>
>
> > On 25 Mar 2024, at 10:56, Xu Kuohai <xukuohai@huaweicloud.com> wrote:
> >
> > From: Xu Kuohai <xukuohai@huawei.com>
> >
> > Add return value descriptions for lsm hook.
> >
> > Two integer ranges are added:
> >
> > 1. ERRNO: Integer between -MAX_ERRNO and 0, including -MAX_ERRNO and 0.
I also don't really like these special macros that imply a range. Why
not do something like?
LSM_RET_INT(default, min, max)
You seemed to have missed the values returned by these hooks:
security_inode_need_killpriv
security_inode_getsecurity
security_inode_listsecurity
security_inode_copy_up_xattr
security_task_prctl
security_getprocattr
securitty_setprocattr
^^these two we should just disable in BPF LSM
security_ismaclabel
^^probably even this
There seem to be only a handful of these. Can we just manage it with a
BTF set on the BPF side?
- KP
> > 2. ANY: Any integer
>
>
> I think you should merge this patch and the first patch. It's not clear that the first value in this macro is actually used as the default value until one reads the code. I think you also need to make it clear that there is no logical change on the LSM side in the this patch.
>
> - KP
next prev parent reply other threads:[~2024-04-08 22:15 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-25 9:56 [PATCH bpf-next v2 0/7] Add check for bpf lsm return value Xu Kuohai
2024-03-25 9:56 ` [PATCH bpf-next v2 1/7] bpf, lsm: Annotate lsm hook return integer with new macro LSM_RET_INT Xu Kuohai
2024-03-25 9:56 ` [PATCH bpf-next v2 2/7] bpf, lsm: Add return value range description for lsm hook Xu Kuohai
2024-04-08 17:09 ` KP Singh
2024-04-08 22:15 ` KP Singh [this message]
2024-04-10 12:30 ` Xu Kuohai
2024-03-25 9:56 ` [PATCH bpf-next v2 3/7] bpf, lsm: Add function to read lsm hook return value range Xu Kuohai
2024-03-25 9:56 ` [PATCH bpf-next v2 4/7] bpf, lsm: Check bpf lsm hook return values in verifier Xu Kuohai
2024-03-25 9:56 ` [PATCH bpf-next v2 5/7] bpf: Fix compare error in function retval_range_within Xu Kuohai
2024-03-25 9:56 ` [PATCH bpf-next v2 6/7] selftests/bpf: Avoid load failure for token_lsm.c Xu Kuohai
2024-03-25 9:56 ` [PATCH bpf-next v2 7/7] selftests/bpf: Add return value checks and corrections for failed progs Xu Kuohai
2024-04-08 21:45 ` [PATCH bpf-next v2 0/7] Add check for bpf lsm return value KP Singh
2024-04-10 12:34 ` Xu Kuohai
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=CACYkzJ5wExNrQYKckVrnbFbFXP8S6oWqG8GU8iaMJTMNbFTDSg@mail.gmail.com \
--to=kpsingh@kernel.org \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=casey@schaufler-ca.com \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=haoluo@google.com \
--cc=jackmanb@chromium.org \
--cc=jmorris@namei.org \
--cc=john.fastabend@gmail.com \
--cc=john.johansen@canonical.com \
--cc=jolsa@kernel.org \
--cc=kamrankhadijadj@gmail.com \
--cc=keescook@chromium.org \
--cc=linux-security-module@vger.kernel.org \
--cc=lukas.bulwahn@gmail.com \
--cc=martin.lau@linux.dev \
--cc=omosnace@redhat.com \
--cc=paul@paul-moore.com \
--cc=revest@chromium.org \
--cc=roberto.sassu@huawei.com \
--cc=sdf@google.com \
--cc=serge@hallyn.com \
--cc=shung-hsi.yu@suse.com \
--cc=song@kernel.org \
--cc=xukuohai@huaweicloud.com \
--cc=yonghong.song@linux.dev \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).