On Thu, Mar 9, 2023 at 2:18 PM Stephen Smalley
<stephen.smalley.work@xxxxxxxxx> wrote:
>
> Linus observed that the pervasive passing of selinux_state pointers
> introduced by me in commit aa8e712cee93 ("selinux: wrap global selinux
> state") adds overhead and complexity without providing any
> benefit. The original idea was to pave the way for SELinux namespaces
> but those have not yet been implemented and there isn't currently
> a concrete plan to do so. Remove the passing of the selinux_state
> pointers, reverting to direct use of the single global selinux_state,
> and likewise remove passing of child pointers like the selinux_avc.
> The selinux_policy pointer remains as it is needed for atomic switching
> of policies.
>
> Suggested-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
> Signed-off-by: Stephen Smalley <stephen.smalley.work@xxxxxxxxx>
> ---
> security/selinux/avc.c | 197 ++++-----
> security/selinux/hooks.c | 549 ++++++++++---------------
> security/selinux/ibpkey.c | 2 +-
> security/selinux/ima.c | 37 +-
> security/selinux/include/avc.h | 29 +-
> security/selinux/include/avc_ss.h | 3 +-
> security/selinux/include/conditional.h | 4 +-
> security/selinux/include/ima.h | 10 +-
> security/selinux/include/security.h | 171 +++-----
> security/selinux/netif.c | 2 +-
> security/selinux/netlabel.c | 17 +-
> security/selinux/netnode.c | 4 +-
> security/selinux/netport.c | 2 +-
> security/selinux/selinuxfs.c | 208 ++++------
> security/selinux/ss/services.c | 346 +++++++---------
> security/selinux/ss/services.h | 1 -
> security/selinux/status.c | 44 +-
> security/selinux/xfrm.c | 20 +-
> 18 files changed, 651 insertions(+), 995 deletions(-)
It looks like this patch was a bit too big for the mailing list; I'm
trimming my reply to get this discussion on the list.
I strongly dislike merging patches that haven't hit the list, but I do
recognize that this is a bit of an unusual case. Have you tried
breaking this up into two (three?) patches? I imagine that should be
possible, although I worry that the time required to do that would be
prohibitive given the change itself.
If that doesn't work, an alternative might be to file a PR against our
kernel subsystem mirror on GitHub and posting a link to the PR here.
I don't want to encourage this as a general way of submitting SELinux
kernel patches, but I could make an exception here.
https://github.com/SELinuxProject/selinux-kernel
--
paul-moore.com
