1575997 - RLBox - Require info adding binary resources to the source tree

Status: RESOLVED FIXED

(Core :: General, task, P3)

Description

[Shravan Narayan]

Project description - See Bug 1554268

RLBox modifies Firefox to use wasm sandboxed versions of third party or otherwise risky libraries. The first target is libGraphite (font library), which is used in libThebes.

For testing purposes, I am locally checking in a prebuilt sandboxed libGraphite ELF and testing on try.

Hoping for some info on the best way I can

1. Add a binary resource and copy it from the source tree to the binary output as part of the build
2. Locate the correct path of the resource, from C++ code inside Firefox...

If there is an example for how this is done with maybe some of the UI graphics etc, that would be great!

Comment 1

[Nathan Froyd [:froydnj]]

The easiest way to do the first part is to look at what's done for LLVM_SYMBOLIZER:

https://searchfox.org/mozilla-central/search?q=LLVM_SYMBOLIZER&path=

I think you can get away with not having the MOZ_PATH_PROG(...) stuff, and just having AC_SUBST(PRECOMPILED_LIBGRAPHITE) somewhere, along with export PRECOMPILED_LIBGRAPHITE=.... in the appropriate mozconfig.

As for the second part, assuming you follow what's done in browser/installer/{Makefile.in,package-manifest.in}, the library will just be in the main firefox directory, which I think you already understand how to load files out of?

Comment 2

[Shravan Narayan]

the library will just be in the main firefox directory, which I think you already understand how to load files out of?

I have so far been using absolute and relative paths for loading which is a bit brittle... If there is an API that returns the path to the Firefox directory, that would definitely simplify things :)

Comment 3

[Shravan Narayan]

Sorry, I don't have a lot of familiarity with autoconf, so I'm having some trouble with this... Attached a diff of what I have so far based on your suggestions... However, this doesn't seem to work...

(I have used an empty text file in place of the ELF binary to keep the diff small)

diff --git a/browser/installer/package-manifest.in b/browser/installer/package-manifest.in
index 387010bdbba5..19c4f6e15e67 100644
--- a/browser/installer/package-manifest.in
+++ b/browser/installer/package-manifest.in
@@ -434,6 +434,10 @@ bin/libfreebl_64int_3.so
 #endif
 #endif
 
+#ifdef SANDBOXED_COMPILED_LIBGRAPHITE
+@BINPATH@/@SANDBOXED_COMPILED_LIBGRAPHITE@
+#endif
+
 #ifdef MOZ_CLANG_RT_ASAN_LIB
 @BINPATH@/@MOZ_CLANG_RT_ASAN_LIB@
 #endif
diff --git a/build/autoconf/sanitize.m4 b/build/autoconf/sanitize.m4
index 11fc6caebbd3..0bc68b45feee 100644
--- a/build/autoconf/sanitize.m4
+++ b/build/autoconf/sanitize.m4
@@ -126,6 +126,8 @@ fi
 # The LLVM symbolizer is used by all sanitizers
 AC_SUBST(LLVM_SYMBOLIZER)
 
+AC_SUBST(SANDBOXED_COMPILED_LIBGRAPHITE)
+
 dnl ========================================================
 dnl = Test for whether the compiler is compatible with the
 dnl = given sanitize options.
diff --git a/libgraphite_wasm.so b/libgraphite_wasm.so
new file mode 100644
index 000000000000..e69de29bb2d1
diff --git a/mozconfig b/mozconfig
new file mode 100644
index 000000000000..e9fbac30c142
--- /dev/null
+++ b/mozconfig
@@ -0,0 +1,10 @@
+ac_add_options --enable-application=browser
+mk_add_options MOZ_MAKE_FLAGS="-j8"
+
+export SANDBOXED_COMPILED_LIBGRAPHITE="libgraphite_wasm.so"
+
+ac_add_options --enable-debug
+#ac_add_options --enable-optimize
+ac_add_options --enable-warnings-as-errors
+ac_add_options --enable-clang-plugin
+#ac_add_options --enable-sandboxed-graphite
\ No newline at end of file

Comment 4

[Nathan Froyd [:froydnj]]

(In reply to Shravan Narayan from comment #3)

Sorry, I don't have a lot of familiarity with autoconf, so I'm having some trouble with this... Attached a diff of what I have so far based on your suggestions... However, this doesn't seem to work...

diff --git a/browser/installer/package-manifest.in b/browser/installer/package-manifest.in
index 387010bdbba5..19c4f6e15e67 100644
--- a/browser/installer/package-manifest.in
+++ b/browser/installer/package-manifest.in
@@ -434,6 +434,10 @@ bin/libfreebl_64int_3.so
#endif
#endif

+#ifdef SANDBOXED_COMPILED_LIBGRAPHITE
+@BINPATH@/@SANDBOXED_COMPILED_LIBGRAPHITE@
+#endif
+

This part is fine.

diff --git a/build/autoconf/sanitize.m4 b/build/autoconf/sanitize.m4
index 11fc6caebbd3..0bc68b45feee 100644
--- a/build/autoconf/sanitize.m4
+++ b/build/autoconf/sanitize.m4
@@ -126,6 +126,8 @@ fi

The LLVM symbolizer is used by all sanitizers

AC_SUBST(LLVM_SYMBOLIZER)

+AC_SUBST(SANDBOXED_COMPILED_LIBGRAPHITE)

We'd normally put the machinery for this in toolkit/moz.configure, but this is fine for hacking.

diff --git a/libgraphite_wasm.so b/libgraphite_wasm.so
new file mode 100644
index 000000000000..e69de29bb2d1
diff --git a/mozconfig b/mozconfig
new file mode 100644
index 000000000000..e9fbac30c142
--- /dev/null
+++ b/mozconfig
@@ -0,0 +1,10 @@
+ac_add_options --enable-application=browser
+mk_add_options MOZ_MAKE_FLAGS="-j8"
+
+export SANDBOXED_COMPILED_LIBGRAPHITE="libgraphite_wasm.so"

As noted, this should go in build/mozconfig.common.override, and be "$topsrcdir/libgraphite_wasm.so".

One missing piece is to put this in a place where package-manifest.in can find it, similar to:

https://searchfox.org/mozilla-central/source/build/moz.build#55-56

So you'd write:

if CONFIG['SANDBOXED_COMPILED_LIBGRAPHITE']:
  FINAL_TARGET_FILES += ['/' + CONFIG['SANDBOXED_COMPILED_LIBGRAPHITE']]

The other missing piece is defining the appropriate macro for package-manifest.in, similar to:

https://searchfox.org/mozilla-central/source/browser/installer/Makefile.in#150-152

Ideally it should be clear how to replicate that for SANDBOXED_COMPILED_LIBGRAPHITE.

You should be able to get the path to the Firefox executable directory via:

https://searchfox.org/mozilla-central/source/xpcom/build/BinaryPath.h#254

Does that clear things up?

Comment 5

[Shravan Narayan]

I believe I understand it now... I will try it out and keep this thread updated. Thanks a bunch for spelling this out... autoconf is definitely one of the harder parts of the codebase to figure out :)