Thank you very much for your help, Mr Stephen Smalley and Mr Paul Moore
I modified my source code like it to make fast the booting time.
------------------------------------------------------------------------------------------
--- a/security/selinux/selinuxfs.c
+++ b/security/selinux/selinuxfs.c
@@ -75,6 +75,8 @@ static char policy_opened;
/* global data for policy capabilities */
static struct dentry *policycap_dir;
+static int booting = 1;
+
/* Check whether a task is allowed to use a security operation. */
static int task_has_security(struct task_struct *tsk,
u32 perms)
@@ -177,8 +178,12 @@ static ssize_t sel_write_enforce(struct file *file,
const char __user *buf,
from_kuid(&init_user_ns, audit_get_loginuid(current)),
audit_get_sessionid(current));
selinux_enforcing = new_value;
- if (selinux_enforcing)
- avc_ss_reset(0);
+ if (selinux_enforcing){
+ if(!booting){
+ avc_ss_reset(0);
+ }
+ booting = 0;
+ }
selnl_notify_setenforce(selinux_enforcing);
selinux_status_update_setenforce(selinux_enforcing);
}
diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
index 18caa16..055157f 100644
--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@ -1870,7 +1870,7 @@ int security_load_policy(void *data, size_t len)
ss_initialized = 1;
seqno = ++latest_granting;
selinux_complete_init();
- avc_ss_reset(seqno);
+ //avc_ss_reset(seqno);
selnl_notify_policyload(seqno);
selinux_status_update_policyload(seqno);
selinux_netlbl_cache_invalidate();
------------------------------------------------------------------------------------------
But I think your code is better than mine, because I am a novice on selinux.
After applying the code you shared me, the selinux initializing time is
decrease (0.5ms -> 0.15ms)
I will try more tests to find out the other effects of the code.
Thank you
Best regards
2014-06-26 23:37 GMT+09:00 Stephen Smalley <[email protected]>:
> On 06/25/2014 04:36 AM, Jaejyn Shin wrote:
> >
> > Dear SEAndroid and SELinux developer
> > First of all, I always appreciate that I get lots of information in this
> > e-mailing list.
> >
> > After applying kernel 3.10, the booting time of my device has been
> > increased
> > Especially, the selinux initializing time is increased (about 0.5s).
> >
> > I analized the reason, and I found that the synchronize_net function has
> > 0.1s delay.
> >
> > before)
> > selinux_initialize
> > -> selinux_android_load_policy
> > -> selinux_android_reload_policy
> > -> security_load_policy
> > -> avc_ss_reset
> > -> sel_netport_avc_callback -> synchronize_net
> > -> sel_netnode_avc_callback -> synchronize_net
> > -> sel_netif_avc_callback -> synchronize_net
> > -> security_setenforce
> > -> sel_write_enforce
> > -> avc_ss_reset
> > -> sel_netport_avc_callback -> synchronize_net
> > -> sel_netnode_avc_callback -> synchronize_net
> > -> sel_netif_avc_callback -> synchronize_net
> > To make fast the booting time, can I don't call the avc_ss_reset
> > function only during initializing selinux ?:
> >
> > after)
> > selinux_initialize
> > -> selinux_android_load_policy
> > -> selinux_android_reload_policy
> > -> security_load_policy
> > X-> avc_ss_reset
> > -> security_setenforce
> > -> sel_write_enforce
> > X-> avc_ss_reset
> >
> > Is it possible?
>
> I took discussion of this issue over to selinux list since it is a
> general selinux kernel issue, see:
> http://marc.info/?t=140372402600004&r=1&w=2
>
> That thread is to consider what we can do in the general case, and will
> likely coalesce the multiple synchronize_net() calls from the individual
> callback functions into a single call.
>
> I think we can further optimize for Android since we know that initial
> policy load always precedes network interface configuration and since we
> know that we will always be performing a setenforce 1 immediately after
> initial policy load. So in that case, we could skip the first
> avc_ss_reset() call altogether and only trigger it from the
> sel_write_enforce() code path. I'd rather keep it there so that
> subsequent setenforce 0; setenforce 1; sequences will correctly flush
> the cache of any permissions granted while in permissive mode.
>
> Attached is an untested patch you could try to see if it resolves the
> issue.
>
_______________________________________________
Seandroid-list mailing list
[email protected]
To unsubscribe, send email to [email protected].
To get help, send an email containing "help" to
[email protected].
