I don't mind. Then before sefcontext_compile -r gets widely adapted we
should change the semantic quickly. I'll prepare a patch.

On Fri, Sep 16, 2016 at 1:35 PM William Roberts <bill.c.roberts@gmail.com>
wrote:

> <snip>
> >
> >
> > That's just the thing. Without -r the phone _will_ boot because the
> regexes
> > are compiled on first use. With -r and an arch mismatch we have an
> undefined
> > behavior, which is bad.
>
> That's just a limitation of the current design.
>
> >
> > See, I don't currently know what part of the architecture is important.
> Will
> > word size and endianess be enough, e.g., will regexes generated on
> x86_64el
> > work on armv8el (apparently this is what I observed but it could change
> at
> > the whim of the PCRE2 maintainers)? So what will be the encoding? If we
> > encode the complete architecture then the typical case for android
> (build on
> > x86_64 for armv7/armv8) will yield the same result as without the -r
> option,
> > namely, we rebuild the regexes on the device. If we just encode word size
> > and endianess it may work for a while... I just don't feel comfortable
> > enough to make a decision at this point.
>
> Then shelve it and use textual file contexts. The only purpose of the
> binary format is to
> include the pre-compiled regex;s so if you cant use that feature,
> there's no point in
> using binary format.
>
> My thought would be that it has to be an exact match for architecture
> upfront, then
> possibly investigate relaxing the requirement later. But, IIRC, if we get
> a 30%
> increase in text file load time, theirs really no point, for the
> binary format on Android.
> Android fic files are smaller, and have much simpler regex's compared
> to our desktop
> brethren.
>
> >
> > My limited understanding is that the automata built by PCRE2 use
> pointers to
> > link states or other structures. These pointers are symbolized when
> > serialized, but they keep their width, which is why the regexes are at
> least
> > sensitive to the word size.
> >
> > Just a wild Idea:
> > PCRE2 also supports JIT compiling. I did not use this here because I did
> not
> > feel comfortable for libselinux to depend on the execmem permission. But
> > this could be developed into pre cross compiling the regexes into native
> > code, which can than be linked into a device specific library. But I
> guess
> > this would require quite some cooperation with the PCRE2 developers.
>
> I was going to ask if the arch dependency was on JIT'd code or just
> something else
> which you elaborated above with word size/endiness, etc.
>
> >
> >>
> >> The other thing is, this is only an issue on binary formated
> file_context
> >> files,
> >> this is the ideal reason to move back to text files, since their is no
> >> speedup
> >> gained if we have to compile them.
> >
> >
> > Right, or you could see it as an intermediate solution that does not
> require
> > changes to the build system until we can properly cross compile the
> regexes.
>
> If you add an option to sefcontext_compile it should be to remove
> them. not add it in.
> This keeps it consistent with teh behavior for PCRE, it would be add
> to say, "make me
> a binary fc, but don't actually embed the regex information", since
> that is currently not
> the default behavior. Changing the Android make recipe is trivial, so
> adding -r shouldn't
> for Android shouldn't be a show stopper.
>
> <snip>
>