You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on May 24, 2023. It is now read-only.
I found that if using the checkpolicy tool to generate sepolicy with cil mode, a lot of "base_typeattr_xx" will be auto-generated. And each of them contain a lot of types. So the "ebitmap_for_each_positive_bit" loop in context_struct_compute_av() function will run 10x times more than policy directly generated from policy.conf file.
if I comment the libsepol's set_to_cil_attr() function and re-generate cil. Kernel runs fast and happy as the non-cil mode
So, why we need so many "base_typeattr_xx" ? Is it a safe way to remove those auto-generated attributes?
On 03/20/2017 10:56 PM, stesen wrote:
I found that if using the checkpolicy tool to generate sepolicy with cil mode, a
lot of "base_typeattr_xx" will be auto-generated. And each of them contain a lot
of types. So the "ebitmap_for_each_positive_bit" loop in
context_struct_compute_av() function will run 10x times more than policy
directly generated from policy.conf file.
if I comment the libsepol's set_to_cil_attr() function and re-generate cil.
Kernel runs fast and happy as the non-cil mode
So, why we need so many "base_typeattr_xx" ? Is it a safe way to remove those
auto-generated attributes?
CIL does not allow type set expressions in av rules (allow, neverallow, etc), so
an attribute needs to be created anywhere a type set expression occurs. Most of
the type sets occur in neverallow rules, so this often does not cause a problem.
It is true that too many attributes can slow things down. Originally, all
attributes were expanded when the policy was created, but at some point the
policy size started becoming too large and the kernel was modified to allow
attributes to be preserved.
What policy did you observe this for? Fedora's, Refpolicy, or something else?
I am working on android. the latest code shows that android will using CIL in the next version.
It seems that base_typeattr_x can decrease the policy size, but use more cpu resource. So do you have some advices? Is that a good choice to set a limit number for one "base_typeattr_"?
Activity
jwcart2 commentedon Mar 21, 2017
stesen commentedon Mar 22, 2017
Thankyou for your reply :)
I am working on android. the latest code shows that android will using CIL in the next version.
It seems that base_typeattr_x can decrease the policy size, but use more cpu resource. So do you have some advices? Is that a good choice to set a limit number for one "base_typeattr_"?
Add attribute expansion options
Add attribute expansion options
Add attribute expansion options
Add attribute expansion options
Add attribute expansion options
Add attribute expansion options
Add attribute expansion options
stesen commentedon Sep 3, 2018
Thank You :)