| Message ID | 20221125143946.27717-1-mhartmay@linux.ibm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | virtiofsd: Add `sigreturn` to the seccomp whitelist | expand |
On Fri, Nov 25, 2022 at 3:40 PM Marc Hartmayer <mhartmay@linux.ibm.com> wrote: > > The virtiofsd currently crashes on s390x. This is because of a > `sigreturn` system call. See audit log below: > > type=SECCOMP msg=audit(1669382477.611:459): auid=4294967295 uid=0 gid=0 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 pid=6649 comm="virtiofsd" exe="/usr/libexec/virtiofsd" sig=31 arch=80000016 syscall=119 compat=0 ip=0x3fff15f748a code=0x80000000AUID="unset" UID="root" GID="root" ARCH=s390x SYSCALL=sigreturn > > Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com> > --- > tools/virtiofsd/passthrough_seccomp.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/tools/virtiofsd/passthrough_seccomp.c b/tools/virtiofsd/passthrough_seccomp.c > index 888295c073de..0033dab4939e 100644 > --- a/tools/virtiofsd/passthrough_seccomp.c > +++ b/tools/virtiofsd/passthrough_seccomp.c > @@ -110,6 +110,7 @@ static const int syscall_allowlist[] = { > #endif > SCMP_SYS(set_robust_list), > SCMP_SYS(setxattr), > + SCMP_SYS(sigreturn), > SCMP_SYS(symlinkat), > SCMP_SYS(syncfs), > SCMP_SYS(time), /* Rarely needed, except on static builds */ > -- > 2.34.1 > > _______________________________________________ > Virtio-fs mailing list > Virtio-fs@redhat.com > https://listman.redhat.com/mailman/listinfo/virtio-fs > Reviewed-by: German Maglione <gmaglione@redhat.com> Should we add this also in the rust version?, I see we don't have it enabled either.
Thanks, applied to qemu.git/master. Stefan
Am 25.11.22 um 17:32 schrieb German Maglione: > On Fri, Nov 25, 2022 at 3:40 PM Marc Hartmayer <mhartmay@linux.ibm.com> wrote: >> >> The virtiofsd currently crashes on s390x. This is because of a >> `sigreturn` system call. See audit log below: >> >> type=SECCOMP msg=audit(1669382477.611:459): auid=4294967295 uid=0 gid=0 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 pid=6649 comm="virtiofsd" exe="/usr/libexec/virtiofsd" sig=31 arch=80000016 syscall=119 compat=0 ip=0x3fff15f748a code=0x80000000AUID="unset" UID="root" GID="root" ARCH=s390x SYSCALL=sigreturn >> >> Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com> >> --- >> tools/virtiofsd/passthrough_seccomp.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/tools/virtiofsd/passthrough_seccomp.c b/tools/virtiofsd/passthrough_seccomp.c >> index 888295c073de..0033dab4939e 100644 >> --- a/tools/virtiofsd/passthrough_seccomp.c >> +++ b/tools/virtiofsd/passthrough_seccomp.c >> @@ -110,6 +110,7 @@ static const int syscall_allowlist[] = { >> #endif >> SCMP_SYS(set_robust_list), >> SCMP_SYS(setxattr), >> + SCMP_SYS(sigreturn), >> SCMP_SYS(symlinkat), >> SCMP_SYS(syncfs), >> SCMP_SYS(time), /* Rarely needed, except on static builds */ >> -- >> 2.34.1 >> >> _______________________________________________ >> Virtio-fs mailing list >> Virtio-fs@redhat.com >> https://listman.redhat.com/mailman/listinfo/virtio-fs >> > > Reviewed-by: German Maglione <gmaglione@redhat.com> > > Should we add this also in the rust version?, I see we don't have it > enabled either. this is probably a good idea.
German Maglione <gmaglione@redhat.com> writes: > On Fri, Nov 25, 2022 at 3:40 PM Marc Hartmayer <mhartmay@linux.ibm.com> wrote: >> >> The virtiofsd currently crashes on s390x. This is because of a >> `sigreturn` system call. See audit log below: >> >> type=SECCOMP msg=audit(1669382477.611:459): auid=4294967295 uid=0 gid=0 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 pid=6649 comm="virtiofsd" exe="/usr/libexec/virtiofsd" sig=31 arch=80000016 syscall=119 compat=0 ip=0x3fff15f748a code=0x80000000AUID="unset" UID="root" GID="root" ARCH=s390x SYSCALL=sigreturn >> >> Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com> >> --- >> tools/virtiofsd/passthrough_seccomp.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/tools/virtiofsd/passthrough_seccomp.c b/tools/virtiofsd/passthrough_seccomp.c >> index 888295c073de..0033dab4939e 100644 >> --- a/tools/virtiofsd/passthrough_seccomp.c >> +++ b/tools/virtiofsd/passthrough_seccomp.c >> @@ -110,6 +110,7 @@ static const int syscall_allowlist[] = { >> #endif >> SCMP_SYS(set_robust_list), >> SCMP_SYS(setxattr), >> + SCMP_SYS(sigreturn), >> SCMP_SYS(symlinkat), >> SCMP_SYS(syncfs), >> SCMP_SYS(time), /* Rarely needed, except on static builds */ >> -- >> 2.34.1 >> >> _______________________________________________ >> Virtio-fs mailing list >> Virtio-fs@redhat.com >> https://listman.redhat.com/mailman/listinfo/virtio-fs >> > > Reviewed-by: German Maglione <gmaglione@redhat.com> Thanks. > > Should we add this also in the rust version?, I see we don't have it > enabled either. Yep - thanks. > > -- > German >
On Mon, Nov 28, 2022 at 10:00 AM Marc Hartmayer <mhartmay@linux.ibm.com> wrote: > > German Maglione <gmaglione@redhat.com> writes: > > > On Fri, Nov 25, 2022 at 3:40 PM Marc Hartmayer <mhartmay@linux.ibm.com> wrote: > >> > >> The virtiofsd currently crashes on s390x. This is because of a > >> `sigreturn` system call. See audit log below: > >> > >> type=SECCOMP msg=audit(1669382477.611:459): auid=4294967295 uid=0 gid=0 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 pid=6649 comm="virtiofsd" exe="/usr/libexec/virtiofsd" sig=31 arch=80000016 syscall=119 compat=0 ip=0x3fff15f748a code=0x80000000AUID="unset" UID="root" GID="root" ARCH=s390x SYSCALL=sigreturn > >> > >> Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com> > >> --- > >> tools/virtiofsd/passthrough_seccomp.c | 1 + > >> 1 file changed, 1 insertion(+) > >> > >> diff --git a/tools/virtiofsd/passthrough_seccomp.c b/tools/virtiofsd/passthrough_seccomp.c > >> index 888295c073de..0033dab4939e 100644 > >> --- a/tools/virtiofsd/passthrough_seccomp.c > >> +++ b/tools/virtiofsd/passthrough_seccomp.c > >> @@ -110,6 +110,7 @@ static const int syscall_allowlist[] = { > >> #endif > >> SCMP_SYS(set_robust_list), > >> SCMP_SYS(setxattr), > >> + SCMP_SYS(sigreturn), > >> SCMP_SYS(symlinkat), > >> SCMP_SYS(syncfs), > >> SCMP_SYS(time), /* Rarely needed, except on static builds */ > >> -- > >> 2.34.1 > >> > >> _______________________________________________ > >> Virtio-fs mailing list > >> Virtio-fs@redhat.com > >> https://listman.redhat.com/mailman/listinfo/virtio-fs > >> > > > > Reviewed-by: German Maglione <gmaglione@redhat.com> > > Thanks. > > > > > Should we add this also in the rust version?, I see we don't have it > > enabled either. > > Yep - thanks. Could you test this MR to see if it is ok? https://gitlab.com/virtio-fs/virtiofsd/-/merge_requests/144 Thanks,
* Marc Hartmayer (mhartmay@linux.ibm.com) wrote: > The virtiofsd currently crashes on s390x. This is because of a > `sigreturn` system call. See audit log below: > > type=SECCOMP msg=audit(1669382477.611:459): auid=4294967295 uid=0 gid=0 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 pid=6649 comm="virtiofsd" exe="/usr/libexec/virtiofsd" sig=31 arch=80000016 syscall=119 compat=0 ip=0x3fff15f748a code=0x80000000AUID="unset" UID="root" GID="root" ARCH=s390x SYSCALL=sigreturn I'm curious; doesn't that mean that some signal is being delivered and you're returning? Which one? Dave > Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com> > --- > tools/virtiofsd/passthrough_seccomp.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/tools/virtiofsd/passthrough_seccomp.c b/tools/virtiofsd/passthrough_seccomp.c > index 888295c073de..0033dab4939e 100644 > --- a/tools/virtiofsd/passthrough_seccomp.c > +++ b/tools/virtiofsd/passthrough_seccomp.c > @@ -110,6 +110,7 @@ static const int syscall_allowlist[] = { > #endif > SCMP_SYS(set_robust_list), > SCMP_SYS(setxattr), > + SCMP_SYS(sigreturn), > SCMP_SYS(symlinkat), > SCMP_SYS(syncfs), > SCMP_SYS(time), /* Rarely needed, except on static builds */ > -- > 2.34.1 >
"Dr. David Alan Gilbert" <dgilbert@redhat.com> writes: > * Marc Hartmayer (mhartmay@linux.ibm.com) wrote: >> The virtiofsd currently crashes on s390x. This is because of a >> `sigreturn` system call. See audit log below: >> >> type=SECCOMP msg=audit(1669382477.611:459): auid=4294967295 uid=0 gid=0 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 pid=6649 comm="virtiofsd" exe="/usr/libexec/virtiofsd" sig=31 arch=80000016 syscall=119 compat=0 ip=0x3fff15f748a code=0x80000000AUID="unset" UID="root" GID="root" ARCH=s390x SYSCALL=sigreturn > > I'm curious; doesn't that mean that some signal is being delivered and > you're returning? Which one? code=0x80000000 means that the seccomp action SECCOMP_RET_KILL_PROCESS is taken => process is killed by a SIGSYS signal (31) [1]. At least, that’s my understanding of this log message. [1] https://man7.org/linux/man-pages/man2/seccomp.2.html […snip…] > -- > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK >
* Marc Hartmayer (mhartmay@linux.ibm.com) wrote: > "Dr. David Alan Gilbert" <dgilbert@redhat.com> writes: > > > * Marc Hartmayer (mhartmay@linux.ibm.com) wrote: > >> The virtiofsd currently crashes on s390x. This is because of a > >> `sigreturn` system call. See audit log below: > >> > >> type=SECCOMP msg=audit(1669382477.611:459): auid=4294967295 uid=0 gid=0 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 pid=6649 comm="virtiofsd" exe="/usr/libexec/virtiofsd" sig=31 arch=80000016 syscall=119 compat=0 ip=0x3fff15f748a code=0x80000000AUID="unset" UID="root" GID="root" ARCH=s390x SYSCALL=sigreturn > > > > I'm curious; doesn't that mean that some signal is being delivered and > > you're returning? Which one? > > code=0x80000000 means that the seccomp action SECCOMP_RET_KILL_PROCESS > is taken => process is killed by a SIGSYS signal (31) [1]. > > At least, that’s my understanding of this log message. > > [1] https://man7.org/linux/man-pages/man2/seccomp.2.html But isn't that the fallout rather than the cause ? i.e. seccomp is sending a SIGSYS because the process used sigreturn, my question is why did the process call sigreturn in the first place - it must have received a signal to return from? Dave > […snip…] > > > -- > > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK > > > -- > Kind regards / Beste Grüße > Marc Hartmayer > > IBM Deutschland Research & Development GmbH > Vorsitzender des Aufsichtsrats: Gregor Pillen > Geschäftsführung: David Faller > Sitz der Gesellschaft: Böblingen > Registergericht: Amtsgericht Stuttgart, HRB 243294 >
Am 29.11.22 um 10:42 schrieb Dr. David Alan Gilbert: > * Marc Hartmayer (mhartmay@linux.ibm.com) wrote: >> "Dr. David Alan Gilbert" <dgilbert@redhat.com> writes: >> >>> * Marc Hartmayer (mhartmay@linux.ibm.com) wrote: >>>> The virtiofsd currently crashes on s390x. This is because of a >>>> `sigreturn` system call. See audit log below: >>>> >>>> type=SECCOMP msg=audit(1669382477.611:459): auid=4294967295 uid=0 gid=0 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 pid=6649 comm="virtiofsd" exe="/usr/libexec/virtiofsd" sig=31 arch=80000016 syscall=119 compat=0 ip=0x3fff15f748a code=0x80000000AUID="unset" UID="root" GID="root" ARCH=s390x SYSCALL=sigreturn >>> >>> I'm curious; doesn't that mean that some signal is being delivered and >>> you're returning? Which one? >> >> code=0x80000000 means that the seccomp action SECCOMP_RET_KILL_PROCESS >> is taken => process is killed by a SIGSYS signal (31) [1]. >> >> At least, that’s my understanding of this log message. >> >> [1] https://man7.org/linux/man-pages/man2/seccomp.2.html > > But isn't that the fallout rather than the cause ? i.e. seccomp > is sending a SIGSYS because the process used sigreturn, my question > is why did the process call sigreturn in the first place - it must > have received a signal to return from? Good question. virtiofsd seems to prepare itself for int fuse_set_signal_handlers(struct fuse_session *se) { /* * If we used SIG_IGN instead of the do_nothing function, * then we would be unable to tell if we set SIG_IGN (and * thus should reset to SIG_DFL in fuse_remove_signal_handlers) * or if it was already set to SIG_IGN (and should be left * untouched. */ if (set_one_signal_handler(SIGHUP, exit_handler, 0) == -1 || set_one_signal_handler(SIGINT, exit_handler, 0) == -1 || set_one_signal_handler(SIGTERM, exit_handler, 0) == -1 || set_one_signal_handler(SIGPIPE, do_nothing, 0) == -1) { return -1; } Given that rt_sigreturn was already on the seccomp list it seems to be expected that those handlers are called.
Am 29.11.22 um 10:52 schrieb Christian Borntraeger: > > > Am 29.11.22 um 10:42 schrieb Dr. David Alan Gilbert: >> * Marc Hartmayer (mhartmay@linux.ibm.com) wrote: >>> "Dr. David Alan Gilbert" <dgilbert@redhat.com> writes: >>> >>>> * Marc Hartmayer (mhartmay@linux.ibm.com) wrote: >>>>> The virtiofsd currently crashes on s390x. This is because of a >>>>> `sigreturn` system call. See audit log below: >>>>> >>>>> type=SECCOMP msg=audit(1669382477.611:459): auid=4294967295 uid=0 gid=0 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 pid=6649 comm="virtiofsd" exe="/usr/libexec/virtiofsd" sig=31 arch=80000016 syscall=119 compat=0 ip=0x3fff15f748a code=0x80000000AUID="unset" UID="root" GID="root" ARCH=s390x SYSCALL=sigreturn >>>> >>>> I'm curious; doesn't that mean that some signal is being delivered and >>>> you're returning? Which one? >>> >>> code=0x80000000 means that the seccomp action SECCOMP_RET_KILL_PROCESS >>> is taken => process is killed by a SIGSYS signal (31) [1]. >>> >>> At least, that’s my understanding of this log message. >>> >>> [1] https://man7.org/linux/man-pages/man2/seccomp.2.html >> >> But isn't that the fallout rather than the cause ? i.e. seccomp >> is sending a SIGSYS because the process used sigreturn, my question >> is why did the process call sigreturn in the first place - it must >> have received a signal to return from? > > Good question. virtiofsd seems to prepare itself for > > int fuse_set_signal_handlers(struct fuse_session *se) > { > /* > * If we used SIG_IGN instead of the do_nothing function, > * then we would be unable to tell if we set SIG_IGN (and > * thus should reset to SIG_DFL in fuse_remove_signal_handlers) > * or if it was already set to SIG_IGN (and should be left > * untouched. > */ > if (set_one_signal_handler(SIGHUP, exit_handler, 0) == -1 || > set_one_signal_handler(SIGINT, exit_handler, 0) == -1 || > set_one_signal_handler(SIGTERM, exit_handler, 0) == -1 || > set_one_signal_handler(SIGPIPE, do_nothing, 0) == -1) { > return -1; > } > > > > Given that rt_sigreturn was already on the seccomp list it seems > to be expected that those handlers are called. For me, it seems to happen on shutdown: Stack trace of thread 1: #0 0x000003ffc06f348a __kernel_sigreturn (linux-vdso64.so.1 + 0x48a) #1 0x000003ffc06f3488 __kernel_sigreturn (linux-vdso64.so.1 + 0x488) #2 0x000003ff9af1be96 __GI___futex_abstimed_wait_cancelable64 (libc.so.6 + 0x9be96) #3 0x000003ff9af211b4 __pthread_clockjoin_ex (libc.so.6 + 0xa11b4) #4 0x000003ff9af2106e pthread_join@GLIBC_2.2 (libc.so.6 + 0xa106e) #5 0x000002aa35d2fe36 fv_queue_cleanup_thread (virtiofsd + 0x2fe36) #6 0x000002aa35d3152c stop_all_queues (virtiofsd + 0x3152c) #7 0x000002aa35d2869c main (virtiofsd + 0x2869c) #8 0x000003ff9aeb4872 __libc_start_call_main (libc.so.6 + 0x34872) #9 0x000003ff9aeb4950 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x34950) #10 0x000002aa35d290a0 .annobin_libvhost_user.c_end.startup (virtiofsd + 0x290a0)
* Christian Borntraeger (borntraeger@de.ibm.com) wrote: > > > Am 29.11.22 um 10:52 schrieb Christian Borntraeger: > > > > > > Am 29.11.22 um 10:42 schrieb Dr. David Alan Gilbert: > > > * Marc Hartmayer (mhartmay@linux.ibm.com) wrote: > > > > "Dr. David Alan Gilbert" <dgilbert@redhat.com> writes: > > > > > > > > > * Marc Hartmayer (mhartmay@linux.ibm.com) wrote: > > > > > > The virtiofsd currently crashes on s390x. This is because of a > > > > > > `sigreturn` system call. See audit log below: > > > > > > > > > > > > type=SECCOMP msg=audit(1669382477.611:459): auid=4294967295 uid=0 gid=0 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 pid=6649 comm="virtiofsd" exe="/usr/libexec/virtiofsd" sig=31 arch=80000016 syscall=119 compat=0 ip=0x3fff15f748a code=0x80000000AUID="unset" UID="root" GID="root" ARCH=s390x SYSCALL=sigreturn > > > > > > > > > > I'm curious; doesn't that mean that some signal is being delivered and > > > > > you're returning? Which one? > > > > > > > > code=0x80000000 means that the seccomp action SECCOMP_RET_KILL_PROCESS > > > > is taken => process is killed by a SIGSYS signal (31) [1]. > > > > > > > > At least, that’s my understanding of this log message. > > > > > > > > [1] https://man7.org/linux/man-pages/man2/seccomp.2.html > > > > > > But isn't that the fallout rather than the cause ? i.e. seccomp > > > is sending a SIGSYS because the process used sigreturn, my question > > > is why did the process call sigreturn in the first place - it must > > > have received a signal to return from? > > > > Good question. virtiofsd seems to prepare itself for > > > > int fuse_set_signal_handlers(struct fuse_session *se) > > { > > /* > > * If we used SIG_IGN instead of the do_nothing function, > > * then we would be unable to tell if we set SIG_IGN (and > > * thus should reset to SIG_DFL in fuse_remove_signal_handlers) > > * or if it was already set to SIG_IGN (and should be left > > * untouched. > > */ > > if (set_one_signal_handler(SIGHUP, exit_handler, 0) == -1 || > > set_one_signal_handler(SIGINT, exit_handler, 0) == -1 || > > set_one_signal_handler(SIGTERM, exit_handler, 0) == -1 || > > set_one_signal_handler(SIGPIPE, do_nothing, 0) == -1) { > > return -1; > > } > > > > > > > > Given that rt_sigreturn was already on the seccomp list it seems > > to be expected that those handlers are called. > > For me, it seems to happen on shutdown: > Stack trace of thread 1: > #0 0x000003ffc06f348a __kernel_sigreturn (linux-vdso64.so.1 + 0x48a) > #1 0x000003ffc06f3488 __kernel_sigreturn (linux-vdso64.so.1 + 0x488) > #2 0x000003ff9af1be96 __GI___futex_abstimed_wait_cancelable64 (libc.so.6 + 0x9be96) > #3 0x000003ff9af211b4 __pthread_clockjoin_ex (libc.so.6 + 0xa11b4) > #4 0x000003ff9af2106e pthread_join@GLIBC_2.2 (libc.so.6 + 0xa106e) > #5 0x000002aa35d2fe36 fv_queue_cleanup_thread (virtiofsd + 0x2fe36) > #6 0x000002aa35d3152c stop_all_queues (virtiofsd + 0x3152c) > #7 0x000002aa35d2869c main (virtiofsd + 0x2869c) > #8 0x000003ff9aeb4872 __libc_start_call_main (libc.so.6 + 0x34872) > #9 0x000003ff9aeb4950 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x34950) > #10 0x000002aa35d290a0 .annobin_libvhost_user.c_end.startup (virtiofsd + 0x290a0) <shrug> I guess it could be a SIGCHLD or SIGPIPE or something during shutdown; I guess especially since we have the SIGPIPE registered. Dave >
Christian Borntraeger <borntraeger@de.ibm.com> writes: > Am 29.11.22 um 10:52 schrieb Christian Borntraeger: >> >> >> Am 29.11.22 um 10:42 schrieb Dr. David Alan Gilbert: >>> * Marc Hartmayer (mhartmay@linux.ibm.com) wrote: >>>> "Dr. David Alan Gilbert" <dgilbert@redhat.com> writes: >>>> >>>>> * Marc Hartmayer (mhartmay@linux.ibm.com) wrote: >>>>>> The virtiofsd currently crashes on s390x. This is because of a >>>>>> `sigreturn` system call. See audit log below: >>>>>> >>>>>> type=SECCOMP msg=audit(1669382477.611:459): auid=4294967295 uid=0 gid=0 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 pid=6649 comm="virtiofsd" exe="/usr/libexec/virtiofsd" sig=31 arch=80000016 syscall=119 compat=0 ip=0x3fff15f748a code=0x80000000AUID="unset" UID="root" GID="root" ARCH=s390x SYSCALL=sigreturn >>>>> >>>>> I'm curious; doesn't that mean that some signal is being delivered and >>>>> you're returning? Which one? >>>> >>>> code=0x80000000 means that the seccomp action SECCOMP_RET_KILL_PROCESS >>>> is taken => process is killed by a SIGSYS signal (31) [1]. >>>> >>>> At least, that’s my understanding of this log message. >>>> >>>> [1] https://man7.org/linux/man-pages/man2/seccomp.2.html >>> >>> But isn't that the fallout rather than the cause ? i.e. seccomp >>> is sending a SIGSYS because the process used sigreturn, my question >>> is why did the process call sigreturn in the first place - it must >>> have received a signal to return from? >> >> Good question. virtiofsd seems to prepare itself for >> >> int fuse_set_signal_handlers(struct fuse_session *se) >> { >> /* >> * If we used SIG_IGN instead of the do_nothing function, >> * then we would be unable to tell if we set SIG_IGN (and >> * thus should reset to SIG_DFL in fuse_remove_signal_handlers) >> * or if it was already set to SIG_IGN (and should be left >> * untouched. >> */ >> if (set_one_signal_handler(SIGHUP, exit_handler, 0) == -1 || >> set_one_signal_handler(SIGINT, exit_handler, 0) == -1 || >> set_one_signal_handler(SIGTERM, exit_handler, 0) == -1 || >> set_one_signal_handler(SIGPIPE, do_nothing, 0) == -1) { >> return -1; >> } >> >> >> >> Given that rt_sigreturn was already on the seccomp list it seems >> to be expected that those handlers are called. > > For me, it seems to happen on shutdown: > Stack trace of thread 1: > #0 0x000003ffc06f348a __kernel_sigreturn (linux-vdso64.so.1 + 0x48a) > #1 0x000003ffc06f3488 __kernel_sigreturn (linux-vdso64.so.1 + 0x488) > #2 0x000003ff9af1be96 __GI___futex_abstimed_wait_cancelable64 (libc.so.6 + 0x9be96) > #3 0x000003ff9af211b4 __pthread_clockjoin_ex (libc.so.6 + 0xa11b4) > #4 0x000003ff9af2106e pthread_join@GLIBC_2.2 (libc.so.6 + 0xa106e) > #5 0x000002aa35d2fe36 fv_queue_cleanup_thread (virtiofsd + 0x2fe36) > #6 0x000002aa35d3152c stop_all_queues (virtiofsd + 0x3152c) > #7 0x000002aa35d2869c main (virtiofsd + 0x2869c) > #8 0x000003ff9aeb4872 __libc_start_call_main (libc.so.6 + 0x34872) > #9 0x000003ff9aeb4950 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x34950) > #10 0x000002aa35d290a0 .annobin_libvhost_user.c_end.startup (virtiofsd + 0x290a0) > > That’s also what I see. -- Kind regards / Beste Grüße Marc Hartmayer IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Gregor Pillen Geschäftsführung: David Faller Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294
To find out: # perf record -e signal:signal_deliver ...wait for QEMU shutdown... ^C # perf script qemu-system-x86_64 2319136 [001] 1062886.415312: signal:signal_deliver: sig=2 errno=0 code=128 sa_handler=7fc6ccfbabc0 sa_flags=14000004 sig=2 is SIGINT. This is just an example, I didn't run virtiofsd.
German Maglione <gmaglione@redhat.com> writes: > On Mon, Nov 28, 2022 at 10:00 AM Marc Hartmayer <mhartmay@linux.ibm.com> wrote: >> >> German Maglione <gmaglione@redhat.com> writes: >> >> > On Fri, Nov 25, 2022 at 3:40 PM Marc Hartmayer <mhartmay@linux.ibm.com> wrote: >> >> >> >> The virtiofsd currently crashes on s390x. This is because of a >> >> `sigreturn` system call. See audit log below: >> >> >> >> type=SECCOMP msg=audit(1669382477.611:459): auid=4294967295 uid=0 gid=0 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 pid=6649 comm="virtiofsd" exe="/usr/libexec/virtiofsd" sig=31 arch=80000016 syscall=119 compat=0 ip=0x3fff15f748a code=0x80000000AUID="unset" UID="root" GID="root" ARCH=s390x SYSCALL=sigreturn >> >> >> >> Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com> >> >> --- >> >> tools/virtiofsd/passthrough_seccomp.c | 1 + >> >> 1 file changed, 1 insertion(+) >> >> >> >> diff --git a/tools/virtiofsd/passthrough_seccomp.c b/tools/virtiofsd/passthrough_seccomp.c >> >> index 888295c073de..0033dab4939e 100644 >> >> --- a/tools/virtiofsd/passthrough_seccomp.c >> >> +++ b/tools/virtiofsd/passthrough_seccomp.c >> >> @@ -110,6 +110,7 @@ static const int syscall_allowlist[] = { >> >> #endif >> >> SCMP_SYS(set_robust_list), >> >> SCMP_SYS(setxattr), >> >> + SCMP_SYS(sigreturn), >> >> SCMP_SYS(symlinkat), >> >> SCMP_SYS(syncfs), >> >> SCMP_SYS(time), /* Rarely needed, except on static builds */ >> >> -- >> >> 2.34.1 >> >> >> >> _______________________________________________ >> >> Virtio-fs mailing list >> >> Virtio-fs@redhat.com >> >> https://listman.redhat.com/mailman/listinfo/virtio-fs >> >> >> > >> > Reviewed-by: German Maglione <gmaglione@redhat.com> >> >> Thanks. >> >> > >> > Should we add this also in the rust version?, I see we don't have it >> > enabled either. >> >> Yep - thanks. > > Could you test this MR to see if it is ok? > https://gitlab.com/virtio-fs/virtiofsd/-/merge_requests/144 I couldn’t reproduce the problem using the Rust version - even without your patch. With your patch applied it’s (of course) still working. > > Thanks, > > -- > German >
diff --git a/tools/virtiofsd/passthrough_seccomp.c b/tools/virtiofsd/passthrough_seccomp.c index 888295c073de..0033dab4939e 100644 --- a/tools/virtiofsd/passthrough_seccomp.c +++ b/tools/virtiofsd/passthrough_seccomp.c @@ -110,6 +110,7 @@ static const int syscall_allowlist[] = { #endif SCMP_SYS(set_robust_list), SCMP_SYS(setxattr), + SCMP_SYS(sigreturn), SCMP_SYS(symlinkat), SCMP_SYS(syncfs), SCMP_SYS(time), /* Rarely needed, except on static builds */
The virtiofsd currently crashes on s390x. This is because of a `sigreturn` system call. See audit log below: type=SECCOMP msg=audit(1669382477.611:459): auid=4294967295 uid=0 gid=0 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 pid=6649 comm="virtiofsd" exe="/usr/libexec/virtiofsd" sig=31 arch=80000016 syscall=119 compat=0 ip=0x3fff15f748a code=0x80000000AUID="unset" UID="root" GID="root" ARCH=s390x SYSCALL=sigreturn Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com> --- tools/virtiofsd/passthrough_seccomp.c | 1 + 1 file changed, 1 insertion(+)