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
