On Fri, Sep 16, 2016 at 06:15:01AM -0700, William Roberts wrote: > On Fri, Sep 16, 2016 at 6:09 AM, Janis Danisevskis <jda...@google.com> wrote: > > I don't mind. Then before sefcontext_compile -r gets widely adapted we > > should change the semantic quickly. I'll prepare a patch. > > Did I miss something and this was merged? Iv'e been out recovering > from a surgery so I haven't been > following this as well as I normally would have, > > If its merged, just leave it.
Its the very latest thing in master yeah, but I do also agree with changing it. I just wanted to add that from a distro perspective, compiling things by default makes more sense. In gentoo, the package post_install runs sefcontext_compile. Using the fcontext files happens a lot more than any updates to libselinux (and thus potential format changes) so I'm pretty sure most people would prefer to have the speedup. Gentoo does it on the machine itself, I am not sure about redhat or debian but I wouldnt be surprised if they do it per-arch at the very least so cross-arch probably isnt an issue. Also, I think we should add the arch to the version string stored. I would rather have false negatives than positives especially since we are not 100% sure exactly what part of the arch is important. We can always loosen it up later if that gets locked down. Isnt the selinux policy in android stored in the rootfs or /system? isnt that all read-only? how would re-compiling on the device work? Does android put the fcontext.bin files on /data? that seems insecure. -- Jason > > On Fri, Sep 16, 2016 at 1:35 PM William Roberts <bill.c.robe...@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> > > > > -- > Respectfully, > > William C Roberts > _______________________________________________ > 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. _______________________________________________ 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.
