On Sun, 2015-09-27 at 18:23 +0300, Petko Manolov wrote: > On 15-09-23 23:06:54, Mimi Zohar wrote: > > On Tue, 2015-09-22 at 18:19 +0300, Petko Manolov wrote: > > > > > > Well, this is a sore point. I don't have sufficient knowledge about how > > > audit_rule_xxx callbacks work and the only safe workaround i could think > > > of > > > is to move this call out of the ima_match_policy()'s big RCU read lock. > > > > The LSM rule numbers change when the LSM policy (eg. SELinux) is reloaded. > > All of the old LSM policy rules will be included in the new policy, so > > there > > shouldn't be a problem with simply replacing the old LSM rule number with > > the > > new one. > > OK. > > > > I suggest that we run another list_for_each_entry(entry, ima_rules, list) > > > loop and update the LSM rules there, where taking a mutex is legal. What > > > would you say? > > > > The mutex prevented the concurrent udpate. As there shouldn't be any side > > affects with updating the field multiple times, I would leave it alone. > > This means the patch stays as it is?
Yes. > > > Yes, i did. The problem with list_splice_tail_init() is not RCU safe and > > > it > > > does pointer assignment in the wrong way for us. If i used it i should > > > have > > > put spinlocks around the call, which i thought i can avoid. > > > > > > include/linux/rculist.h has only one splice routine, > > > list_splice_init_rcu(), > > > but it creates stack structure, not queue. > > > > > > The pointers assignment is done in such order so any in-flight readers > > > will > > > either see the old policy or the combined one, not a disjointed version > > > of > > > it. This is guaranteed by the way the readers walk the list, IOW - > > > forward. > > > > > > This line is the key: rcu_assign_pointer(list_next_rcu(policy->prev), > > > first); > > > > Fine, eventually this code should be moved to rculist.h. > > I just sent a patch to Paul McKenney doing just that. However, i suggest > that > we don't wait for him applying the said patch as it may take some time. Agreed. > Do you want me to do anything else or the two patches i sent earlier (one > adding > additional keyring and another for IMA policy updates) are OK for mainlining? > > As far as i can tell we're late for 4.3, but let's aim for 4.4 window. Definitely way too late for 4.3. In general, for patches being upstreamed via the linux-security subsystem, patches are first upstreamed via their respective trees. For integrity, the patches first go into the linux-integrity next branch. (linux-next automatically picks up these patches.) Pull requests for the different linux-security subsystems (eg. SELinux, smack, apparmor, capabilities, YAMA, integrity, etc) are sent around rc4 to James. During the open window, James sends a pull request to Linus. Mimi > > thanks, > Petko -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
