In a similar vein to https://bugs.gentoo.org/737604 chromium's seccomp filter has not yet learned syscall 403 & 407 (time64 syscalls added to glibc-2.31). This causes it to just display an "Aw snap" message for every page you attempt to load. I found the following linked to an arch32 forum post: https://github.com/OSSystems/meta-browser/issues/357 And applying just this patch works for me: https://raw.githubusercontent.com/OSSystems/meta-browser/805b297fc8efe46240f99b2731596a4377bea190/recipes-browser/chromium/files/0003-Fix-sandbox-Aw-snap-for-syscalls-403-and-407.patch Reproducible: Always
Any syslog/console output would help us out too. Thanks.
I think the patch is wrong, because it is probably incorrect to check syscall presence with "#if defined()". Can you open upstream bug report and see if chromium devs are going to fix this? Another option is to drop x86 keywords completely (upstream does not support 32-bit builds).
From the terminal, I see many of these messages: (note, you can also workaround this with --disable-seccomp-filter-sandbox, but obviously that's not advisable for daily driving) ../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0403 Received signal 11 SEGV_ACCERR 000001c01193 #0 0x0000052cc5af (/usr/lib/chromium-browser/chrome+0x4de35ae) #1 0x0000052053c4 (/usr/lib/chromium-browser/chrome+0x4d1c3c3) #2 0x0000052ccb10 (/usr/lib/chromium-browser/chrome+0x4de3b0f) #3 0x0000052cd1ff (/usr/lib/chromium-browser/chrome+0x4de41fe) #4 0x0000b7efb918 ([vdso]+0x917) #5 0x0000095d27b9 (/usr/lib/chromium-browser/chrome+0x90e97b8) #6 0x0000095dba5a (/usr/lib/chromium-browser/chrome+0x90f2a59) #7 0x0000095dbbff (/usr/lib/chromium-browser/chrome+0x90f2bfe) #8 0x0000b7efb918 ([vdso]+0x917) #9 0x0000b7efb901 ([vdso]+0x900) #10 0x0000b7efb871 ([vdso]+0x870) #11 0x0000b447f529 (/lib/libc-2.31.so+0xbe528) gs: 00000033 fs: 00000000 es: 0000007b ds: 0000007b edi: 0e30b1fc esi: 01c01193 ebp: bfc513f8 esp: bfc513b0 ebx: bfc51440 edx: 01c00000 ecx: 0f9c5b70 eax: 01c01000 trp: 0000000e err: 00000006 ip: 095d27b9 cs: 00000073 efl: 00210206 usp: bfc513b0 ss: 0000007b [end of stack trace] Calling _exit(1). Core file will not be generated. ../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0403 Received signal 11 SEGV_ACCERR 000001c01193 #0 0x0000052cc5af (/usr/lib/chromium-browser/chrome+0x4de35ae) #1 0x0000052053c4 (/usr/lib/chromium-browser/chrome+0x4d1c3c3) #2 0x0000052ccb10 (/usr/lib/chromium-browser/chrome+0x4de3b0f) #3 0x0000052cd1ff (/usr/lib/chromium-browser/chrome+0x4de41fe) #4 0x0000b7efb918 ([vdso]+0x917) #5 0x0000095d27b9 (/usr/lib/chromium-browser/chrome+0x90e97b8) #6 0x0000095dba5a (/usr/lib/chromium-browser/chrome+0x90f2a59) #7 0x0000095dbbff (/usr/lib/chromium-browser/chrome+0x90f2bfe) #8 0x0000b7efb918 ([vdso]+0x917) #9 0x0000b7efb901 ([vdso]+0x900) #10 0x0000b7efb871 ([vdso]+0x870) #11 0x0000b447f529 (/lib/libc-2.31.so+0xbe528) gs: 00000033 fs: 00000000 es: 0000007b ds: 0000007b edi: 0e30b1fc esi: 01c01193 ebp: bfc513f8 esp: bfc513b0 ebx: bfc51440 edx: 01c00000 ecx: 0f9c5b70 eax: 01c01000 trp: 0000000e err: 00000006 ip: 095d27b9 cs: 00000073 efl: 00210206 usp: bfc513b0 ss: 0000007b [end of stack trace] Calling _exit(1). Core file will not be generated.
Checking for syscall numbers with #if defined() seems ok to me. Projects like systemd do this for compatibility with old versions of the linux headers. https://github.com/systemd/systemd/blob/v246/src/basic/missing_syscall.h I agree that this patch should be sent upstream.
i have this exact same problem when running qutebrowser with qtwebengine on 32bit gentoo
There's not much that toolchain can do here. This is an architectural limitation of seccomp filtering - to be safe, an "unknown" syscall needs to be a "forbidden" one...
these reports really need to be directed at crbug.com/new. and indeed, it's been filed & fixed there since: https://crbug.com/1183928 (In reply to Mike Gilbert from comment #4) > Checking for syscall numbers with #if defined() seems ok to me. it isn't needed in Chromium because it provides its own fallbacks. that's the point of sandbox/linux/system_headers/$ARCH_linux_syscalls.h.