Fwd: Booting time is increased after applying kernel 3.10

Fwd: Booting time is increased after applying kernel 3.10

[Stephen Smalley]

(fwd to selinux list as this is a general selinux kernel issue)

---------- Forwarded message ----------
From: Jaejyn Shin <flagon22bass@gmail.com>
Date: Wed, Jun 25, 2014 at 4:36 AM
Subject: Booting time is increased after applying kernel 3.10
To: "seandroid-list@tycho.nsa.gov" <seandroid-list@tycho.nsa.gov>



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?

Thank you
Best regards

_______________________________________________
Seandroid-list mailing list
Seandroid-list@tycho.nsa.gov
To unsubscribe, send email to Seandroid-list-leave@tycho.nsa.gov.
To get help, send an email containing "help" to
Seandroid-list-request@tycho.nsa.gov.

Re: Fwd: Booting time is increased after applying kernel 3.10

[Paul Moore]

On Wednesday, June 25, 2014 03:14:56 PM Stephen Smalley wrote:
> ---------- Forwarded message ----------
> From: Jaejyn Shin <flagon22bass@gmail.com>
> Date: Wed, Jun 25, 2014 at 4:36 AM
> Subject: Booting time is increased after applying kernel 3.10
> To: "seandroid-list@tycho.nsa.gov" <seandroid-list@tycho.nsa.gov>
> 
> 
> 
> 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.

I would need to give it some more thought, but since the netport/netnode/netif 
caches all have their own locks it may be possible to skip the 
synchronize_net() call.  Although, looking at this a bit closer, I wonder if 
it would be possible to just skip the avc_ss_reset() call for the initial 
policy load, or at least skip the callback processing.  Am I missing 
something?
 
> 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?
> 
> Thank you
> Best regards
> 
> _______________________________________________
> Seandroid-list mailing list
> Seandroid-list@tycho.nsa.gov
> To unsubscribe, send email to Seandroid-list-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to
> Seandroid-list-request@tycho.nsa.gov.

-- 
paul moore
www.paul-moore.com

Re: Fwd: Booting time is increased after applying kernel 3.10

[Stephen Smalley]

I suspect it won't matter in practice, but the reason for it is that
permissions or other state may have been cached during bootup prior to
initial policy load that may no longer be valid.

On Wed, Jun 25, 2014 at 3:29 PM, Paul Moore <paul@paul-moore.com> wrote:
> On Wednesday, June 25, 2014 03:14:56 PM Stephen Smalley wrote:
>> ---------- Forwarded message ----------
>> From: Jaejyn Shin <flagon22bass@gmail.com>
>> Date: Wed, Jun 25, 2014 at 4:36 AM
>> Subject: Booting time is increased after applying kernel 3.10
>> To: "seandroid-list@tycho.nsa.gov" <seandroid-list@tycho.nsa.gov>
>>
>>
>>
>> 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.
>
> I would need to give it some more thought, but since the netport/netnode/netif
> caches all have their own locks it may be possible to skip the
> synchronize_net() call.  Although, looking at this a bit closer, I wonder if
> it would be possible to just skip the avc_ss_reset() call for the initial
> policy load, or at least skip the callback processing.  Am I missing
> something?
>
>> 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?
>>
>> Thank you
>> Best regards
>>
>> _______________________________________________
>> Seandroid-list mailing list
>> Seandroid-list@tycho.nsa.gov
>> To unsubscribe, send email to Seandroid-list-leave@tycho.nsa.gov.
>> To get help, send an email containing "help" to
>> Seandroid-list-request@tycho.nsa.gov.
>
> --
> paul moore
> www.paul-moore.com
>

Re: Fwd: Booting time is increased after applying kernel 3.10

[Jaejyn Shin]

