On Wed, Aug 26, 2020 at 10:12 AM Ondrej Mosnacek <omosnace@xxxxxxxxxx> wrote: > > 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? No, I was fine with the other parts of the patch just not the lockdown one, because it can be called from many places like capable().
