On Thu, Jul 16, 2020 at 09:48:50PM -0700, Andy Lutomirski wrote:
On Thu, Jul 16, 2020 at 7:15 PM Gabriel Krisman Bertazi krisman@collabora.com wrote:
Andy Lutomirski luto@kernel.org writes:
On Thu, Jul 16, 2020 at 12:31 PM Gabriel Krisman Bertazi krisman@collabora.com wrote:
This is quite nice. I have a few comments, though:
You mentioned rt_sigreturn(). Should this automatically exempt the kernel-provided signal restorer on architectures (e.g. x86_32) that provide one?
That seems reasonable. Not sure how easy it is to do it, though.
For better or for worse, it's currently straightforward because the code is:
__kernel_sigreturn: .LSTART_sigreturn: popl %eax /* XXX does this mean it needs unwind info? */ movl $__NR_sigreturn, %eax SYSCALL_ENTER_KERNEL
and SYSCALL_ENTER_KERNEL is hardwired as int $0x80. (The latter is probably my fault, for better or for worse.) So this would change to:
__vdso32_sigreturn_syscall: SYSCALL_ENTER_KERNEL
and vdso2c would wire up __vdso32_sigreturn_syscall. Then there would be something like:
bool arch_syscall_is_vdso_sigreturn(struct pt_regs *regs);
and that would be that. Does anyone have an opinion as to whether this is a good idea? Modern glibc shouldn't be using this mechanism, I think, but I won't swear to it.
On arm64 sigreturn is always through the vdso, so IIUC we'd certainly need something like this. Otherwise it'd be the user's responsibility to register the vdso sigtramp range when making the prctl, and flip the selector in each signal handler, which sounds both painful and fragile.
Mark.