* [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
@ 2022-11-25 14:39 ` Marc Hartmayer
0 siblings, 0 replies; 25+ messages in thread
From: Marc Hartmayer @ 2022-11-25 14:39 UTC (permalink / raw)
To: qemu-devel
Cc: qemu-s390x, virtio-fs, Dr. David Alan Gilbert, Stefan Hajnoczi,
Christian Borntraeger, Sven Schnelle, Stefan Liebler
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
^ permalink raw reply related [flat|nested] 25+ messages in thread
* [Virtio-fs] [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
@ 2022-11-25 14:39 ` Marc Hartmayer
0 siblings, 0 replies; 25+ messages in thread
From: Marc Hartmayer @ 2022-11-25 14:39 UTC (permalink / raw)
To: qemu-devel
Cc: qemu-s390x, virtio-fs, Dr. David Alan Gilbert, Stefan Hajnoczi,
Christian Borntraeger, Sven Schnelle, Stefan Liebler
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
^ permalink raw reply related [flat|nested] 25+ messages in thread
* Re: [Virtio-fs] [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
2022-11-25 14:39 ` [Virtio-fs] " Marc Hartmayer
(?)
@ 2022-11-25 16:32 ` German Maglione
2022-11-28 6:18 ` Christian Borntraeger
2022-11-28 9:00 ` Marc Hartmayer
-1 siblings, 2 replies; 25+ messages in thread
From: German Maglione @ 2022-11-25 16:32 UTC (permalink / raw)
To: Marc Hartmayer
Cc: qemu-devel, Stefan Liebler, virtio-fs, Christian Borntraeger,
qemu-s390x, Sven Schnelle, Stefan Hajnoczi
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
2022-11-25 14:39 ` [Virtio-fs] " Marc Hartmayer
@ 2022-11-25 20:50 ` Stefan Hajnoczi
-1 siblings, 0 replies; 25+ messages in thread
From: Stefan Hajnoczi @ 2022-11-25 20:50 UTC (permalink / raw)
To: Marc Hartmayer
Cc: qemu-devel, qemu-s390x, virtio-fs, Dr. David Alan Gilbert,
Stefan Hajnoczi, Christian Borntraeger, Sven Schnelle,
Stefan Liebler
Thanks, applied to qemu.git/master.
Stefan
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Virtio-fs] [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
@ 2022-11-25 20:50 ` Stefan Hajnoczi
0 siblings, 0 replies; 25+ messages in thread
From: Stefan Hajnoczi @ 2022-11-25 20:50 UTC (permalink / raw)
To: Marc Hartmayer
Cc: qemu-devel, qemu-s390x, virtio-fs, Dr. David Alan Gilbert,
Stefan Hajnoczi, Christian Borntraeger, Sven Schnelle,
Stefan Liebler
Thanks, applied to qemu.git/master.
Stefan
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Virtio-fs] [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
2022-11-25 16:32 ` German Maglione
@ 2022-11-28 6:18 ` Christian Borntraeger
2022-11-28 9:00 ` Marc Hartmayer
1 sibling, 0 replies; 25+ messages in thread
From: Christian Borntraeger @ 2022-11-28 6:18 UTC (permalink / raw)
To: German Maglione, Marc Hartmayer
Cc: qemu-devel, Stefan Liebler, virtio-fs, qemu-s390x, Sven Schnelle,
Stefan Hajnoczi
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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Virtio-fs] [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
2022-11-25 16:32 ` German Maglione
2022-11-28 6:18 ` Christian Borntraeger
@ 2022-11-28 9:00 ` Marc Hartmayer
2022-11-28 10:17 ` German Maglione
1 sibling, 1 reply; 25+ messages in thread
From: Marc Hartmayer @ 2022-11-28 9:00 UTC (permalink / raw)
To: German Maglione
Cc: qemu-devel, Stefan Liebler, virtio-fs, Christian Borntraeger,
qemu-s390x, Sven Schnelle, Stefan Hajnoczi
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Virtio-fs] [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
2022-11-28 9:00 ` Marc Hartmayer
@ 2022-11-28 10:17 ` German Maglione
2022-12-01 9:44 ` Marc Hartmayer
0 siblings, 1 reply; 25+ messages in thread
From: German Maglione @ 2022-11-28 10:17 UTC (permalink / raw)
To: Marc Hartmayer
Cc: qemu-devel, Stefan Liebler, virtio-fs, Christian Borntraeger,
qemu-s390x, Sven Schnelle, Stefan Hajnoczi
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
2022-11-25 14:39 ` [Virtio-fs] " Marc Hartmayer
@ 2022-11-28 18:47 ` Dr. David Alan Gilbert
-1 siblings, 0 replies; 25+ messages in thread
From: Dr. David Alan Gilbert @ 2022-11-28 18:47 UTC (permalink / raw)
To: Marc Hartmayer
Cc: qemu-devel, qemu-s390x, virtio-fs, Stefan Hajnoczi,
Christian Borntraeger, Sven Schnelle, Stefan Liebler
* 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Virtio-fs] [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
@ 2022-11-28 18:47 ` Dr. David Alan Gilbert
0 siblings, 0 replies; 25+ messages in thread
From: Dr. David Alan Gilbert @ 2022-11-28 18:47 UTC (permalink / raw)
To: Marc Hartmayer
Cc: qemu-devel, qemu-s390x, virtio-fs, Stefan Hajnoczi,
Christian Borntraeger, Sven Schnelle, Stefan Liebler
* 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
2022-11-28 18:47 ` [Virtio-fs] " Dr. David Alan Gilbert
@ 2022-11-29 9:38 ` Marc Hartmayer
-1 siblings, 0 replies; 25+ messages in thread
From: Marc Hartmayer @ 2022-11-29 9:38 UTC (permalink / raw)
To: Dr. David Alan Gilbert
Cc: qemu-devel, qemu-s390x, virtio-fs, Stefan Hajnoczi,
Christian Borntraeger, Sven Schnelle, Stefan Liebler
"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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Virtio-fs] [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
@ 2022-11-29 9:38 ` Marc Hartmayer
0 siblings, 0 replies; 25+ messages in thread
From: Marc Hartmayer @ 2022-11-29 9:38 UTC (permalink / raw)
To: Dr. David Alan Gilbert
Cc: qemu-devel, qemu-s390x, virtio-fs, Stefan Hajnoczi,
Christian Borntraeger, Sven Schnelle, Stefan Liebler
"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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
2022-11-29 9:38 ` [Virtio-fs] " Marc Hartmayer
@ 2022-11-29 9:42 ` Dr. David Alan Gilbert
-1 siblings, 0 replies; 25+ messages in thread
From: Dr. David Alan Gilbert @ 2022-11-29 9:42 UTC (permalink / raw)
To: Marc Hartmayer
Cc: qemu-devel, qemu-s390x, virtio-fs, Stefan Hajnoczi,
Christian Borntraeger, Sven Schnelle, Stefan Liebler
* 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Virtio-fs] [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
@ 2022-11-29 9:42 ` Dr. David Alan Gilbert
0 siblings, 0 replies; 25+ messages in thread
From: Dr. David Alan Gilbert @ 2022-11-29 9:42 UTC (permalink / raw)
To: Marc Hartmayer
Cc: qemu-devel, qemu-s390x, virtio-fs, Stefan Hajnoczi,
Christian Borntraeger, Sven Schnelle, Stefan Liebler
* 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
2022-11-29 9:42 ` [Virtio-fs] " Dr. David Alan Gilbert
@ 2022-11-29 9:52 ` Christian Borntraeger
-1 siblings, 0 replies; 25+ messages in thread
From: Christian Borntraeger @ 2022-11-29 9:52 UTC (permalink / raw)
To: Dr. David Alan Gilbert, Marc Hartmayer
Cc: qemu-devel, qemu-s390x, virtio-fs, Stefan Hajnoczi,
Sven Schnelle, Stefan Liebler
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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Virtio-fs] [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
@ 2022-11-29 9:52 ` Christian Borntraeger
0 siblings, 0 replies; 25+ messages in thread
From: Christian Borntraeger @ 2022-11-29 9:52 UTC (permalink / raw)
To: Dr. David Alan Gilbert, Marc Hartmayer
Cc: qemu-devel, qemu-s390x, virtio-fs, Stefan Hajnoczi,
Sven Schnelle, Stefan Liebler
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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
2022-11-29 9:52 ` [Virtio-fs] " Christian Borntraeger
@ 2022-11-29 9:57 ` Christian Borntraeger
-1 siblings, 0 replies; 25+ messages in thread
From: Christian Borntraeger @ 2022-11-29 9:57 UTC (permalink / raw)
To: Dr. David Alan Gilbert, Marc Hartmayer
Cc: qemu-devel, qemu-s390x, virtio-fs, Stefan Hajnoczi,
Sven Schnelle, Stefan Liebler
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)
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Virtio-fs] [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
@ 2022-11-29 9:57 ` Christian Borntraeger
0 siblings, 0 replies; 25+ messages in thread
From: Christian Borntraeger @ 2022-11-29 9:57 UTC (permalink / raw)
To: Dr. David Alan Gilbert, Marc Hartmayer
Cc: qemu-devel, qemu-s390x, virtio-fs, Stefan Hajnoczi,
Sven Schnelle, Stefan Liebler
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)
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
2022-11-29 9:57 ` [Virtio-fs] " Christian Borntraeger
@ 2022-11-29 10:16 ` Dr. David Alan Gilbert
-1 siblings, 0 replies; 25+ messages in thread
From: Dr. David Alan Gilbert @ 2022-11-29 10:16 UTC (permalink / raw)
To: Christian Borntraeger
Cc: Marc Hartmayer, qemu-devel, qemu-s390x, virtio-fs,
Stefan Hajnoczi, Sven Schnelle, Stefan Liebler
* 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Virtio-fs] [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
@ 2022-11-29 10:16 ` Dr. David Alan Gilbert
0 siblings, 0 replies; 25+ messages in thread
From: Dr. David Alan Gilbert @ 2022-11-29 10:16 UTC (permalink / raw)
To: Christian Borntraeger
Cc: Marc Hartmayer, qemu-devel, qemu-s390x, virtio-fs,
Stefan Hajnoczi, Sven Schnelle, Stefan Liebler
* 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
2022-11-29 9:57 ` [Virtio-fs] " Christian Borntraeger
@ 2022-11-29 10:16 ` Marc Hartmayer
-1 siblings, 0 replies; 25+ messages in thread
From: Marc Hartmayer @ 2022-11-29 10:16 UTC (permalink / raw)
To: Christian Borntraeger, Dr. David Alan Gilbert
Cc: qemu-devel, qemu-s390x, virtio-fs, Stefan Hajnoczi,
Sven Schnelle, Stefan Liebler
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Virtio-fs] [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
@ 2022-11-29 10:16 ` Marc Hartmayer
0 siblings, 0 replies; 25+ messages in thread
From: Marc Hartmayer @ 2022-11-29 10:16 UTC (permalink / raw)
To: Christian Borntraeger, Dr. David Alan Gilbert
Cc: qemu-devel, qemu-s390x, virtio-fs, Stefan Hajnoczi,
Sven Schnelle, Stefan Liebler
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
2022-11-29 10:16 ` [Virtio-fs] " Dr. David Alan Gilbert
@ 2022-11-29 12:04 ` Stefan Hajnoczi
-1 siblings, 0 replies; 25+ messages in thread
From: Stefan Hajnoczi @ 2022-11-29 12:04 UTC (permalink / raw)
To: Dr. David Alan Gilbert
Cc: Christian Borntraeger, Marc Hartmayer, qemu-devel, qemu-s390x,
virtio-fs, Stefan Hajnoczi, Sven Schnelle, Stefan Liebler
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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Virtio-fs] [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
@ 2022-11-29 12:04 ` Stefan Hajnoczi
0 siblings, 0 replies; 25+ messages in thread
From: Stefan Hajnoczi @ 2022-11-29 12:04 UTC (permalink / raw)
To: Dr. David Alan Gilbert
Cc: Christian Borntraeger, Marc Hartmayer, qemu-devel, qemu-s390x,
virtio-fs, Stefan Hajnoczi, Sven Schnelle, Stefan Liebler
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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Virtio-fs] [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist
2022-11-28 10:17 ` German Maglione
@ 2022-12-01 9:44 ` Marc Hartmayer
0 siblings, 0 replies; 25+ messages in thread
From: Marc Hartmayer @ 2022-12-01 9:44 UTC (permalink / raw)
To: German Maglione
Cc: qemu-devel, Stefan Liebler, virtio-fs, Christian Borntraeger,
qemu-s390x, Sven Schnelle, Stefan Hajnoczi
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
^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2022-12-01 9:44 UTC | newest]
Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-11-25 14:39 [PATCH] virtiofsd: Add `sigreturn` to the seccomp whitelist Marc Hartmayer
2022-11-25 14:39 ` [Virtio-fs] " Marc Hartmayer
2022-11-25 16:32 ` German Maglione
2022-11-28 6:18 ` Christian Borntraeger
2022-11-28 9:00 ` Marc Hartmayer
2022-11-28 10:17 ` German Maglione
2022-12-01 9:44 ` Marc Hartmayer
2022-11-25 20:50 ` Stefan Hajnoczi
2022-11-25 20:50 ` [Virtio-fs] " Stefan Hajnoczi
2022-11-28 18:47 ` Dr. David Alan Gilbert
2022-11-28 18:47 ` [Virtio-fs] " Dr. David Alan Gilbert
2022-11-29 9:38 ` Marc Hartmayer
2022-11-29 9:38 ` [Virtio-fs] " Marc Hartmayer
2022-11-29 9:42 ` Dr. David Alan Gilbert
2022-11-29 9:42 ` [Virtio-fs] " Dr. David Alan Gilbert
2022-11-29 9:52 ` Christian Borntraeger
2022-11-29 9:52 ` [Virtio-fs] " Christian Borntraeger
2022-11-29 9:57 ` Christian Borntraeger
2022-11-29 9:57 ` [Virtio-fs] " Christian Borntraeger
2022-11-29 10:16 ` Dr. David Alan Gilbert
2022-11-29 10:16 ` [Virtio-fs] " Dr. David Alan Gilbert
2022-11-29 12:04 ` Stefan Hajnoczi
2022-11-29 12:04 ` [Virtio-fs] " Stefan Hajnoczi
2022-11-29 10:16 ` Marc Hartmayer
2022-11-29 10:16 ` [Virtio-fs] " Marc Hartmayer
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.