[-- Attachment #1: Type: text/plain, Size: 3018 bytes --]

Thank you for your comment.
Then, I will remove the calling avc_ss_reset during bootup and test my
device many times to find side-effect.


2014-06-26 4:49 GMT+09:00 Stephen Smalley <stephen.smalley@gmail.com>:

> I suspect it won't matter in practice, but the reason for it is that
> permissions or other state may have been cached during bootup prior to
> initial policy load that may no longer be valid.
>
> On Wed, Jun 25, 2014 at 3:29 PM, Paul Moore <paul@paul-moore.com> wrote:
> > On Wednesday, June 25, 2014 03:14:56 PM Stephen Smalley wrote:
> >> ---------- Forwarded message ----------
> >> From: Jaejyn Shin <flagon22bass@gmail.com>
> >> Date: Wed, Jun 25, 2014 at 4:36 AM
> >> Subject: Booting time is increased after applying kernel 3.10
> >> To: "seandroid-list@tycho.nsa.gov" <seandroid-list@tycho.nsa.gov>
> >>
> >>
> >>
> >> 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.
> >
> > I would need to give it some more thought, but since the
> netport/netnode/netif
> > caches all have their own locks it may be possible to skip the
> > synchronize_net() call.  Although, looking at this a bit closer, I
> wonder if
> > it would be possible to just skip the avc_ss_reset() call for the initial
> > policy load, or at least skip the callback processing.  Am I missing
> > something?
> >
> >> 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?
> >>
> >> Thank you
> >> Best regards
> >>
> >> _______________________________________________
> >> Seandroid-list mailing list
> >> Seandroid-list@tycho.nsa.gov
> >> To unsubscribe, send email to Seandroid-list-leave@tycho.nsa.gov.
> >> To get help, send an email containing "help" to
> >> Seandroid-list-request@tycho.nsa.gov.
> >
> > --
> > paul moore
> > www.paul-moore.com
> >
>

[-- Attachment #2: Type: text/html, Size: 4623 bytes --]

Re: Fwd: Booting time is increased after applying kernel 3.10

[Stephen Smalley]

On 06/25/2014 03:49 PM, Stephen Smalley wrote:
> I suspect it won't matter in practice, but the reason for it is that
> permissions or other state may have been cached during bootup prior to
> initial policy load that may no longer be valid.

So, as far as the netif/node/port caches are concerned, the potential
concern is that if we perform any netif/node/port SID lookups prior to
initial policy load, then the kernel security server will always return
the netif/node/port initial SIDs, and those SIDs will be cached for any
such interfaces, IP addresses, or port numbers looked up prior to the
policy load and continue to be used after the policy load even if the
policy defines a different context for that interface, address, or port.
 This should only be an issue if some action is performed that would
trigger a netif/node/port lookup prior to initial policy load (e.g.
network interface configuration, binding to a network port, sending or
receiving a packet), and if the policy defines a netif, node, or port
context other than the one associated with the initial netif, node, or
port SIDs for any such interface, address, or port.

So in Android at least it is a non-issue (policy is loaded by init from
the initramfs before any network interface configuration).  I'm a bit
unclear on what happens in Fedora these days from the initramfs, and how
it might deal with e.g. a nfsroot or something similar where network
interfaces may be configured and network traffic may already be
occurring before policy can be loaded from the real root filesystem.

As far as the AVC state is concerned, security_compute_av() will return
all-permissions-allowed until policy is first loaded, so the AVC may
contain cached permissions for the kernel SID for any requested
permissions prior to initial policy load, which is why we flush its
contents.  However, this should only matter for the kernel SID.

We will also perform an avc_ss_reset() on the setenforce 1 by init if
the system is enforcing to flush any permissions added to the AVC while
permissive.  So even if we were to drop the avc_ss_reset() from the
initial policy load, we would still get it on enforcing systems as a
side effect of the setenforce 1.  However, that could yield different
avc denials on a permissive vs enforcing system.

So I am not sure we can safely remove the avc_ss_reset() from initial
policy load in the mainline kernel, as we are not guaranteed that there
is no network interface configuration prior to initial policy load and
we are not guaranteed that there will be a setenforce 1.  It would
perhaps be better there to instead just avoid calling synchronize_net
altogether if possible or only call it once for the entire avc_ss_reset,
not on each of the netif/node/port callbacks.

Re: Fwd: Booting time is increased after applying kernel 3.10

[Paul Moore]

On Thursday, June 26, 2014 09:57:57 AM Stephen Smalley wrote:
> On 06/25/2014 03:49 PM, Stephen Smalley wrote:
> > I suspect it won't matter in practice, but the reason for it is that
> > permissions or other state may have been cached during bootup prior to
> > initial policy load that may no longer be valid.

...

> So I am not sure we can safely remove the avc_ss_reset() from initial
> policy load in the mainline kernel, as we are not guaranteed that there
> is no network interface configuration prior to initial policy load and
> we are not guaranteed that there will be a setenforce 1.  It would
> perhaps be better there to instead just avoid calling synchronize_net
> altogether if possible or only call it once for the entire avc_ss_reset,
> not on each of the netif/node/port callbacks.

When I took a quick glance at this briefly yesterday one of the things that 
crossed my mind was exporting the different netif/node/port flush functions 
and grouping the callbacks into a single callback that calls each of the flush 
functions and then synchronize_net() once at the end; similar to what you 
describe above.  Perhaps that is the best solution upstream.

Unless someone else wants to develop/test a patch, I'll put one together.

-- 
paul moore
www.paul-moore.com

Re: Fwd: Booting time is increased after applying kernel 3.10

[Stephen Smalley]

On 06/26/2014 10:17 AM, Paul Moore wrote:
> On Thursday, June 26, 2014 09:57:57 AM Stephen Smalley wrote:
>> On 06/25/2014 03:49 PM, Stephen Smalley wrote:
>>> I suspect it won't matter in practice, but the reason for it is that
>>> permissions or other state may have been cached during bootup prior to
>>> initial policy load that may no longer be valid.
> 
> ...
> 
>> So I am not sure we can safely remove the avc_ss_reset() from initial
>> policy load in the mainline kernel, as we are not guaranteed that there
>> is no network interface configuration prior to initial policy load and
>> we are not guaranteed that there will be a setenforce 1.  It would
>> perhaps be better there to instead just avoid calling synchronize_net
>> altogether if possible or only call it once for the entire avc_ss_reset,
>> not on each of the netif/node/port callbacks.
> 
> When I took a quick glance at this briefly yesterday one of the things that 
> crossed my mind was exporting the different netif/node/port flush functions 
> and grouping the callbacks into a single callback that calls each of the flush 
> functions and then synchronize_net() once at the end; similar to what you 
> describe above.  Perhaps that is the best solution upstream.
> 
> Unless someone else wants to develop/test a patch, I'll put one together.

Did you confirm that we need the synchronize_net() call at all?

Re: Fwd: Booting time is increased after applying kernel 3.10

[Stephen Smalley]

On 06/27/2014 08:15 AM, Stephen Smalley wrote:
> On 06/26/2014 10:17 AM, Paul Moore wrote:
>> On Thursday, June 26, 2014 09:57:57 AM Stephen Smalley wrote:
>>> On 06/25/2014 03:49 PM, Stephen Smalley wrote:
>>>> I suspect it won't matter in practice, but the reason for it is that
>>>> permissions or other state may have been cached during bootup prior to
>>>> initial policy load that may no longer be valid.
>>
>> ...
>>
>>> So I am not sure we can safely remove the avc_ss_reset() from initial
>>> policy load in the mainline kernel, as we are not guaranteed that there
>>> is no network interface configuration prior to initial policy load and
>>> we are not guaranteed that there will be a setenforce 1.  It would
>>> perhaps be better there to instead just avoid calling synchronize_net
>>> altogether if possible or only call it once for the entire avc_ss_reset,
>>> not on each of the netif/node/port callbacks.
>>
>> When I took a quick glance at this briefly yesterday one of the things that 
>> crossed my mind was exporting the different netif/node/port flush functions 
>> and grouping the callbacks into a single callback that calls each of the flush 
>> functions and then synchronize_net() once at the end; similar to what you 
>> describe above.  Perhaps that is the best solution upstream.
>>
>> Unless someone else wants to develop/test a patch, I'll put one together.
> 
> Did you confirm that we need the synchronize_net() call at all?

Let me phrase this differently:

1) Does the synchronize_net() call guarantee that after the policy load
completes (or more specifically, after the avc_ss_reset completes), all
subsequent network permission checks will be based on the
netif/node/port contexts defined by the new policy and not based on the
old ones?

-and-

2) Does anyone currently rely on this behavior, i.e. they make a change
to the netif/node/port contexts in policy, load the new policy, and need
to know that the new context assignments are being applied on every
network operation before they can proceed safely?

