Thanks a bunch for the info! So from your comments, I believe one option is that we should perform an early load of the library, prior to sandbox creation. I think this makes sense, and I will investigate this option. I think the above solution makes sense for the current example of sandboxing the font library. In the future when we move to sandboxing rarely used libraries, I think we would not necessarily want to preload sandboxed libraries. For instance, if we sandbox a library that handles a rarely used image format, we want to defer loading until we hit a page that has an image in this format. > On Linux ... content processes can continue to load libraries > On Mac ... libraries from within the main Firefox.app should still be able to be loaded > On Windows, our best approach... is to preload the library From your comments, above, it seems that deferred loading is possible at least on Linux/Mac. So it sounds like `dlopen` would work. **Question** - Does this mean that syscalls like `open` would also continue to work? > On Windows, restriction ... in the Content Process ... in the future **Question** - Once this is enabled, would a LoadLibrary of a non pre-loaded dll be permitted, at least for dlls in the Firefox binary folder? We can definitely punt on this question if the details of the Windows content sandbox are unclear at this time. > Have you encountered this problem on specific platforms? Sorry, I should have mentioned this earlier. The initial plan for wasm sandboxing is Linux 64. So my testing and this bug description is for Linux 64. However the goal is to keep this general, so that we can expand to other platforms. Mac 64 is a relatively easy next step in the roadmap. Win64 is a longer term goal as Lucet does not currently support it. > Yes, there is a way to do this if the libraries can't be delivered in the .app bundle. If you could provide some more details about where you're loading from now and what failures you're seeing, that would help. Ok, this makes sense now. The current prototype is a proof of concept and is a bit hacky - it would load from a path outside the Firefox binary folder/app bundle. After cleanup, I am hoping to set it up so that the load is from the same folder (app bundle?) as libxul. From your comments, it seems that this deferred library load would be permitted? *Caveat* - I am not very familiar with the app bundles on Mac, so I apologize if the above description is flawed. **Follow up investigation from my side** - The code that dynamically loads the wasm sandbox ([RLBox_Lucet](https://github.com/PLSysSec/rlbox_lucet_sandbox/) + [a customized Lucet compiler runtime](https://github.com/PLSysSec/lucet_sandbox_compiler/)), uses 2 file related system calls prior to loading 1) dlopen/LoadLibrary 2) File open, read, close syscalls - to parse some additional metadata from the shared library file that is not included in the dlopen above I will check to see if we can eliminate #2 above, in case that helps simplify working with the content sandbox.
Bug 1575985 Comment 4 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Thanks a bunch for the info! So from your comments, I believe one option is that we should perform an early load of the library, prior to sandbox creation. I think this makes sense, and I will investigate this option. I think the above solution makes sense for the current example of sandboxing the font library. In the future when we move to sandboxing rarely used libraries, I think we would not necessarily want to preload sandboxed libraries. For instance, if we sandbox a library that handles a rarely used image format, we want to defer loading until we hit a page that has an image in this format. > On Linux ... content processes can continue to load libraries > On Mac ... libraries from within the main Firefox.app should still be able to be loaded > On Windows, our best approach... is to preload the library From your comments, above, it seems that deferred loading is possible at least on Linux/Mac. So it sounds like `dlopen` would work. **Question(Linux/Mac)** - Does this mean that syscalls like `open` would also continue to work? > On Windows, restriction ... in the Content Process ... in the future **Question(Win)** - Once this is enabled, would a LoadLibrary of a non pre-loaded dll be permitted, at least for dlls in the Firefox binary folder? We can definitely punt on this question if the details of the Windows content sandbox are unclear at this time. > Have you encountered this problem on specific platforms? Sorry, I should have mentioned this earlier. The initial plan for wasm sandboxing is Linux 64. So my testing and this bug description is for Linux 64. However the goal is to keep this general, so that we can expand to other platforms. Mac 64 is a relatively easy next step in the roadmap. Win64 is a longer term goal as Lucet does not currently support it. > Yes, there is a way to do this if the libraries can't be delivered in the .app bundle. If you could provide some more details about where you're loading from now and what failures you're seeing, that would help. Ok, this makes sense now. The current prototype is a proof of concept and is a bit hacky - it would load from a path outside the Firefox binary folder/app bundle. After cleanup, I am hoping to set it up so that the load is from the same folder (app bundle?) as libxul. **Question(Mac)** - From your comments, it seems that this deferred library load would be permitted? *Caveat* - I am not very familiar with the app bundles on Mac, so I apologize if the above description is flawed. **Follow up investigation from my side** - The code that dynamically loads the wasm sandbox ([RLBox_Lucet](https://github.com/PLSysSec/rlbox_lucet_sandbox/) + [a customized Lucet compiler runtime](https://github.com/PLSysSec/lucet_sandbox_compiler/)), uses 2 file related system calls prior to loading 1) dlopen/LoadLibrary 2) File open, read, close syscalls - to parse some additional metadata from the shared library file that is not included in the dlopen above I will check to see if we can eliminate #2 above, in case that helps simplify working with the content sandbox.