Messages in this thread | | | From | Andy Lutomirski <> | Date | Tue, 26 Jun 2018 12:32:22 -0700 | Subject | Re: rseq: How to test for compat task at signal delivery |
| |
On Tue, Jun 26, 2018 at 11:45 AM Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote: > > ----- On Jun 26, 2018, at 1:38 PM, Mathieu Desnoyers mathieu.desnoyers@efficios.com wrote: > > > Hi Andy, > > > > I would like to make the behavior rseq on compat tasks more robust > > by ensuring that kernel/rseq.c:rseq_get_rseq_cs() clears the high > > bits of rseq_cs->abort_ip, rseq_cs->start_ip and > > rseq_cs->post_commit_offset when a 32-bit binary is run on a 64-bit > > kernel. > > > > The intent here is that if user-space has garbage rather than zeroes > > in its struct rseq_cs fields padding, the behavior will be the same > > whether the binary is run on 32-bit or 64 kernels. > > > > I know that internally, the kernel is making a transition from > > is_compat_task() to in_compat_syscall(). > > > > I'm fine with using in_compat_syscall() when rseq_get_rseq_cs() is > > invoked from a system call, but is it OK to call it when it is > > invoked from signal delivery ? AFAIU, signals can be delivered > > upon return from interrupt as well. > > > > If not, what strategy do you recommend for arch-agnostic code ? > > I think what we're missing here is a new "is_compat_frame(struct ksignal *ksig)" > which I could use in the rseq code. I'll prepare a patch and we can discuss > from there. >
That sounds about right.
I'm confused, though. Wouldn't it be more consistent to just segfault if the high 32 bits are not clear when rseq transitions to a 32-bit context? If there's garbage in 64-bit mode, the program will crash. Why should 32-bit mode be any different?
| |