mbox series

[bug#77653,0/4] Add WASM toolchain, wasi-libc, and browser WASM sandbox support

Message ID 20250408195720.2021-1-ian@retrospec.tv
Headers
Series Add WASM toolchain, wasi-libc, and browser WASM sandbox support |

Message

Ian Eure April 8, 2025, 7:57 p.m. UTC 
  This patch series adds a Clang variant which can emit WASM; runtime support for WASM binaries; wasi-libc, a libc implementation for WASM programs; and a `wasm-sandboxed' function which creates a WASM sandboxed variant of Firefox-based browsers.

In Firefox and Firefox-derived browsers, WASM sandboxing is a security technique which compiles C/C++ libraries into WASM, then translates the WASM back into native code.  This allows leveraging the WASM security model to isolate the library from the browser, without needing a separate process to contain it.  Please see this blog post for more info: https://hacks.mozilla.org/2020/02/securing-firefox-with-webassembly/

The code is extracted from my personal channel[1], which in turn is based on work done for nonguix's Firefox package.  I've been daliy-driving personal variants of LibreWolf since before the package was accepted into Guix, and nonguix's Firefox has been using it even longer.

[1]: https://codeberg.org/ieure/atomized-guix/src/branch/main/atomized/packages/wasm.scm
[2]: https://gitlab.com/nonguix/nonguix/-/blob/master/nongnu/packages/wasm.scm?ref_type=heads

Ian Eure (4):
  gnu: Add wasi-libc.
  gnu: Add wasm32-wasi-clang-runtime.
  gnu: Add wasm32-wasi-clang.
  gnu: Add wasm-sandboxed.

 gnu/packages/gnuzilla.scm |  30 +++++++++
 gnu/packages/wasm.scm     | 135 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 165 insertions(+)
 create mode 100644 gnu/packages/wasm.scm

Comments

Ian Eure April 9, 2025, 10:08 p.m. UTC | #1 
Z572 <z572@z572.online> writes:

> Ian Eure <ian@retrospec.tv> writes:
>
>> +    (native-inputs
>> +     (list clang-16
>> +           wasi-libc))
>
> Should wasi-libc be placed in inputs?

Good question.  I think it can be, since it’s WASM bytecode.  My 
only concern is that it might contain an arch-specific store 
reference, but I dug around in the output and didn’t see anything. 
So I think this should be fine, but I’ll do a little testing.

All your other suggestions look good, I’ll give this a whirl and 
send a v2.

Thanks,
  -- Ian
Maxim Cournoyer April 25, 2025, 1:02 p.m. UTC | #2 
Hi Ian,

Ian Eure <ian@retrospec.tv> writes:

> This patch series adds a Clang variant which can emit WASM; runtime support for WASM binaries; wasi-libc, a libc implementation for WASM programs; and a `wasm-sandboxed' function which creates a WASM sandboxed variant of Firefox-based browsers.
>
> In Firefox and Firefox-derived browsers, WASM sandboxing is a security technique which compiles C/C++ libraries into WASM, then translates the WASM back into native code.  This allows leveraging the WASM security model to isolate the library from the browser, without needing a separate process to contain it.  Please see this blog post for more info: https://hacks.mozilla.org/2020/02/securing-firefox-with-webassembly/
>
> The code is extracted from my personal channel[1], which in turn is based on work done for nonguix's Firefox package.  I've been daliy-driving personal variants of LibreWolf since before the package was accepted into Guix, and nonguix's Firefox has been using it even longer.
>
> [1]: https://codeberg.org/ieure/atomized-guix/src/branch/main/atomized/packages/wasm.scm
> [2]: https://gitlab.com/nonguix/nonguix/-/blob/master/nongnu/packages/wasm.scm?ref_type=heads
>
> Ian Eure (4):
>   gnu: Add wasi-libc.
>   gnu: Add wasm32-wasi-clang-runtime.
>   gnu: Add wasm32-wasi-clang.
>   gnu: Add wasm-sandboxed.

Thanks for picking it up!  Nice series.  I've left a few hopefully
useful comments.  Could you please prepare a v2 taking them into
account?

Thank you!
Ian Eure April 28, 2025, 1:10 a.m. UTC | #3 
Hi Maxim, Z572,

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> Hi Ian,
>
>
> Thanks for picking it up!  Nice series.  I've left a few 
> hopefully
> useful comments.  Could you please prepare a v2 taking them into
> account?

Sorry about the delay on this.  I appreciate the feedback and have 
a v2 in decent shape that incorporates nearly all the feedback 
from the two of you.

Unfortunately, this work is currently blocked due to unclear 
licensing of the WASI specification, which wasi-libc includes a 
copy of via Git submodule.  There’s an issue open for this, but it 
was opened in 2019 and still isn’t resolved.  Hopefully recent 
pings on the issue will get it some renewed attention, but I’m not 
feeling confident about moving this forward at the moment.

I’ll go ahead and send a v2 patch anyway, but it’s unpushable 
until the WASI situation is resolved.

Thanks,
  -- Ian

[1]: https://github.com/WebAssembly/WASI/issues/182
Maxim Cournoyer April 29, 2025, 1:24 a.m. UTC | #4 
Hi,

Ian Eure <ian@retrospec.tv> writes:

> Hi Maxim, Z572,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
>
>> Hi Ian,
>>
>>
>> Thanks for picking it up!  Nice series.  I've left a few hopefully
>> useful comments.  Could you please prepare a v2 taking them into
>> account?
>
> Sorry about the delay on this.  I appreciate the feedback and have a
> v2 in decent shape that incorporates nearly all the feedback from the
> two of you.
>
> Unfortunately, this work is currently blocked due to unclear licensing
> of the WASI specification, which wasi-libc includes a copy of via Git

WASI specification sounds like non-functional data more than code,
right?  If that's correct, then it shouldn't be an impediment to having
this merged in GNU Guix (though of course having this licensing issue
fixed upstream would be nice), as the GNU FSDG has an exception for
non-functional data, as long as is freely distributable.  See the
'Non-functional Data' paragraph, specifically:

> It can be included in a free system distribution as long as its
> license gives you permission to copy and redistribute, both for
> commercial and non-commercial purposes.
Ian Eure May 2, 2025, 10:48 p.m. UTC | #5 
Hi Maxim,

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> Hi,
>
> Ian Eure <ian@retrospec.tv> writes:
>
>> Hi Maxim, Z572,
>>
>> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
>>
>>> Hi Ian,
>>>
>>>
>>> Thanks for picking it up!  Nice series.  I've left a few 
>>> hopefully
>>> useful comments.  Could you please prepare a v2 taking them 
>>> into
>>> account?
>>
>> Sorry about the delay on this.  I appreciate the feedback and 
>> have a
>> v2 in decent shape that incorporates nearly all the feedback 
>> from the
>> two of you.
>>
>> Unfortunately, this work is currently blocked due to unclear 
>> licensing
>> of the WASI specification, which wasi-libc includes a copy of 
>> via Git
>
> WASI specification sounds like non-functional data more than 
> code,
> right?  If that's correct, then it shouldn't be an impediment to 
> having
> this merged in GNU Guix (though of course having this licensing 
> issue
> fixed upstream would be nice), as the GNU FSDG has an exception 
> for
> non-functional data, as long as is freely distributable.  See 
> the
> 'Non-functional Data' paragraph, specifically:

The stuff in the WASI repo is used to generate api.h in 
wasi-libc[1].  Since it’s already in there, maybe we don’t need to 
package the WASI repo or fetch the submodule at all.


>> It can be included in a free system distribution as long as its
>> license gives you permission to copy and redistribute, both for
>> commercial and non-commercial purposes.

The issue is that it’s unclear whether it has a user license at 
all.  The only licensing information in the project is two 
sentences saying[2]:

    Copyright © 2019-2023 the Contributors to the WASI 
    Specification,
    published by the WebAssembly Community Group under the W3C
    Community Contributor License Agreement (CLA). A 
    human-readable
    summary is available.

The CLA itself covers contributions into the project.  While 
section 12.8 has some language about the terms it can be provided 
under, a specific license laying out those terms is not provided. 
It also appears to cover the Specification, which is the final 
work product, which hasn’t been published yet.  Section 5 also 
allows contributions to be withdrawn up to 45 days after being 
contributed, which makes it incompatible with the GPL’s "Basic 
Permissions," which states:

    All rights granted under this License are granted for the term 
    of
    copyright on the Program, and are irrevocable provided the 
    stated
    conditions are met.

I’ll see if wasi-libc builds without the WASI module and go from 
there.

Thanks,

  -- Ian


[1]: 
https://github.com/WebAssembly/wasi-libc/blob/main/libc-bottom-half/headers/public/wasi/api.h
[2]: https://github.com/WebAssembly/WASI/blob/main/LICENSE.md