Thread (5 messages) flat view 5 messages, 3 authors, 2018-06-28

Re: [RFC PATCH for 4.18 2/2] rseq: compat: clear high bits of rseq_cs fields

From: Andy Lutomirski <luto@amacapital.net>
Date: 2018-06-26 21:58:17
Also in: linux-arch, lkml

On Jun 26, 2018, at 2:16 PM, Mathieu Desnoyers [off-list ref] wrote:

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-bit kernels.

Use in_compat_syscall() when rseq_get_rseq_cs() is invoked from
system call context, and use is_compat_frame() when invoked from
signal delivery.
And when it’s invoked due to preemption unrelated to a syscall or signal, you malfunction?

I think the only sane solution is to make these fields be u64, delete the LINUX_FIELD_ macros, and possibly teach the x86 slowpath return to inject a signal if it’s trying to return to a 32-bit context with garbage in the high bits of regs->ip so that we determistically fail if the user screws up.

Rseq is brand new. It should not need compat code at all.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help