getrlimit failed (chromium on musl)

getrlimit failed (chromium on musl)

[Alba Pompeo]

Hi.

Running chromium on a musl system spams this message.

getrlimit(RLIMIT_NOFILE) failed

Any idea how to figure out what's wrong?

Thanks.

Re: getrlimit failed (chromium on musl)

[Rich Felker]

On Wed, Jan 18, 2017 at 12:08:55PM -0200, Alba Pompeo wrote:
> Hi.
> 
> Running chromium on a musl system spams this message.
> 
> getrlimit(RLIMIT_NOFILE) failed
> 
> Any idea how to figure out what's wrong?

strace would be the best way to debug this, I think. My guess is that
chrome's seccomp sandbox wrongly blocks one or more syscalls needed in
getrlimit.

Rich

Re: getrlimit failed (chromium on musl)

[Alba Pompeo]

Does it help? http://sprunge.us/iWdT


On Wed, Jan 18, 2017 at 12:18 PM, Rich Felker <dalias@libc.org> wrote:
> On Wed, Jan 18, 2017 at 12:08:55PM -0200, Alba Pompeo wrote:
>> Hi.
>>
>> Running chromium on a musl system spams this message.
>>
>> getrlimit(RLIMIT_NOFILE) failed
>>
>> Any idea how to figure out what's wrong?
>
> strace would be the best way to debug this, I think. My guess is that
> chrome's seccomp sandbox wrongly blocks one or more syscalls needed in
> getrlimit.
>
> Rich

Re: getrlimit failed (chromium on musl)

[Samuel Holland]

On 01/18/17 08:08, Alba Pompeo wrote:
> Hi.
>
> Running chromium on a musl system spams this message.
>
> getrlimit(RLIMIT_NOFILE) failed
>
> Any idea how to figure out what's wrong?

The problem is that the sandbox blocks prlimit64 with EPERM, but musl
only falls back to getrlimit on ENOSYS. The diff below will fix the
error. From the linked bug, the only reason it is blocked in the first
place is ChromeOS, and this change should be fine even there.

