If Bin is using our N tree, then all the stuff for debugfs are exact matches:
/sys/kernel/debug/sync u:object_r:debugfs_graphics_sync:s0 /sys/kernel/debug/dri/0/i915_frequency_info u:object_r:debugfs_graphics:s0 /sys/kernel/debug/pstate_snb/setpoint u:object_r:debugfs_pstate:s0 Bin, can you confirm the state of your tree? You can run this command to find the entries: find . -name file_contexts | xargs grep 'kernel/debug' Thanks, Bill From: Nick Kralevich [mailto:n...@google.com] Sent: Wednesday, October 12, 2016 11:42 AM To: Roberts, William C <william.c.robe...@intel.com> Cc: Stephen Smalley <s...@tycho.nsa.gov>; seandroid-list@tycho.nsa.gov; Yang, Bin Y <bin.y.y...@intel.com> Subject: Re: labelling /sys/kernel/debug aka debugfs Can you attach the file_contexts file you're using? Or at least all the entries starting with /sys? In the past, when I've seen this kind of slow restorecon on boot, it's been due to a regex which defeats the restorecon directory tree walking optimizations. -- Nick On Wed, Oct 12, 2016 at 6:42 AM, Roberts, William C <william.c.robe...@intel.com<mailto:william.c.robe...@intel.com>> wrote: > -----Original Message----- > From: Stephen Smalley [mailto:s...@tycho.nsa.gov<mailto:s...@tycho.nsa.gov>] > Sent: Wednesday, October 12, 2016 9:37 AM > To: Roberts, William C > <william.c.robe...@intel.com<mailto:william.c.robe...@intel.com>>; 'seandroid- > l...@tycho.nsa.gov<mailto:l...@tycho.nsa.gov>' > <seandroid-list@tycho.nsa.gov<mailto:seandroid-list@tycho.nsa.gov>> > Cc: Yang, Bin Y <bin.y.y...@intel.com<mailto:bin.y.y...@intel.com>> > Subject: Re: labelling /sys/kernel/debug aka debugfs > > On 10/12/2016 09:24 AM, Roberts, William C wrote: > > It’s been reported that labelling via restorecon_recursive > > /sys/kernel/debug is taking 0.25s on a device. I wanted to verify a > > thought: > > > > > > > > It looks like genfscon per file labeling is supported by selinux (like > > procfs), on linux master branch, I see: > > > > > > > > selinux_set_mnt_opts(): > > > > <snip> > > > > 815 if (!strcmp(sb->s_type->name, "debugfs") || > > > > 816 !strcmp(sb->s_type->name, "sysfs") || > > > > 817 !strcmp(sb->s_type->name, "pstore")) > > > > 818 sbsec->flags |= SE_SBGENFS; > > > > <snip> > > > > > > > > Would using genfscon statements and removing the restorecon_recursive > > be faster since it avoids the tree walk? Any caveats, issues one can think > > of? > > First, I'd be interested in understanding why that is taking so long, and > compare > with time on restorecon_recursive /sys (performed directly by init). > > The SE for Android todo list does suggest investigating this for replacing the > restorecon_recursive /sys, so it would make sense to investigate it for both. > It > does require that the device kernel include the necessary support. As noted in > https://android-review.googlesource.com/#/c/151776/, you are also limited in > that genfscon only supports pathname prefix matching, not regexes. I don't see any uses where the lack of regex support would be a problem. I'll see if Bin, the reporter, can collect more stats for us, Yang could you collect those? _______________________________________________ Seandroid-list mailing list Seandroid-list@tycho.nsa.gov<mailto:Seandroid-list@tycho.nsa.gov> To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov<mailto:seandroid-list-le...@tycho.nsa.gov>. To get help, send an email containing "help" to seandroid-list-requ...@tycho.nsa.gov<mailto:seandroid-list-requ...@tycho.nsa.gov>. -- Nick Kralevich | Android Security | n...@google.com<mailto:n...@google.com> | 650.214.4037
_______________________________________________ Seandroid-list mailing list Seandroid-list@tycho.nsa.gov To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov. To get help, send an email containing "help" to seandroid-list-requ...@tycho.nsa.gov.
