Re: [Virtio-fs] [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
German Maglione writes: > On Mon, Nov 28, 2022 at 10:00 AM Marc Hartmayer > wrote: >> >> German Maglione writes: >> >> > On Fri, Nov 25, 2022 at 3:40 PM Marc Hartmayer >> > 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=8016 >> >> syscall=119 compat=0 ip=0x3fff15f748a code=0x8000AUID="unset" >> >> UID="root" GID="root" ARCH=s390x SYSCALL=sigreturn >> >> >> >> Signed-off-by: Marc Hartmayer >> >> --- >> >> 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...@redhat.com >> >> https://listman.redhat.com/mailman/listinfo/virtio-fs >> >> >> > >> > Reviewed-by: German Maglione >> >> 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 > -- 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
Re: [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
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=1404 sig=2 is SIGINT. This is just an example, I didn't run virtiofsd.
Re: [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
Am 29.11.22 um 10:42 schrieb Dr. David Alan Gilbert: * Marc Hartmayer (mhart...@linux.ibm.com) wrote: "Dr. David Alan Gilbert" writes: * Marc Hartmayer (mhart...@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=8016 syscall=119 compat=0 ip=0x3fff15f748a code=0x8000AUID="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=0x8000 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.
Re: [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
Christian Borntraeger 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 (mhart...@linux.ibm.com) wrote: "Dr. David Alan Gilbert" writes: > * Marc Hartmayer (mhart...@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=8016 >> syscall=119 compat=0 ip=0x3fff15f748a code=0x8000AUID="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=0x8000 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 0x03ffc06f348a __kernel_sigreturn (linux-vdso64.so.1 > + 0x48a) > #1 0x03ffc06f3488 __kernel_sigreturn (linux-vdso64.so.1 > + 0x488) > #2 0x03ff9af1be96 > __GI___futex_abstimed_wait_cancelable64 (libc.so.6 + 0x9be96) > #3 0x03ff9af211b4 __pthread_clockjoin_ex (libc.so.6 + > 0xa11b4) > #4 0x03ff9af2106e pthread_join@GLIBC_2.2 (libc.so.6 + > 0xa106e) > #5 0x02aa35d2fe36 fv_queue_cleanup_thread (virtiofsd + > 0x2fe36) > #6 0x02aa35d3152c stop_all_queues (virtiofsd + 0x3152c) > #7 0x02aa35d2869c main (virtiofsd + 0x2869c) > #8 0x03ff9aeb4872 __libc_start_call_main (libc.so.6 + > 0x34872) > #9 0x03ff9aeb4950 __libc_start_main@@GLIBC_2.34 > (libc.so.6 + 0x34950) > #10 0x02aa35d290a0 .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
Re: [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
* Christian Borntraeger (borntrae...@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 (mhart...@linux.ibm.com) wrote: > > > > "Dr. David Alan Gilbert" writes: > > > > > > > > > * Marc Hartmayer (mhart...@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=8016 syscall=119 compat=0 ip=0x3fff15f748a > > > > > > code=0x8000AUID="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=0x8000 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 0x03ffc06f348a __kernel_sigreturn (linux-vdso64.so.1 > + 0x48a) > #1 0x03ffc06f3488 __kernel_sigreturn (linux-vdso64.so.1 > + 0x488) > #2 0x03ff9af1be96 > __GI___futex_abstimed_wait_cancelable64 (libc.so.6 + 0x9be96) > #3 0x03ff9af211b4 __pthread_clockjoin_ex (libc.so.6 + > 0xa11b4) > #4 0x03ff9af2106e pthread_join@GLIBC_2.2 (libc.so.6 + > 0xa106e) > #5 0x02aa35d2fe36 fv_queue_cleanup_thread (virtiofsd + > 0x2fe36) > #6 0x02aa35d3152c stop_all_queues (virtiofsd + 0x3152c) > #7 0x02aa35d2869c main (virtiofsd + 0x2869c) > #8 0x03ff9aeb4872 __libc_start_call_main (libc.so.6 + > 0x34872) > #9 0x03ff9aeb4950 __libc_start_main@@GLIBC_2.34 > (libc.so.6 + 0x34950) > #10 0x02aa35d290a0 .annobin_libvhost_user.c_end.startup > (virtiofsd + 0x290a0) I guess it could be a SIGCHLD or SIGPIPE or something during shutdown; I guess especially since we have the SIGPIPE registered. Dave > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
Am 29.11.22 um 10:52 schrieb Christian Borntraeger: Am 29.11.22 um 10:42 schrieb Dr. David Alan Gilbert: * Marc Hartmayer (mhart...@linux.ibm.com) wrote: "Dr. David Alan Gilbert" writes: * Marc Hartmayer (mhart...@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=8016 syscall=119 compat=0 ip=0x3fff15f748a code=0x8000AUID="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=0x8000 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 0x03ffc06f348a __kernel_sigreturn (linux-vdso64.so.1 + 0x48a) #1 0x03ffc06f3488 __kernel_sigreturn (linux-vdso64.so.1 + 0x488) #2 0x03ff9af1be96 __GI___futex_abstimed_wait_cancelable64 (libc.so.6 + 0x9be96) #3 0x03ff9af211b4 __pthread_clockjoin_ex (libc.so.6 + 0xa11b4) #4 0x03ff9af2106e pthread_join@GLIBC_2.2 (libc.so.6 + 0xa106e) #5 0x02aa35d2fe36 fv_queue_cleanup_thread (virtiofsd + 0x2fe36) #6 0x02aa35d3152c stop_all_queues (virtiofsd + 0x3152c) #7 0x02aa35d2869c main (virtiofsd + 0x2869c) #8 0x03ff9aeb4872 __libc_start_call_main (libc.so.6 + 0x34872) #9 0x03ff9aeb4950 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x34950) #10 0x02aa35d290a0 .annobin_libvhost_user.c_end.startup (virtiofsd + 0x290a0)
Re: [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
* Marc Hartmayer (mhart...@linux.ibm.com) wrote: > "Dr. David Alan Gilbert" writes: > > > * Marc Hartmayer (mhart...@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=8016 > >> syscall=119 compat=0 ip=0x3fff15f748a code=0x8000AUID="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=0x8000 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 / dgilb...@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 > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
"Dr. David Alan Gilbert" writes: > * Marc Hartmayer (mhart...@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=8016 >> syscall=119 compat=0 ip=0x3fff15f748a code=0x8000AUID="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=0x8000 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 / dgilb...@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
Re: [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
* Marc Hartmayer (mhart...@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=8016 > syscall=119 compat=0 ip=0x3fff15f748a code=0x8000AUID="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 > --- > 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 / dgilb...@redhat.com / Manchester, UK
Re: [Virtio-fs] [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
On Mon, Nov 28, 2022 at 10:00 AM Marc Hartmayer wrote: > > German Maglione writes: > > > On Fri, Nov 25, 2022 at 3:40 PM Marc Hartmayer > > 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=8016 > >> syscall=119 compat=0 ip=0x3fff15f748a code=0x8000AUID="unset" > >> UID="root" GID="root" ARCH=s390x SYSCALL=sigreturn > >> > >> Signed-off-by: Marc Hartmayer > >> --- > >> 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...@redhat.com > >> https://listman.redhat.com/mailman/listinfo/virtio-fs > >> > > > > Reviewed-by: German Maglione > > 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, -- German
Re: [Virtio-fs] [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
German Maglione writes: > On Fri, Nov 25, 2022 at 3:40 PM Marc Hartmayer 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=8016 >> syscall=119 compat=0 ip=0x3fff15f748a code=0x8000AUID="unset" UID="root" >> GID="root" ARCH=s390x SYSCALL=sigreturn >> >> Signed-off-by: Marc Hartmayer >> --- >> 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...@redhat.com >> https://listman.redhat.com/mailman/listinfo/virtio-fs >> > > Reviewed-by: German Maglione Thanks. > > Should we add this also in the rust version?, I see we don't have it > enabled either. Yep - thanks. > > -- > German > -- 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
Re: [Virtio-fs] [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
Am 25.11.22 um 17:32 schrieb German Maglione: On Fri, Nov 25, 2022 at 3:40 PM Marc Hartmayer 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=8016 syscall=119 compat=0 ip=0x3fff15f748a code=0x8000AUID="unset" UID="root" GID="root" ARCH=s390x SYSCALL=sigreturn Signed-off-by: Marc Hartmayer --- 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...@redhat.com https://listman.redhat.com/mailman/listinfo/virtio-fs Reviewed-by: German Maglione Should we add this also in the rust version?, I see we don't have it enabled either. this is probably a good idea.
Re: [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
Thanks, applied to qemu.git/master. Stefan
Re: [Virtio-fs] [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
On Fri, Nov 25, 2022 at 3:40 PM Marc Hartmayer 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=8016 > syscall=119 compat=0 ip=0x3fff15f748a code=0x8000AUID="unset" UID="root" > GID="root" ARCH=s390x SYSCALL=sigreturn > > Signed-off-by: Marc Hartmayer > --- > 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...@redhat.com > https://listman.redhat.com/mailman/listinfo/virtio-fs > Reviewed-by: German Maglione Should we add this also in the rust version?, I see we don't have it enabled either. -- German
[PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
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=8016 syscall=119 compat=0 ip=0x3fff15f748a code=0x8000AUID="unset" UID="root" GID="root" ARCH=s390x SYSCALL=sigreturn Signed-off-by: Marc Hartmayer --- 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