I don't really care much about the behavior of sefcontext_compile. I just
thought making the default behavior the safest would be the best option.
Before android is using it, I will have to sync the (now modified and
improved - thank you) patches back into AOSP, which I intend to do. I have
some benchmarks measuring load and lookup time for file contexts. I am
eager to review and benchmark William's patches and explore a bit myself.
And once all options are on the table I can make a case for the fastest
solution to make it into Android.
Concerning the arch string I respond in the other add support for pcre2
On Fri, Sep 16, 2016 at 4:20 PM, William Roberts <bill.c.robe...@gmail.com>
> On Sep 16, 2016 08:12, "Stephen Smalley" <s...@tycho.nsa.gov> wrote:
> > On 09/16/2016 11:08 AM, William Roberts wrote:
> > > On Fri, Sep 16, 2016 at 7:41 AM, Stephen Smalley <s...@tycho.nsa.gov>
> > >> On 09/16/2016 09:08 AM, Janis Danisevskis wrote:
> > >>> This patch reestablishes the default behavior of sefcontext_compile
> > >>> to include precompiled regular expressions in the output. If linked
> > >>> against PCRE2 the flag "-r" now causes the precompiled regular
> > >>> expressions to be omitted from the output.
> > >>
> > >> I thought your original rationale was more compelling. If we add
> > >> detection of the relevant arch properties, then we can do this.
> > >> Otherwise, I don't think we should.
> > >
> > > I was assuming based on the thread earlier that those patches would be
> > > If we cant detect and compile on the current "undefined behavior"
> > > case, then this
> > > needs to stay as is.
> > >
> > > But I thought someone had a list of PCRE things that can be checked
> for "arch",
> > > so its just a matter of encoding those, assuming that list is correct.
> > >
> > > Binary file_contexts only make sense if you compile in the regex info,
> > > just use the textual representation.
> > That was my thought originally, but Janis did say that it was still
> > faster, and Android presently only ships file_contexts.bin, so we can't
> > just break that.
> I'm not saying that we break anything, but I think we should really
> scrutinize the decision to keep binary fc's on Android. The only way it
> could be faster at the moment is mmap and pcre2. We need to get some raw
> numbers of pcre2 textual vs binary load times. If it's within 30% I'll have
> that gap closed soon. It also takes up about 3 times the disk space for
Seandroid-list mailing list
To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov.
To get help, send an email containing "help" to