On Wed, Aug 26, 2020 at 3:51 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > On Wed, Aug 26, 2020 at 9:02 AM Stephen Smalley > <stephen.smalley.work@xxxxxxxxx> wrote: > > Generally the core SELinux permission checking code assumes it can be > > called from any context (including hardirq) and under any locking > > conditions, and hooks that are for permission checking (not security > > blob allocation/management) do the same. This allows permission > > checks to be performed while locks are held by the caller. and from > > arbitrary contexts I'd be inclined to just leave selinux_lockdown > > unchanged given that it might be called anywhere much like capable(). > > Agreed. The code paths relating to policy load, etc. are good > candidates for an ATOMIC->KERNEL conversion, assuming no other > constraints, but I'm somewhat nervous of converting stuff in hook.c > that doesn't have a hard sleep-ability defined. OK, I can drop the selinux_lockdown() hunk then. The other hooks.c hunks both have an existing GFP_KERNEL allocation in the same function, so I'd tend to keep them for consistency. Or do you want me to rather convert the GFP_KERNELs to GFP_ATOMICs there? > > The other question about this patchset is motivation: were you seeing > problem reports relating to SELinux memory failures when the system > was under pressure, or is this preemptive? No, I just went over the GFP_* usage in security/selinux/ when scoping how many GFP_ATOMIC ones could be changed to GFP_KERNEL after the refcount patch and found these that could be switched right away. -- Ondrej Mosnacek Software Engineer, Platform Security - SELinux kernel Red Hat, Inc.
