Signal Handling

[Bailey Battles]

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]

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]

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]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/gvisor-users/01b5a6f8-aafc-47aa-9259-50266d914138n%40googlegroups.com.