--- 
chromium-55.0.2883.75/content/common/sandbox_linux/bpf_renderer_policy_linux.cc.orig
+++ 
chromium-55.0.2883.75/content/common/sandbox_linux/bpf_renderer_policy_linux.cc
@@ -88,7 +88,7 @@ ResultExpr RendererProcessPolicy::EvaluateSyscall(int 
sysno) const {
      case __NR_sched_setscheduler:
        return sandbox::RestrictSchedTarget(GetPolicyPid(), sysno);
      case __NR_prlimit64:
-      return Error(EPERM);  // See crbug.com/160157.
+      return Error(ENOSYS);  // See crbug.com/160157.
      default:
        // Default on the content baseline policy.
        return SandboxBPFBasePolicy::EvaluateSyscall(sysno);

> Thanks.

Regards,
Samuel

Re: getrlimit failed (chromium on musl)

[Rich Felker]

On Wed, Jan 18, 2017 at 01:18:34PM -0200, Alba Pompeo wrote:
> Does it help? http://sprunge.us/iWdT

No because it seems to be tracing only the main process/thread not the
one printing the error. You need the -f option to follow forks/clones.

Rich

> On Wed, Jan 18, 2017 at 12:18 PM, Rich Felker <dalias@libc.org> wrote:
> > On Wed, Jan 18, 2017 at 12:08:55PM -0200, Alba Pompeo wrote:
> >> Hi.
> >>
> >> Running chromium on a musl system spams this message.
> >>
> >> getrlimit(RLIMIT_NOFILE) failed
> >>
> >> Any idea how to figure out what's wrong?
> >
> > strace would be the best way to debug this, I think. My guess is that
> > chrome's seccomp sandbox wrongly blocks one or more syscalls needed in
> > getrlimit.
> >
> > Rich

Re: getrlimit failed (chromium on musl)

[Alba Pompeo]

Ran strace -f.

[pid 13354] prlimit64(0, RLIMIT_NOFILE, NULL, {rlim_cur=1024,
rlim_max=4*1024}) = 0
[pid 13350] clone(child_stack=NULL, flags=CLONE_NEWUSER|SIGCHLD) = -1
EPERM (Operation not permitted)
[pid 13354] clone(child_stack=NULL,
flags=CLONE_NEWPID|CLONE_NEWNET|SIGCHLD) = -1 EPERM (Operation not
permitted)
[pid 13354] writev(2, [{iov_base=" but failed: errno = Operation
n"..., iov_len=45}, {iov_base=NULL, iov_len=0}], 2 but failed: errno =
Operation not permitted

So the patch from Samuel should be a real solution.

Thanks.



On Wed, Jan 18, 2017 at 1:51 PM, Samuel Holland <samuel@sholland.org> wrote:
> On 01/18/17 08:08, Alba Pompeo wrote:
>>
>> Hi.
>>
>> Running chromium on a musl system spams this message.
>>
>> getrlimit(RLIMIT_NOFILE) failed
>>
>> Any idea how to figure out what's wrong?
>
>
> The problem is that the sandbox blocks prlimit64 with EPERM, but musl
> only falls back to getrlimit on ENOSYS. The diff below will fix the
> error. From the linked bug, the only reason it is blocked in the first
> place is ChromeOS, and this change should be fine even there.
>
> ---
> chromium-55.0.2883.75/content/common/sandbox_linux/bpf_renderer_policy_linux.cc.orig
> +++
> chromium-55.0.2883.75/content/common/sandbox_linux/bpf_renderer_policy_linux.cc
> @@ -88,7 +88,7 @@ ResultExpr RendererProcessPolicy::EvaluateSyscall(int
> sysno) const {
>      case __NR_sched_setscheduler:
>        return sandbox::RestrictSchedTarget(GetPolicyPid(), sysno);
>      case __NR_prlimit64:
> -      return Error(EPERM);  // See crbug.com/160157.
> +      return Error(ENOSYS);  // See crbug.com/160157.
>      default:
>        // Default on the content baseline policy.
>        return SandboxBPFBasePolicy::EvaluateSyscall(sysno);
>
>> Thanks.
>
>
> Regards,
> Samuel
>

Re: getrlimit failed (chromium on musl)

[Alba Pompeo]

The patch worked.
Many thanks Samuel.
I hope they fix it upstream too for the future.
Sadly Chromium still needs some patches to compile and work on musl.



On Wed, Jan 18, 2017 at 2:13 PM, Alba Pompeo <albapompeo@gmail.com> wrote:
> Ran strace -f.
>
> [pid 13354] prlimit64(0, RLIMIT_NOFILE, NULL, {rlim_cur=1024,
> rlim_max=4*1024}) = 0
> [pid 13350] clone(child_stack=NULL, flags=CLONE_NEWUSER|SIGCHLD) = -1
> EPERM (Operation not permitted)
> [pid 13354] clone(child_stack=NULL,
> flags=CLONE_NEWPID|CLONE_NEWNET|SIGCHLD) = -1 EPERM (Operation not
> permitted)
> [pid 13354] writev(2, [{iov_base=" but failed: errno = Operation
> n"..., iov_len=45}, {iov_base=NULL, iov_len=0}], 2 but failed: errno =
> Operation not permitted
>
> So the patch from Samuel should be a real solution.
>
> Thanks.
>
>
>
> On Wed, Jan 18, 2017 at 1:51 PM, Samuel Holland <samuel@sholland.org> wrote:
>> On 01/18/17 08:08, Alba Pompeo wrote:
>>>
>>> Hi.
>>>
>>> Running chromium on a musl system spams this message.
>>>
>>> getrlimit(RLIMIT_NOFILE) failed
>>>
>>> Any idea how to figure out what's wrong?
>>
>>
>> The problem is that the sandbox blocks prlimit64 with EPERM, but musl
>> only falls back to getrlimit on ENOSYS. The diff below will fix the
>> error. From the linked bug, the only reason it is blocked in the first
>> place is ChromeOS, and this change should be fine even there.
>>
>> ---
>> chromium-55.0.2883.75/content/common/sandbox_linux/bpf_renderer_policy_linux.cc.orig
>> +++
>> chromium-55.0.2883.75/content/common/sandbox_linux/bpf_renderer_policy_linux.cc
>> @@ -88,7 +88,7 @@ ResultExpr RendererProcessPolicy::EvaluateSyscall(int
>> sysno) const {
>>      case __NR_sched_setscheduler:
>>        return sandbox::RestrictSchedTarget(GetPolicyPid(), sysno);
>>      case __NR_prlimit64:
>> -      return Error(EPERM);  // See crbug.com/160157.
>> +      return Error(ENOSYS);  // See crbug.com/160157.
>>      default:
>>        // Default on the content baseline policy.
>>        return SandboxBPFBasePolicy::EvaluateSyscall(sysno);
>>
>>> Thanks.
>>
>>
>> Regards,
>> Samuel
>>

Re: getrlimit failed (chromium on musl)

[He X]

[-- Attachment #1: Type: text/plain, Size: 3483 bytes --]

After patched,  chromium segfault three times in two days, e.g. when i try
to upload a file in a baiduyun, crash when i click the upload button, and
suddenly crashed twice, when --disable-sandbox, no crashing:
[65422.256448] chromium[12257]: segfault at 3c1 ip 00007f69e30e075c sp
00007ffe5442efc0 error 4 in libc.so[7f69e30b9000+a1000]

strace output(should be this one):
13:52:37.479810 prlimit64(0, RLIMIT_NOFILE, {rlim_cur=4*1024,
rlim_max=4*1024}, NULL) = 0
13:52:37.479835 futex(0x7f98cbc02b6c, FUTEX_WAKE_PRIVATE, 1) = 1
13:52:37.479862 futex(0x7f98cbc02b4c, FUTEX_WAIT_PRIVATE, 4294967295, NULL)
= 0
13:52:37.479961 rt_sigreturn({mask=[]}) = 61
13:52:37.479982 wait4(29341, NULL, 0, NULL) = ? ERESTARTSYS (To be
restarted if SA_RESTART is set)
13:52:37.851264 wait4(29341, NULL, 0, NULL) = ? ERESTARTSYS (To be
restarted if SA_RESTART is set)
13:52:42.127096 wait4(29341, NULL, 0, NULL) = ? ERESTARTSYS (To be
restarted if SA_RESTART is set)
13:53:23.970709 wait4(29341,  <unfinished ...>) = ?
13:53:30.693847 +++ killed by SIGSEGV +++

This patch is a bit dangerous, though it indeed solved the problem, i think
EPERM is needed. Modifying musl is a better way, but is that correct?


2017-01-27 8:41 GMT+08:00 Alba Pompeo <albapompeo@gmail.com>:

> The patch worked.
> Many thanks Samuel.
> I hope they fix it upstream too for the future.
> Sadly Chromium still needs some patches to compile and work on musl.
>
>
>
> On Wed, Jan 18, 2017 at 2:13 PM, Alba Pompeo <albapompeo@gmail.com> wrote:
> > Ran strace -f.
> >
> > [pid 13354] prlimit64(0, RLIMIT_NOFILE, NULL, {rlim_cur=1024,
> > rlim_max=4*1024}) = 0
> > [pid 13350] clone(child_stack=NULL, flags=CLONE_NEWUSER|SIGCHLD) = -1
> > EPERM (Operation not permitted)
> > [pid 13354] clone(child_stack=NULL,
> > flags=CLONE_NEWPID|CLONE_NEWNET|SIGCHLD) = -1 EPERM (Operation not
> > permitted)
> > [pid 13354] writev(2, [{iov_base=" but failed: errno = Operation
> > n"..., iov_len=45}, {iov_base=NULL, iov_len=0}], 2 but failed: errno =
> > Operation not permitted
> >
> > So the patch from Samuel should be a real solution.
> >
> > Thanks.
> >
> >
> >
> > On Wed, Jan 18, 2017 at 1:51 PM, Samuel Holland <samuel@sholland.org>
> wrote:
> >> On 01/18/17 08:08, Alba Pompeo wrote:
> >>>
> >>> Hi.
> >>>
> >>> Running chromium on a musl system spams this message.
> >>>
> >>> getrlimit(RLIMIT_NOFILE) failed
> >>>
> >>> Any idea how to figure out what's wrong?
> >>
> >>
> >> The problem is that the sandbox blocks prlimit64 with EPERM, but musl
> >> only falls back to getrlimit on ENOSYS. The diff below will fix the
> >> error. From the linked bug, the only reason it is blocked in the first
> >> place is ChromeOS, and this change should be fine even there.
> >>
> >> ---
> >> chromium-55.0.2883.75/content/common/sandbox_linux/bpf_
> renderer_policy_linux.cc.orig
> >> +++
> >> chromium-55.0.2883.75/content/common/sandbox_linux/bpf_
> renderer_policy_linux.cc
> >> @@ -88,7 +88,7 @@ ResultExpr RendererProcessPolicy::EvaluateSyscall(int
> >> sysno) const {
> >>      case __NR_sched_setscheduler:
> >>        return sandbox::RestrictSchedTarget(GetPolicyPid(), sysno);
> >>      case __NR_prlimit64:
> >> -      return Error(EPERM);  // See crbug.com/160157.
> >> +      return Error(ENOSYS);  // See crbug.com/160157.
> >>      default:
> >>        // Default on the content baseline policy.
> >>        return SandboxBPFBasePolicy::EvaluateSyscall(sysno);
> >>
> >>> Thanks.
> >>
> >>
> >> Regards,
> >> Samuel
> >>
>

[-- Attachment #2: Type: text/html, Size: 4780 bytes --]

Re: getrlimit failed (chromium on musl)

[Szabolcs Nagy]

* He X <xw897002528@gmail.com> [2017-01-28 14:00:59 +0800]:
> After patched,  chromium segfault three times in two days, e.g. when i try
> to upload a file in a baiduyun, crash when i click the upload button, and
> suddenly crashed twice, when --disable-sandbox, no crashing:
> [65422.256448] chromium[12257]: segfault at 3c1 ip 00007f69e30e075c sp
> 00007ffe5442efc0 error 4 in libc.so[7f69e30b9000+a1000]
> 

can you provide your libc.so binary?

or at least objdump around address
0x00007f69e30e075c - 0x7f69e30b9000 = 0x2775c

objdump -rdw libc.so |grep -C 100 '2775c:'

make the context (-C) large enough so we see the function
entry, a proper backtrace would be useful too (e.g.
looking at the coredump from gdb).

> This patch is a bit dangerous, though it indeed solved the problem, i think
> EPERM is needed. Modifying musl is a better way, but is that correct?

disabling syscalls with EPERM is a chrome bug,
but this issue seems independent.

Re: getrlimit failed (chromium on musl)

[Samuel Holland]

Hello,

On 01/28/17 00:00, He X wrote:
> After patched,  chromium segfault three times in two days, e.g. when
> i try to upload a file in a baiduyun, crash when i click the upload
> button, and suddenly crashed twice, when --disable-sandbox, no
> crashing: [65422.256448] chromium[12257]: segfault at 3c1 ip
> 00007f69e30e075c sp 00007ffe5442efc0 error 4 in
> libc.so[7f69e30b9000+a1000]

I have had zero crashes with chromium and this patch (over more than a
month of use).

> strace output(should be this one):
> 13:52:37.479810 prlimit64(0, RLIMIT_NOFILE, {rlim_cur=4*1024,
> rlim_max=4*1024}, NULL) = 0
> 13:52:37.479835 futex(0x7f98cbc02b6c, FUTEX_WAKE_PRIVATE, 1) = 1
> 13:52:37.479862 futex(0x7f98cbc02b4c, FUTEX_WAIT_PRIVATE, 4294967295,
> NULL) = 0
> 13:52:37.479961 rt_sigreturn({mask=[]}) = 61
> 13:52:37.479982 wait4(29341, NULL, 0, NULL) = ? ERESTARTSYS (To be
> restarted if SA_RESTART is set)
> 13:52:37.851264 wait4(29341, NULL, 0, NULL) = ? ERESTARTSYS (To be
> restarted if SA_RESTART is set)
> 13:52:42.127096 wait4(29341, NULL, 0, NULL) = ? ERESTARTSYS (To be
> restarted if SA_RESTART is set)
> 13:53:23.970709 wait4(29341,  <unfinished ...>) = ?
> 13:53:30.693847 +++ killed by SIGSEGV +++

Given the 53 seconds between the prlimit64 call and the crash, I doubt
they are related.

Regards,
Samuel

Re: getrlimit failed (chromium on musl)

[Rich Felker]

On Sat, Jan 28, 2017 at 01:45:25PM -0600, Samuel Holland wrote:
> Hello,
> 
> On 01/28/17 00:00, He X wrote:
> >After patched,  chromium segfault three times in two days, e.g. when
> >i try to upload a file in a baiduyun, crash when i click the upload
> >button, and suddenly crashed twice, when --disable-sandbox, no
> >crashing: [65422.256448] chromium[12257]: segfault at 3c1 ip
> >00007f69e30e075c sp 00007ffe5442efc0 error 4 in
> >libc.so[7f69e30b9000+a1000]
> 
> I have had zero crashes with chromium and this patch (over more than a
> month of use).
> 
> >strace output(should be this one):
> >13:52:37.479810 prlimit64(0, RLIMIT_NOFILE, {rlim_cur=4*1024,
> >rlim_max=4*1024}, NULL) = 0
> >13:52:37.479835 futex(0x7f98cbc02b6c, FUTEX_WAKE_PRIVATE, 1) = 1
> >13:52:37.479862 futex(0x7f98cbc02b4c, FUTEX_WAIT_PRIVATE, 4294967295,
> >NULL) = 0
> >13:52:37.479961 rt_sigreturn({mask=[]}) = 61
> >13:52:37.479982 wait4(29341, NULL, 0, NULL) = ? ERESTARTSYS (To be
> >restarted if SA_RESTART is set)
> >13:52:37.851264 wait4(29341, NULL, 0, NULL) = ? ERESTARTSYS (To be
> >restarted if SA_RESTART is set)
> >13:52:42.127096 wait4(29341, NULL, 0, NULL) = ? ERESTARTSYS (To be
> >restarted if SA_RESTART is set)
> >13:53:23.970709 wait4(29341,  <unfinished ...>) = ?
> >13:53:30.693847 +++ killed by SIGSEGV +++
> 
> Given the 53 seconds between the prlimit64 call and the crash, I doubt
> they are related.

Agreed. But there does seem to be something else causing musl-linked
chromium to crash [more often] when sandbox is enabled. I suspect
there's something else they're doing wrong with seccomp that's
breaking it. This strace seems to be done without -f, making it mostly
useless.

Rich

Re: getrlimit failed (chromium on musl)

[He X]

[-- Attachment #1: Type: text/plain, Size: 1947 bytes --]

guys, i cleared, this is another bug about intl, check my another mail:
http://www.openwall.com/lists/musl/2017/01/29/1

2017-01-29 4:59 GMT+08:00 Rich Felker <dalias@libc.org>:

> On Sat, Jan 28, 2017 at 01:45:25PM -0600, Samuel Holland wrote:
> > Hello,
> >
> > On 01/28/17 00:00, He X wrote:
> > >After patched,  chromium segfault three times in two days, e.g. when
> > >i try to upload a file in a baiduyun, crash when i click the upload
> > >button, and suddenly crashed twice, when --disable-sandbox, no
> > >crashing: [65422.256448] chromium[12257]: segfault at 3c1 ip
> > >00007f69e30e075c sp 00007ffe5442efc0 error 4 in
> > >libc.so[7f69e30b9000+a1000]
> >
> > I have had zero crashes with chromium and this patch (over more than a
> > month of use).
> >
> > >strace output(should be this one):
> > >13:52:37.479810 prlimit64(0, RLIMIT_NOFILE, {rlim_cur=4*1024,
> > >rlim_max=4*1024}, NULL) = 0
> > >13:52:37.479835 futex(0x7f98cbc02b6c, FUTEX_WAKE_PRIVATE, 1) = 1
> > >13:52:37.479862 futex(0x7f98cbc02b4c, FUTEX_WAIT_PRIVATE, 4294967295,
> > >NULL) = 0
> > >13:52:37.479961 rt_sigreturn({mask=[]}) = 61
> > >13:52:37.479982 wait4(29341, NULL, 0, NULL) = ? ERESTARTSYS (To be
> > >restarted if SA_RESTART is set)
> > >13:52:37.851264 wait4(29341, NULL, 0, NULL) = ? ERESTARTSYS (To be
> > >restarted if SA_RESTART is set)
> > >13:52:42.127096 wait4(29341, NULL, 0, NULL) = ? ERESTARTSYS (To be
> > >restarted if SA_RESTART is set)
> > >13:53:23.970709 wait4(29341,  <unfinished ...>) = ?
> > >13:53:30.693847 +++ killed by SIGSEGV +++
> >
> > Given the 53 seconds between the prlimit64 call and the crash, I doubt
> > they are related.
>
> Agreed. But there does seem to be something else causing musl-linked
> chromium to crash [more often] when sandbox is enabled. I suspect
> there's something else they're doing wrong with seccomp that's
> breaking it. This strace seems to be done without -f, making it mostly
> useless.
>
> Rich
>

[-- Attachment #2: Type: text/html, Size: 2701 bytes --]

Re: getrlimit failed (chromium on musl)

[Samuel Holland]

Hello,

On 01/26/17 18:41, Alba Pompeo wrote:
> The patch worked.
> Many thanks Samuel.
> I hope they fix it upstream too for the future.
> Sadly Chromium still needs some patches to compile and work on musl.

Forward-porting my patches to chromium 56, I see that this has already 
been fixed upstream:
https://bugs.chromium.org/p/chromium/issues/detail?id=662450

Regards,
Samuel