The best I could come up with for allowing compile_seccomp_policy
to be an executable script installed via setup.py.

Originally I cooked up a trick where setup.py also had:

data_files=[('minijail', ['constants.json'])],

and compile_seccomp_policy.py used:

constants_file = 'constants.json'
if pkg_resources.resource_exists(__name__, constants_file):
    constants_file = pkg_resources.resource_filename(__name__, constants_file)

so that a package can ship with a constants.json and auotmatically use
it.  This works when installed as a 'dist-package' egg, but CrOS installs
as a 'site-package' where this trick don't work (constants.json ends up in
another location under /usr, not to mention being stored with a board) and it
complicates the dependency story for the Makefile so I punted.

For both 'dist-package' and 'site-package' the plain "import XXX" form doesn't work
for files located in the same directory (results in a ModuleNotFoundError error),
so I've added a "from minijail import XXX" fallback so new & original cases both
work okay.

Bug: None
Test: `make tests`.  Ran 'python3 setup.py install --record files.txt'
and verified the stubs in /usr/local/bin could be used to launch the 3
scripts without import errors.

Change-Id: I61fe0b624960c89fd715c1c60213edc2b736ad1c

The current generate_seccomp_policy.py can only generate policy files that
are sorted by frequency.  compile_seccomp_policy.py can accept a frequency file
(via a @frequency line in the policy file), but such a file isn't
created by generate_seccomp_policy.

This change adds a --frequency command-line option that can be used to
genreate a frequency file. For consistency I also added a --policy
option that can be used to specify the destination file for the policy
(normally the file is just sent to standard output and piped to a file).

If --frequency is used then the policy file will be generate syscall
rules in alphabetical order (vs. the frequency of the use).  Alphabetic
order makes it easier to see what syscalls are used and facilitates
manual modification.

I was tempted to also output an additional header comment to the
generated policy file (for both modes) that warn the files were
generated by a script (and to either add new syscalls in use order or to
the frequency file, as relevant for the mode that was used to create the
script).

TBD is whether to automatically add a @frequency line to the policy
file.  So far I haven't (the relative paths used to create the files
might have no relation to where the files are stored).  I thought about
adding a command-line parameter to compile_seccomp_policy.py that permits the
frequency file to be specified (instead of or in addition to @frequency) but
I didn't see a clean & easy way to add this.

Bug: None
Test: make tests
Change-Id: I9e1a5128052a7ae529b2e149c2e7bd4a263907a8

This change adds enough Android.bp rules and tools to make it possible
to compile .policy files at build-time, using the new optimizing
compiler.

This is achieved by compiling the libconstants.gen.c and
libsyscalls.gen.c into LLVM IR files (which are roughly
architecture-neutral for our purposes). These IR files are then parsed
by the `tools/generate_constants_json.py` script and produces an
architecture-specific `constants.json` file, which can be fed into
`tools/compile_seccomp_policy.py` to compile .policy files.

The last piece of the puzzle is to actually invoke the script. This
needs to be done from a cc_genrule due to the way that soong handles
target variations, and will produce artifacts that are
architecture-specific. One example to invoke the script is as follows:

    cc_genrule {
        name: "bpf_compilation",
        host_supported: true,
        vendor_available: true,
        recovery_available: true,
        tools: ["minijail_compile_seccomp_policy"],
        cmd: "$(location minijail_compile_seccomp_policy) --arch-json $(in) $(out)",
        srcs: [":minijail_constants_json", "my_seccomp.policy"],
        out: ["my_seccomp.bpf"],
    }

Bug: None
Test: mmma -j external/minijail
Test: make all
Change-Id: I835ee18c3ff515a6f3203ed86d20ad41d4f5d066

This change improves the logging of filters that have conflicting
unconditional actions. It now prints the actual line that caused the
problem (instead of just the filename), and also the last place where an
unconditional action was declared, to aid in debugging.

Bug: chromium:1033137
Test: ./tools/parser_unittest.py
Change-Id: I50f32f28d88dbd95d4d4bb3d40576fa6e91dc38a

This change adds tools/README.md, to help understand what the scripts do
and how to invoke them.

Bug: None
Test: viewed using gitiles
Change-Id: I0610fbb6840eddbc1d001169697deb9414aeb087

This change ensures that identifiers that have a prefix that is an
otherwise valid token (such as `inotify_wait` that has a prefix `in`,
which is an OP) from tokenizing the prefix as a separate token.

Bug: chromium:1024021
Test: ./tools/compiler_unittest.py
Test: ./tools/parser_unittest.py

Change-Id: Ieae168c573116314bcdd7e862448c8ee298b05d4

The parsing fails on statements like:

kill: 1

since 'kill' is matched as an action.

I added these to tests/seccomp.policy and verified the script
now runs to completion.

Bug: chromium:1024021
Test: ./tools/compiler_unittest.py
Test: ./tools/parser_unittest.py
Test: ./tools/compile_seccomp_policy.py \
      test/seccomp.policy test/seccomp.bpf

Change-Id: Idd9476f2d3bc4d69dd1f4bbaac4505bff2ce9801
Signed-off-by: Matt Delco <delco@chromium.org>

The --default-action option fails.
This change fixes it so it can work.

Bug: chromium:1024664
Test: ./tools/compiler_unittest.py
      ./tools/parser_unittest.py
      ./tools/compile_seccomp_policy.py --default-action=log \
       test/seccomp.policy test/seccomp.bpf
       Verified file now ends with 0x7ffc instead of 0.
Change-Id: I08082c14aedb9861f2b5f230532f36d7a5c95a77
Signed-off-by: Matt Delco <delco@chromium.org>

This change provides an escape hatch for overriding the @default action
provided in the .policy file.

.policy files should always have restrictive default actions that
terminate the thread/process upon policy violation. But for debugging
purposes it is super convenient to generate a BPF file that just logs
any violations. So the --default-action flag was added to reconcile both
goals.

Bug: chromium:856315
Test: ./tools/compiler_unittest.py
Test: ./tools/parser_unittest.py
Test: ./tools/compile_seccomp_policy.py --default-action=log \
      test/seccomp.policy test/seccomp.bpf && \
      ~/libseccomp/tools/scmp_bpf_disasm < test/seccomp.bpf | grep LOG

Change-Id: Ib29964dfe21faeddeb6a92b827ffe33007e8dc55

This change adds Android.bp file so that the unittests can be built.

Bug: chromium:856315
Test: mmma -j42 external/minijail/tools/ && \
      out/host/linux-x86/nativetest64/minijail_compiler_unittest/minijail_compiler_unittest && \
      out/host/linux-x86/nativetest64/minijail_parser_unittest/minijail_parser_unittest

Change-Id: I9e7865e4b0cab40cddcf24f96eaad87b3cd06675