1611565 - Build failure with musl libc (error: no member named '_sifields' in 'siginfo_t')

Status: RESOLVED FIXED

(Core :: Security: Process Sandboxing, defect, P5)

Description

[mforney]

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

Steps to reproduce:

Attempt to build firefox with musl libc

Actual results:

The build failed:

../../sandbox/linux/seccomp-bpf/trap.cc:171:26: error: no member named '_sifields' in 'siginfo_t'; did you mean '__si_fields'?

This is because _sifields is a glibc-internal field in siginfo_t, not a public interface. musl's corresponding field is called __si_fields.

Expected results:

The build should have succeeded.

The intent of the code in question is to access three fields in siginfo_t. These were added in glibc 2.17, and are named si_call_addr, si_syscall, and si_arch. These public members should be used instead, if available.

I also reported this issue to upstream (chromium) in https://bugs.chromium.org/p/chromium/issues/detail?id=1045069, which has already accepted my patch. Cherry-picking that patch will resolve the issue in firefox as well.

Comment 1

[mforney]

Attachment: Bug 1611565 - Cherry-pick upstream patch to use public siginfo_t fields

Upstream patch:
https://chromium.googlesource.com/chromium/src.git/+/6bd491daaf28a8281136931133504c23a18f819f%5E%21/#F0

_sifields is a glibc-internal field, and is not available on musl
libc. Instead, use the public-facing fields si_call_addr, si_syscall,
and si_arch, if they are available.

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3ec8c96f4d53
Cherry-pick upstream patch to use public siginfo_t fields r=gcp

Comment 3

[Gian-Carlo Pascutto [:gcp]]

Will need to update sandbox/chromium-shim/patches/with_update as well so this doesn't get lost if we update to a chromium snapshot from before that got added upstream.

Comment 4

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/3ec8c96f4d53

Comment 5

[Gian-Carlo Pascutto [:gcp]]

Follow up in Bug 1613921.