Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 737808 - www-client/chromium: seccomp sandbox breaks on i686 with recent glibc-2.31 upgrade
Summary: www-client/chromium: seccomp sandbox breaks on i686 with recent glibc-2.31 up...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Chromium Project
URL: https://crbug.com/1183928
Whiteboard:
Keywords:
Depends on:
Blocks: glibc-2.31 glibc-2.32
  Show dependency tree
 
Reported: 2020-08-18 08:50 UTC by David Flogeras
Modified: 2021-11-01 16:03 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Flogeras 2020-08-18 08:50:17 UTC
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
Comment 1 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2020-08-18 08:52:58 UTC
Any syslog/console output would help us out too. Thanks.
Comment 2 Stephan Hartmann (RETIRED) gentoo-dev 2020-08-18 09:09:25 UTC
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).
Comment 3 David Flogeras 2020-08-19 09:16:30 UTC
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.
Comment 4 Mike Gilbert gentoo-dev 2020-08-19 14:01:19 UTC
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.
Comment 5 Henry Kohli 2020-09-23 10:23:16 UTC
i have this exact same problem when running qutebrowser with qtwebengine on 32bit gentoo
Comment 6 Andreas K. Hüttel archtester gentoo-dev 2020-10-09 21:41:13 UTC
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...
Comment 7 SpanKY gentoo-dev 2021-11-01 16:03:13 UTC
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.