1. Patchew
  2. QEMU
  3. View series

[PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist

Marc Hartmayer posted 1 patch 1 year, 4 months ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/20221125143946.27717-1-mhartmay@linux.ibm.com
Maintainers: "Dr. David Alan Gilbert" <dgilbert@redhat.com>, Stefan Hajnoczi <stefanha@redhat.com>
tools/virtiofsd/passthrough_seccomp.c | 1 +
1 file changed, 1 insertion(+)
[PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
Posted by Marc Hartmayer 1 year, 4 months ago 
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
Re: [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
Posted by Dr. David Alan Gilbert 1 year, 4 months ago 
* 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 / Manchester, UK
Re: [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
Posted by Marc Hartmayer 1 year, 4 months ago 
"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
>
-- 
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
Posted by Dr. David Alan Gilbert 1 year, 4 months ago 
* 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
> 
-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
Re: [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
Posted by Christian Borntraeger 1 year, 4 months ago 

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.
Re: [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
Posted by Christian Borntraeger 1 year, 4 months ago 

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)
Re: [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
Posted by Dr. David Alan Gilbert 1 year, 4 months ago 
* 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

> 
-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
Re: [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
Posted by Stefan Hajnoczi 1 year, 4 months ago 
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.
Re: [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
Posted by Marc Hartmayer 1 year, 4 months ago 
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
Re: [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
Posted by Stefan Hajnoczi 1 year, 4 months ago 
Thanks, applied to qemu.git/master.

Stefan
Re: [Virtio-fs] [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
Posted by German Maglione 1 year, 4 months ago 
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.

-- 
German
Re: [Virtio-fs] [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
Posted by Marc Hartmayer 1 year, 4 months ago 
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
>
-- 
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
Posted by German Maglione 1 year, 4 months ago 
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,

-- 
German
Re: [Virtio-fs] [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
Posted by Marc Hartmayer 1 year, 4 months ago 
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
>
-- 
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
Posted by Christian Borntraeger 1 year, 4 months ago 
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.

Patchew 2.1-devel-0870f84

© 2016 - 2024 Red Hat, Inc.