Signal Handling

13 views
Skip to first unread message

Bailey Battles

unread,
Oct 21, 2020, 8:24:25 PM10/21/20
to gVisor Users [Public]
This is a really cool project with some great documentation!  I am having a bit of trouble understanding signal handling with a Ptrace Platform though.  Reading here I understand why a SIGSEGV would occur.  I'm confused about the line " The host then sends a SIGSEGV to the sentry."

It's my understanding here that the sentry is handling signals from the Application process.  If someone could point me to the place in the code where the handler was registered or explain my misunderstanding I'd really appreciate it.

Best,
Bailey

Ian Lewis

unread,
Oct 21, 2020, 10:37:38 PM10/21/20
to Bailey Battles, gVisor Users [Public]
Hi,

The SIGSEGV is a more special kind of fault/signal that is raised by the host hardware and trapped by the sentry. It occurs because the memory region being written to by the application isn't actually allocated on the host yet. The sentry will create memory regions that it tracks itself but only actually allocate the backing memory on the host when it's written to. When it is, the sentry will catch the SIGSEGV from the host and actually allocate the memory on the host if it's a valid region the sentry knows about. Hope that makes sense.

Jamie or Adin would know better but IIUC the low level SIGSEGV processing is done by the safemem and safecopy packages and higher level mappings and such done in the mm package and mapping memory to files etc. in the linked fsutil package (there may be a separate implementation for vfs2 but I'm not as familiar with that. Again others might know better).

--
You received this message because you are subscribed to the Google Groups "gVisor Users [Public]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gvisor-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gvisor-users/0be03e44-f531-41ad-a772-f43dadc30db1n%40googlegroups.com.


--

Ian Lewis | Developer Advocate | ianl...@google.com | +81 (03)4540-2465

Bailey Battles

unread,
Oct 22, 2020, 12:11:29 PM10/22/20
to gVisor Users [Public]
Hi Ian,

Thanks so much that is helpful!  I think the part I'm mostly confused about is how the sentry catches the signal from the host.  If my mental model is correct, the application is running in it's own process.  When it attempts to access invalid memory the host creates a SIGSEGV signal to send to the application process but the sentry is able to catch it and allocate the memory on the host.  I'm curious as to how the sentry is able to get the signal from the application process before the application process receives the SIGSEGV and terminates.

I have been reading through the code some more and I found this.  Is this where the Sentry would find out about the SIGSEGV?

Adin Scannell

unread,
Oct 22, 2020, 12:59:56 PM10/22/20
to Bailey Battles, gVisor Users [Public]
On Thu, Oct 22, 2020 at 9:11 AM Bailey Battles <bailey....@gmail.com> wrote:
Hi Ian,

Thanks so much that is helpful!  I think the part I'm mostly confused about is how the sentry catches the signal from the host.  If my mental model is correct, the application is running in it's own process.  When it attempts to access invalid memory the host creates a SIGSEGV signal to send to the application process but the sentry is able to catch it and allocate the memory on the host.  I'm curious as to how the sentry is able to get the signal from the application process before the application process receives the SIGSEGV and terminates.

I have been reading through the code some more and I found this.  Is this where the Sentry would find out about the SIGSEGV?

You've got it. When a thread is attached to a tracer, any signal results stops the tracee and the tracer can pull the signal. This signal is never processed by the tracee thread.

On Wednesday, October 21, 2020 at 7:37:38 PM UTC-7 Ian Lewis wrote:
Hi,

The SIGSEGV is a more special kind of fault/signal that is raised by the host hardware and trapped by the sentry. It occurs because the memory region being written to by the application isn't actually allocated on the host yet. The sentry will create memory regions that it tracks itself but only actually allocate the backing memory on the host when it's written to. When it is, the sentry will catch the SIGSEGV from the host and actually allocate the memory on the host if it's a valid region the sentry knows about. Hope that makes sense.

Jamie or Adin would know better but IIUC the low level SIGSEGV processing is done by the safemem and safecopy packages and higher level mappings and such done in the mm package and mapping memory to files etc. in the linked fsutil package (there may be a separate implementation for vfs2 but I'm not as familiar with that. Again others might know better).

On Thu, Oct 22, 2020 at 9:24 AM Bailey Battles <bailey....@gmail.com> wrote:
This is a really cool project with some great documentation!  I am having a bit of trouble understanding signal handling with a Ptrace Platform though.  Reading here I understand why a SIGSEGV would occur.  I'm confused about the line " The host then sends a SIGSEGV to the sentry."

It's my understanding here that the sentry is handling signals from the Application process.  If someone could point me to the place in the code where the handler was registered or explain my misunderstanding I'd really appreciate it.

Best,
Bailey

--
You received this message because you are subscribed to the Google Groups "gVisor Users [Public]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gvisor-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gvisor-users/0be03e44-f531-41ad-a772-f43dadc30db1n%40googlegroups.com.


--

Ian Lewis | Developer Advocate | ianl...@google.com | +81 (03)4540-2465

--
You received this message because you are subscribed to the Google Groups "gVisor Users [Public]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gvisor-users...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages