1754959 - --enable-sandbox support for more cpu architectures

Status: NEW

(Core :: Security: Process Sandboxing, enhancement, P3)

Description

[Joonas Niilola]

Attachment: firefox-97.0-power9-build-1000.log

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0

Steps to reproduce:

Tried to enable sandboxing via --enable-sandbox on a power9, ppc64 system.

Actual results:

The builds errors out with error: "unrecognized architecture". Please see the attachment for more information. I can also see errors like #error Missing stat syscall include. but that must be due to how the Firefox build system does includes, when an arch is unsupported.

Expected results:

I'm not sure. Why is the sandbox support enabled only for pre-defined arches? For Firefox-97.0 I can see:

        # Linux sandbox is only available on x86{,_64} and arm{,64}.
        return target.cpu in ("x86", "x86_64", "arm", "aarch64")

but what about other arches, like ppc64? What is the reason sandbox can't be enabled for them?

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Security: Process Sandboxing' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Dan Horák]

If I see right, then it's the Chromium sandbox bits that are bundled in FF sources, that have limited multiarch support ...

Comment 3

[Dan Horák]

see https://github.com/shawnanastasio/chromium_power/tree/master/sandbox for ppc64le support patches, I don't think they have been merged

Comment 4

[Gian-Carlo Pascutto [:gcp]]

We don't have any developers with PPC64 machines, nor do we have CI support, so this would require someone to get those patches to apply to our copy of the Chromium source, and see if the can get Firefox running (likely various extra work is needed). That'd be enough to merge them into our tree (although I'd be hard to ensure everything stays working with lack of CI coverage).

Comment 5

[Dan Horák]

There are few developers/contributors with ppc64 systems, so when someone finds the time, I believe we could get the ppc64 sandbox in. We are running a simple, but multi-arch, CI for Firefox internally at Red Hat covering ppc64 and s390x with x86_64 and aarch64 as reference. And we talk about more visible/public CI solution as well. So even a long term maintenance should be doable.

Comment 6

[Georgy Yakovlev]

gentoo linux supports firefox on ppc64le and has quite a lot of users using it daily.
also we have fresh sandbox patchset for chromium that works with new glibcs and is based on current chromium source, also we have qtwebengine working on ppc64le

also we have a semi-idle ppc64le machine we could run container on. uptime is quite good. Machine is hosted in OSUOSL.
what's exactly needed for ppc64le CI? Can someone point me to the right direction?
I (on behalf of gentoo ppc64 team) can probably provide a qemu vm or a container for CI. I just need to understand what CI implies, what the load is and how access is set-up.

Comment 7

[Timothy Pearson]

I'd also like to offer free (donated) CI system access via Integricloud [1], if it helps to improve and maintain POWER support for Firefox. Just need to know the CPU / RAM / disk space requirements and we could get something set up right away.

[1] https://integricloud.com/

Comment 8

[Gian-Carlo Pascutto [:gcp]]

We are running a simple, but multi-arch, CI for Firefox internally at Red Hat covering ppc64 and s390x with x86_64 and aarch64 as reference. And we talk about more visible/public CI solution as well. So even a long term maintenance should be doable.

As long as someone would be monitoring that and filing bugs if the PPC/sandboxing support gets broken, that's probably good enough.

So the work would be to port the patches from Chromium over to our copy of the sandboxing code, and then investigating which, if any, parts of the sandboxing policy need modifications on PPC64.

Comment 9

[Gian-Carlo Pascutto [:gcp]]

In terms of hardware needed, for tier-1 support, the smallest platform we support is macOS ARM, for which we have 36 machines. There we abuse the fact that Android also tests the ARM support, and x86 macOS tests a lot of the macOS support, to get away with a much reduced set of tests. ( A core platform like 64-bit Linux can spawn 2000+ machines: https://hg.mozilla.org/ci/ci-configuration/file/tip/worker-pools.yml#l1868)

It makes more sense to treat it as tier-3, have someone external set up a CI that monitors mozilla-central, and run builds/tests off of that, then file bugs if something is broken. This seems to work well enough for a lot of Linux/BSD like platforms, i.e. you're piggy-backing off of the similarities to x86 64-bit Linux, and I think we have no PPC-JIT, so that can't break to begin with?