Re: Fwd: Booting time is increased after applying kernel 3.10

[Paul Moore]

On Friday, June 27, 2014 08:52:40 AM Stephen Smalley wrote:
> On 06/27/2014 08:15 AM, Stephen Smalley wrote:
> >
> > Did you confirm that we need the synchronize_net() call at all?

I looked into a little more yesterday and it probably isn't needed for the 
netport cache as that is only ever really used at the socket level so there is 
no need to wait on any packet processing.  We might be able to get away with 
removing for the netif and netnode caches as well since we only check those 
caches once for each packet so I don't believe there is a real worry about 
consistency.  However, I'm inclined to leave it in for now and just 
consolidate the callbacks so we only call synchronize_net() once; it's still a 
performance win and we preserve any safety benefits that may be there.

Also, in the interest of full disclosure, I've never been one of those folks 
who are militant about reducing boot times, a few milliseconds here are there 
aren't a big deal to me.  At some point I may change my opinion on boot times, 
but right now that's my thinking.

> Let me phrase this differently:
> 
> 1) Does the synchronize_net() call guarantee that after the policy load
> completes (or more specifically, after the avc_ss_reset completes), all
> subsequent network permission checks will be based on the
> netif/node/port contexts defined by the new policy and not based on the
> old ones?

Essentially the synchronize_net() call is just a synchronize_rcu() call with a 
little extra work if the routing table lock is taken, so no magic 
synchronization here.  Basically as soon as the network object cache is 
flushed new lookups to the cache will start querying the policy again, the 
synchronize_net() call really just ensures that existing RCU critical sections 
will finish up before the callback complete.

> -and-
> 
> 2) Does anyone currently rely on this behavior, i.e. they make a change
> to the netif/node/port contexts in policy, load the new policy, and need
> to know that the new context assignments are being applied on every
> network operation before they can proceed safely?

I don't believe so, at least I would advise against it as there are little 
guarantees when it comes to network I/O.

-- 
paul moore
www.paul-moore.com

Re: Fwd: Booting time is increased after applying kernel 3.10

[Ravi Kumar]

[-- Attachment #1: Type: text/plain, Size: 869 bytes --]

Hi Team ,
In reference to old discussion via the mail thread ,
http://marc.info/?l=selinux&m=140387478632108&q=raw

This is on the context on removing the synchronize_net() from bootup and
was concluded with optimization  on reducing the the number of call to
synchronize_net()  In context to to this what we are seeing is skipping the
call is saving much time  on android bootup  and based on the discussion
 at least for android  systems it look like we can still  skip this call as
suggest in the initial patch  which is much saving on the bootup time .
But still i dont see any mainline / signed off sort of patch for andriod
 or any one using this . Did we see any issue or planned different .

At least on KK the bootup time was under control for L code base we are
trying to see  all the ways of optimization  any input are greatly
 appreciated.


Regards,
Ravi

[-- Attachment #2: Type: text/html, Size: 1251 bytes --]

Re: Fwd: Booting time is increased after applying kernel 3.10

[Stephen Smalley]

On 04/01/2015 02:58 PM, Ravi Kumar wrote:
> Hi Team , 
> In reference to old discussion via the mail thread , 
> http://marc.info/?l=selinux&m=140387478632108&q=raw
> 
> This is on the context on removing the synchronize_net() from bootup and
> was concluded with optimization  on reducing the the number of call to
> synchronize_net()  In context to to this what we are seeing is skipping
> the call is saving much time  on android bootup  and based on the
> discussion  at least for android  systems it look like we can still
>  skip this call as suggest in the initial patch  which is much saving on
> the bootup time .  But still i dont see any mainline / signed off sort
> of patch for andriod  or any one using this . Did we see any issue or
> planned different .
> 
> At least on KK the bootup time was under control for L code base we are
> trying to see  all the ways of optimization  any input are greatly
>  appreciated.       

commit 615e51fdda6f274e94b1e905fcaf6111e0d9aa20
Author: Paul Moore <pmoore@redhat.com>
Date:   Thu Jun 26 14:33:56 2014 -0400

    selinux: reduce the number of calls to synchronize_net() when
flushing cache

    When flushing the AVC, such as during a policy load, the various
    network caches are also flushed, with each making a call to
    synchronize_net() which has shown to be expensive in some cases.
    This patch consolidates the network cache flushes into a single AVC
    callback which only calls synchronize_net() once for each AVC cache
    flush.

    Reported-by: Jaejyn Shin <flagon22bass@gmail.com>
    Signed-off-by: Paul Moore <pmoore@redhat.com>

Re: Fwd: Booting time is increased after applying kernel 3.10

[Stephen Smalley]

On 04/01/2015 03:20 PM, Stephen Smalley wrote:
> On 04/01/2015 02:58 PM, Ravi Kumar wrote:
>> Hi Team , 
>> In reference to old discussion via the mail thread , 
>> http://marc.info/?l=selinux&m=140387478632108&q=raw
>>
>> This is on the context on removing the synchronize_net() from bootup and
>> was concluded with optimization  on reducing the the number of call to
>> synchronize_net()  In context to to this what we are seeing is skipping
>> the call is saving much time  on android bootup  and based on the
>> discussion  at least for android  systems it look like we can still
>>  skip this call as suggest in the initial patch  which is much saving on
>> the bootup time .  But still i dont see any mainline / signed off sort
>> of patch for andriod  or any one using this . Did we see any issue or
>> planned different .
>>
>> At least on KK the bootup time was under control for L code base we are
>> trying to see  all the ways of optimization  any input are greatly
>>  appreciated.       
> 
> commit 615e51fdda6f274e94b1e905fcaf6111e0d9aa20
> Author: Paul Moore <pmoore@redhat.com>
> Date:   Thu Jun 26 14:33:56 2014 -0400
> 
>     selinux: reduce the number of calls to synchronize_net() when
> flushing cache
> 
>     When flushing the AVC, such as during a policy load, the various
>     network caches are also flushed, with each making a call to
>     synchronize_net() which has shown to be expensive in some cases.
>     This patch consolidates the network cache flushes into a single AVC
>     callback which only calls synchronize_net() once for each AVC cache
>     flush.
> 
>     Reported-by: Jaejyn Shin <flagon22bass@gmail.com>
>     Signed-off-by: Paul Moore <pmoore@redhat.com>

And this was uploaded to the Android kernel/common tree along with
various other SELinux kernel fixes/improvements, see
https://android-review.googlesource.com/#/q/owner:sds+project:kernel/common